Новый глюк WordPress

Записи не отображаются на сайте, хотя в админке они на месте, статус «Опубликовано», дата верная, текст открывается в редакторе — а по прямой ссылке отдаётся 404. У одного из клиентских сайтов так пропало 214 статей блога за одну ночь: обновилось ядро и три плагина, сработал автоапдейт, и к утру из поиска начали вылетать позиции по низкочастотке. Ситуация выглядит катастрофой, но в девяти случаях из десяти чинится за пятнадцать минут — если идти по порядку, а не тыкать наугад.

Что именно происходит, когда «записи пропали»

Под одной и той же жалобой скрываются четыре разных поломки, и лечатся они по-разному. Прежде чем что-то трогать, надо понять, какая именно из них у вас.

• Записи отдают 404. Список постов в админке полный, но отдельная запись по своему адресу не открывается. Почти всегда это постоянные ссылки или правила перезаписи.
• Записи открываются по прямой ссылке, но не выводятся в списках. Главная, архив рубрики, лента блога пустые или показывают старые материалы. Это уже цикл в шаблоне, кэш или фильтр запроса от плагина.
• Открывается пустая страница без текста. Шапка и подвал есть, контента нет. Ошибка в шаблоне записи или в теме.
• Белый экран на всём сайте. Фатальная ошибка PHP. Записи тут ни при чём, лежит весь фронтенд, а иногда и админка.

Разница принципиальная: в первом случае поисковик получит 404 и начнёт выбрасывать страницы из индекса за несколько дней, во втором — страницы живы, но теряют внутренние ссылки и вес, в четвёртом — сайт вообще недоступен и робот при повторных заходах помечает его как проблемный. Поэтому первое действие всегда одно: открыть проблемный адрес в режиме инкогнито и посмотреть, какой код ответа отдаёт сервер.

curl -I https://site.ru/moya-zapis/

Если в ответе HTTP/2 200 — страница жива, ищем проблему в выводе. Если 404 — ищем в ссылках и роутинге. Если 500 — ищем в логе ошибок. Дальше по таблице.

Симптом	Вероятная причина	Где проверять
Все записи отдают 404, главная работает	Слетели правила перезаписи после обновления ядра	Настройки — Постоянные ссылки, файл .htaccess
404 только у части записей	Дубли слагов, конфликт с ЧПУ страницы или рубрики	Поле post_name в базе, структура ссылок
Лента блога пустая, записи открываются	Плагин фильтрует pre_get_posts или сломан цикл темы	Отключение плагинов, файлы index.php, archive.php
На сайте старая версия, в админке новая	Кэш плагина кэширования или кэш на стороне сервера	Очистка кэша, заголовки ответа сервера
Записи видит только администратор	Статус «На утверждении», «Черновик» или пароль	Колонка статуса в списке записей, поле post_status
Записи нет ни в админке, ни на сайте	Повреждение таблицы или неполный импорт базы	Проверка таблиц, лог MySQL
Белый экран целиком	Фатальная ошибка PHP в плагине или теме	debug.log, лог ошибок хостинга
Записи есть, но не того типа	Плагин произвольных типов записей отключён или обновлён	Значение post_type, активные плагины

Постоянные ссылки: причина номер один

После обновления ядра WordPress перегенерирует правила перезаписи. Если файл .htaccess недоступен для записи, права на него стоят 444, или на сервере используется nginx без нужной директивы, правила остаются битыми. Внешне это выглядит именно так: главная открывается, любая запись — 404.

Лечение занимает полминуты. Заходим в «Настройки — Постоянные ссылки», ничего не меняем и жмём «Сохранить». WordPress пересоберёт правила и перезапишет .htaccess. Проверяем запись — обычно на этом всё заканчивается.

Если не помогло, проверяем сам файл. Он лежит в корне сайта и должен содержать стандартный блок:

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Права на файл — 644, владелец совпадает с пользователем сайта. Если блока нет, вставляем вручную. На nginx правил перезаписи в .htaccess нет вовсе, там нужна директива try_files $uri $uri/ /index.php?$args; в конфиге, и её правит хостер или администратор сервера.

Через WP-CLI то же самое делается одной командой:

wp rewrite flush --hard

Отдельный случай — конфликт слагов. Если у страницы и у рубрики одинаковый ЧПУ, часть записей начинает уходить в 404 непредсказуемо. Ищется запросом к базе по совпадениям post_name среди записей и страниц; лечится переименованием одного из адресов и настройкой 301-редиректа со старого.

Конфликт плагина после обновления

Второй по частоте сценарий: плагин обновился и стал несовместим с версией ядра, темой или другим плагином. Особенно часто ломают вывод записей SEO-плагины, конструкторы страниц, плагины произвольных полей и всё, что вмешивается в главный запрос через pre_get_posts.

Проверяется методом исключения. Если админка доступна, отключаем плагины по одному, начиная с тех, что обновлялись последними, и после каждого отключения обновляем проблемную страницу. Если админка недоступна, работаем по FTP или SSH: переименовываем папку wp-content/plugins в plugins_off. WordPress не найдёт плагины и деактивирует их все разом. Сайт поднимется, после чего папку возвращаем на место и включаем плагины по одному через админку.

mv wp-content/plugins wp-content/plugins_off
mkdir wp-content/plugins

Аккуратнее: некоторые плагины при деактивации чистят свои настройки. Перед такой операцией забирайте дамп базы. Через WP-CLI отключение делается мягче, без потери списка активных:

wp plugin deactivate --all
wp plugin activate imya-plagina

Когда виновник найден, вариантов три: откатить плагин на предыдущую версию, найти замену или заказать правку кода. Откат делается вручную — старые версии лежат в разделе Advanced на странице плагина в каталоге, либо плагином отката версий. Держать сайт на устаревшей версии долго нельзя: это дыра в безопасности.

Ошибка в шаблоне темы

Если код ответа 200, а контента нет, смотрим шаблон. За вывод записи отвечает single.php или content-single.php, за списки — index.php, archive.php, home.php. Достаточно одной незакрытой скобки в цикле или лишнего wp_reset_postdata(), чтобы вывод оборвался.

Смежный материал по теме — «Лучшие SEO плагины для wordpress».

Быстрая проверка: временно переключаемся на стандартную тему (Twenty Twenty-Four или любую другую из комплекта). Если записи появились — дело в теме, а не в ядре и не в базе.

wp theme activate twentytwentyfour

Переключение темы через админку не удаляет вашу тему и не стирает контент, но сбрасывает настройки виджетов и меню, поэтому на живом сайте делайте это в минимальный трафик и с готовым дампом. Если тема кастомная и правилась без дочерней темы, обновление темы просто затирает все правки — записи при этом остаются, а вот вывод описаний, заголовок H1 и микроразметка исчезают. Это отдельная беда, о ней ниже.

Типовые места, где ломается вывод:

• цикл while (have_posts()) без the_post() — страница грузится, текста нет;
• вызов query_posts() вместо отдельного WP_Query — ломает пагинацию и обнуляет архив;
• жёстко прописанное количество постов в шаблоне, которое после обновления перекрывает настройку в админке;
• функция темы, вызывающая удалённую в новой версии PHP конструкцию, — фатальная ошибка вместо контента.

Кэш: сайт показывает вчерашний день

Плагин кэширования отдаёт сохранённую копию страницы. Если сбой произошёл в момент генерации кэша, посетители будут видеть пустую ленту даже после того, как вы всё почините. Проверяется просто: откройте страницу с добавленным параметром — например, ?nocache=1. Если так контент появился, чинить надо не сайт, а кэш.

Порядок очистки: сначала кэш плагина (W3 Total Cache, WP Super Cache, LiteSpeed Cache — у каждого своя кнопка «Очистить весь кэш»), затем объектный кэш, затем кэш на стороне сервера или CDN. Если используется Cloudflare, чистится ещё и там, иначе локальная очистка ничего не даст.

wp cache flush
rm -rf wp-content/cache/*

Важный нюанс для проверок: адрес с любым GET-параметром обычно обходит полностраничный кэш. Поэтому итоговую проверку всегда делайте по чистому адресу, без «хвостов», иначе увидите не то, что видит поисковый робот и обычный посетитель.

Тип записи, статус и права доступа

Банальная, но регулярная причина: записи есть, но у них не тот статус. После неудачного импорта или сбоя редактора посты уходят в «На утверждении» или «Черновик». В списке записей это видно по колонке статуса, а фильтры сверху показывают количество по каждому. Массово статус меняется групповым редактированием: выделяем нужные, «Изменить», статус «Опубликовано».

Второй вариант — тип записи. Если материалы создавались произвольным типом записи через плагин, а плагин отключился или обновился с изменением имени типа, записи остаются в базе, но ни один шаблон их не выводит. В админке они тоже пропадают из привычного раздела. Проверяется значением поля post_type в таблице wp_posts.

Третий — дата публикации в будущем. Запись со статусом «Запланировано» на сайте не появится. Отдельно ловится «Пропущенное расписание»: сервер не выполнил cron, и запись зависла в статусе future навсегда. Лечится плагином контроля расписания или перестановкой даты на текущую.

Четвёртый — защита паролем и статус «Личное». Такие записи видны только автору и администратору, для остальных их нет ни в лентах, ни в поиске по сайту.

Когда виновата база данных

Признак: записи не видит ни сайт, ни админка, а в браузере периодически всплывает «Ошибка установки соединения с базой данных» или таблица постов открывается с задержкой в десятки секунд. Причины — повреждение таблиц при аварийном перезапуске MySQL, переполненная квота диска, разросшиеся таблицы wp_postmeta и wp_options.

Штатный ремонт включается в wp-config.php:

define('WP_ALLOW_REPAIR', true);

После этого открываем адрес site.ru/wp-admin/maint/repair.php — авторизация не потребуется, поэтому строку из конфига обязательно удалите сразу после ремонта. Альтернатива через консоль:

wp db repair
wp db optimize

Отдельно проверьте свободное место на диске. Когда квота выбрана под ноль, MySQL перестаёт писать во временные таблицы, и любая выборка с сортировкой падает. Хостинг при этом формально «работает», а сайт наполовину пуст. Команда df -h по SSH или раздел статистики в панели покажет реальную картину за секунду.

Если нужны детали, смотрите «Новый развод в интернете на оплате домена».

Белый экран: как диагностировать

Белая страница означает фатальную ошибку PHP: скрипт остановился, а вывод ошибок на боевых серверах отключён. Задача — увидеть текст ошибки. Открываем wp-config.php и выше строки «That’s all, stop editing» добавляем:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Такая связка не показывает ошибки посетителям, но пишет их в файл wp-content/debug.log. Обновляем проблемную страницу, открываем лог, смотрим последние строки: там будет путь к файлу и номер строки, где всё сломалось. Обычно этого достаточно, чтобы понять, какой плагин виноват.

tail -n 50 wp-content/debug.log

Параллельно смотрим лог ошибок самого сервера. У ISPmanager и cPanel он лежит рядом с корнем сайта, чаще всего в logs/error.log или site.ru/logs/site.ru.error.log. Там видны ошибки, которые до WordPress вообще не дошли: нехватка памяти, превышение времени выполнения, падение PHP-FPM.

Дальше по порядку: отключаем плагины переименованием папки, переключаемся на стандартную тему, увеличиваем лимит памяти строкой define('WP_MEMORY_LIMIT', '256M');, проверяем версию PHP. Последнее особенно актуально: хостеры массово переводят сайты на PHP 8.x, и старые плагины на этом падают молча. Откат версии PHP в панели хостинга на предыдущую — законный временный шаг, чтобы поднять сайт и спокойно разобраться.

Отладку обязательно выключайте после работы. Оставленный debug.log доступен по прямой ссылке и раскрывает пути к файлам и структуру сайта.

Шаг	Действие	Что смотрим	Время
1	Открыть страницу в инкогнито, снять код ответа	200, 404, 500, 503	1 минута
2	Пересохранить постоянные ссылки	Появились ли записи	1 минута
3	Очистить кэш плагина, сервера и CDN	Изменился ли вывод	3 минуты
4	Включить WP_DEBUG_LOG, прочитать debug.log	Файл и строка ошибки	5 минут
5	Прочитать лог ошибок хостинга	Память, таймауты, падение PHP	5 минут
6	Отключить все плагины, включать по одному	На каком плагине ломается	10-20 минут
7	Переключиться на стандартную тему	Виновата ли тема	3 минуты
8	Проверить статус и тип записей	post_status, post_type, дата	5 минут
9	Проверить таблицы базы и место на диске	Ошибки таблиц, свободное место	10 минут
10	Развернуть последнюю копию, если время дороже	Работоспособность сайта	15-40 минут

Выпадение из индекса как последствие сбоя

Самое дорогое в этой истории — не сам сбой, а то, что происходит после. Пока страницы отдавали 404 или 500, поисковые роботы успели их обойти. Яндекс исключает такие адреса из индекса довольно быстро, Google держится дольше, но тоже реагирует. Возврат позиций после восстановления занимает от одной до нескольких недель, и это при условии, что вы сами подтолкнули переобход.

Что делать сразу после починки:

• в Яндекс.Вебмастере открыть раздел «Индексирование — Страницы в поиске» и посмотреть динамику исключённых страниц за последние дни;
• в разделе «Статистика обхода» проверить всплеск кодов 404 и 5xx — там видна точная дата начала проблемы;
• отправить восстановленные адреса на переобход через «Переобход страниц» (лимит зависит от сайта, обычно десятки адресов в сутки, есть API);
• в Google Search Console проверить отчёт «Страницы» и запросить индексирование ключевых URL;
• убедиться, что sitemap.xml пересобрался и отдаёт актуальные даты изменения;
• проверить robots.txt — при откате из копии туда иногда возвращается строка Disallow: / с тестовой площадки.

Последний пункт стоит отдельного внимания. Копия, снятая с dev-сервера, часто несёт запрет индексации и включённую галочку «Попросить поисковые системы не индексировать сайт» в настройках чтения. Восстановили сайт, обрадовались, а через две недели трафик обвалился уже по другой причине.

Что ещё ломается после обновлений

Пропавшие записи — самый заметный, но не единственный симптом. После обновления ядра, темы или SEO-плагина регулярно всплывает следующее.

• Пропали описания на страницах. Смена SEO-плагина или его мажорное обновление меняет ключи в wp_postmeta. Description исчезает у всех страниц разом, и в выдаче начинает показываться случайный кусок текста.
• Слетели заголовки Title. Шаблон title из настроек плагина сбросился на дефолтный, и все страницы получили одинаковый заголовок вида «Название записи — Название сайта» или вовсе «Просто ещё один сайт на WordPress».
• Исчез H1 в шаблоне. Обновление темы поверх правок без дочерней темы. Заголовок первого уровня либо пропадает, либо превращается в div. Для поиска это потеря главного текстового сигнала на странице.
• Перестали работать формы. Обновился плагин форм или изменилась версия PHP, письма перестали уходить. Внешне форма отправляется, «спасибо» показывается, заявки не приходят. Молчаливая потеря лидов — самый неприятный вид поломки.
• Вырос вес страницы. Плагин подключил новые библиотеки и шрифты, кэш-плагин сбросил настройки объединения файлов. Скорость проседает, за ней проседают поведенческие.
• Поехала вёрстка на мобильных. Обновился конструктор страниц, часть блоков потеряла адаптивные настройки.
• Сломалась микроразметка. Хлебные крошки, FAQ, товары теряют схему, из выдачи пропадают расширенные сниппеты.

Что проверить после обновления	Как проверить	Признак проблемы
Код ответа ключевых страниц	curl -I или массовая проверка краулером	404, 500, 302 вместо 200
Title и Description	Просмотр кода страницы, выборка краулером	Пустые, дублирующиеся, шаблонные
Заголовок H1	Поиск по коду страницы	Отсутствует или их больше одного
Вывод записей и пагинация	Лента блога, вторая и третья страницы архива	Пустой список, повтор постов
Формы обратной связи	Тестовая отправка на рабочую почту	Письмо не пришло за 5 минут
Скорость загрузки	PageSpeed Insights, вкладка Network	Рост веса и времени ответа
Мобильная версия	Просмотр на телефоне и в эмуляции	Горизонтальная прокрутка, наложения
robots.txt и sitemap.xml	Открыть оба файла по прямым адресам	Запрет индексации, пустая карта
Микроразметка	Валидатор структурированных данных	Пропали типы, появились ошибки
Счётчики аналитики	Отчёт по визитам в реальном времени	Ноль визитов при живом трафике

Как обновляться, чтобы не ловить такие вечера

Автообновления всего подряд удобны ровно до первого падения. Разумный компромисс: ядро обновляется автоматически в пределах минорных версий безопасности, всё остальное — руками и по регламенту.

1. Снять копию перед обновлением. Файлы плюс база. Копия должна лежать не на том же сервере.
2. Обновлять на тестовой площадке. Копия сайта на поддомене с закрытой индексацией и паролем. Прогнали обновление там, посмотрели, перенесли на боевой.
3. Обновлять по одному плагину. Обновили — открыли главную, запись, страницу услуги, форму. Пять минут на каждый плагин экономят вечер поисков виновника.
4. Не обновлять в пятницу вечером и перед отпуском. Правило звучит как шутка, но работает.
5. Читать changelog. Мажорные версии (переход с 5.x на 6.x) почти всегда что-то ломают; их лучше ставить через неделю после релиза, когда авторы выпустят патч.
6. Проверять ключевые страницы после. Главная, категория, запись, страница услуги, корзина или форма заявки — короткий список из пяти-семи адресов, который проходится за пару минут.

Отключить бездумные автообновления плагинов можно в списке плагинов ссылкой «Отключить автообновления» напротив каждого. Ядро настраивается константами в wp-config.php: define('WP_AUTO_UPDATE_CORE', 'minor'); оставляет автоматику только для обновлений безопасности.

Чек-лист проверки после любого сбоя

После того как сайт поднялся, соблазн закрыть ноутбук огромен. Не закрывайте: половина последствий всплывает не сразу.

• коды ответа по списку ключевых страниц — все 200, редиректы только там, где задуманы;
• индексация — Вебмастер и Search Console, всплеск ошибок обхода, отправка на переобход;
• метатеги — Title и Description на главной, в категории, в записи, на странице услуги;
• структура заголовков — один H1 на страницу, подзаголовки на месте;
• формы — тестовая заявка с телефона и с компьютера, проверка, что письмо дошло и в CRM тоже;
• скорость — сравнение с показателями до сбоя, а не с абстрактной нормой;
• мобильная версия — меню, кнопка звонка, читаемость текста;
• внутренние ссылки — не появились ли битые после смены структуры адресов;
• изображения — на месте ли файлы в wp-content/uploads и не пропали ли атрибуты alt;
• счётчики Метрики и аналитики — код на месте, цели считаются.

Проще всего пройтись краулером по всему сайту и сравнить выгрузку с той, что снималась до обновления. Если такой выгрузки нет — сделайте её сейчас, пока всё работает. Это тридцать минут работы и главный аргумент в любом будущем споре «что сломалось».

Подробнее об этом — в статье «Перевожу сайт с WordPress на сервер с PHP 7.4».

Если сайт лежит целиком

Отдельный сценарий: не открывается ни сайт, ни админка. Последовательность действий такая.

1. Проверить, лежит ли сайт у всех, а не только у вас, — через любой внешний сервис проверки доступности или мобильный интернет без Wi-Fi.
2. Проверить домен: не истёк ли срок регистрации, на месте ли NS-записи и A-запись.
3. Проверить сертификат: истёкший SSL даёт заглушку браузера, а не ошибку сервера.
4. Зайти в панель хостинга, посмотреть статистику: место на диске, лимит процессов, нагрузка на CPU.
5. Открыть логи ошибок и логи доступа за время падения.
6. Если видно фатальную ошибку PHP — отключить плагины переименованием папки.
7. Если ничего не видно — писать в поддержку хостинга.

Обращение в поддержку экономит часы, если сразу дать конкретику. Формулировка вроде «сайт не работает, помогите» вернёт вам стандартный ответ про проверку плагинов. Полезное обращение выглядит иначе: адрес сайта, точное время начала проблемы, код ответа, который отдаёт сервер, последние строки из error.log, что вы уже сделали, был ли перенос или обновление в этот день, и прямой вопрос — не было ли на сервере работ, блокировок по лимитам или срабатывания антивируса. С такими вводными первая линия поддержки отвечает по делу, а не по скрипту.

Заброшенные плагины

Плагин, который не обновлялся два-три года, — мина замедленного действия. Он не получает правок под новые версии PHP, не закрывает уязвимости и однажды просто перестаёт работать после планового апдейта хостинга. Значительная часть взломов WordPress происходит именно через устаревшие расширения, а не через пароль администратора.

Как находить проблемные:

• на странице плагина в официальном каталоге смотрим дату последнего обновления и строку «Протестирован до версии»; расхождение с вашей версией ядра больше чем на два релиза — повод насторожиться;
• каталог помечает плагины, закрытые за нарушения или заброшенные, отдельным предупреждением — оно видно прямо в админке;
• полезно раз в квартал выгружать список активных плагинов и проверять его целиком;
• плагины безопасности умеют показывать известные уязвимости для установленных версий.

wp plugin list --fields=name,status,version,update

Отдельный вопрос — количество. Тридцать плагинов на визитке из десяти страниц означают тридцать источников конфликтов и заметный вес страницы. Каждый плагин должен отвечать на вопрос «что сломается, если его удалить». Если ответа нет — удаляйте, а не деактивируйте: неактивные плагины остаются на диске и остаются уязвимыми.

Резервные копии и регламент обслуживания

Копия, которая лежит на том же сервере, что и сайт, копией не считается. При компрометации аккаунта, аппаратном сбое или ошибке хостера вы потеряете и оригинал, и архив. Рабочая схема: автоматический бэкап файлов и базы по расписанию, выгрузка в облачное хранилище или на отдельный сервер, хранение нескольких поколений — свежая копия, недельная, месячная.

Проверка восстановления так же важна, как сам бэкап. Архив, который не разворачивается, обнаруживается ровно в тот момент, когда он нужен. Раз в квартал разверните копию на тестовом поддомене и убедитесь, что сайт поднимается целиком.

Дамп базы вручную снимается одной командой:

wp db export backup-$(date +%F).sql

Для интернет-магазинов частота выше: между двумя копиями не должно теряться больше чем несколько часов заказов. Ежедневного бэкапа тут мало, нужен ежечасный или инкрементный на уровне хостинга.

Задача	Частота	Комментарий
Резервная копия файлов и базы	Ежедневно	Хранение вне сервера, минимум 7 поколений
Обновление плагинов и темы	Раз в 2 недели	Сначала тестовая площадка, потом боевой сайт
Обновление ядра	По выходу релиза	Минорные автоматически, мажорные через неделю
Проверка кодов ответа краулером	Ежемесячно	Сравнение с прошлой выгрузкой
Проверка форм тестовой заявкой	Еженедельно	С телефона и с компьютера
Контроль индексации в Вебмастере	Еженедельно	Исключённые страницы, ошибки обхода
Оптимизация базы данных	Ежеквартально	Чистка ревизий, спама, transient-записей
Аудит списка плагинов	Ежеквартально	Удаление неиспользуемых и заброшенных
Тестовое восстановление из копии	Ежеквартально	Разворот на поддомене
Проверка версии PHP и сертификата	Раз в полгода	Срок SSL, поддержка версии PHP

Частые вопросы

Записи пропали, а бэкапа нет. Что делать?
Сначала убедитесь, что данные действительно потеряны, а не просто не выводятся: посмотрите таблицу wp_posts через phpMyAdmin. Если строки на месте, контент цел, и вопрос только в выводе. Если строк нет, запросите у хостинга резервную копию — большинство провайдеров держат автоматические бэкапы за несколько дней, даже если вы их не настраивали. Дальше сразу настройте своё резервное копирование с выгрузкой наружу.

Помогает ли просто откатить обновление?
Часто да, но это временная мера. Откат возвращает работоспособность, однако оставляет вас на версии с известными уязвимостями. Правильная последовательность: откатить, найти причину конфликта, дождаться исправления от разработчика или заменить плагин, обновиться заново.

Сколько времени страницы держатся в индексе, если отдают 404?
Точных гарантий нет. Яндекс обычно исключает адрес после нескольких неудачных обходов, что занимает от нескольких дней до пары недель в зависимости от частоты обхода сайта. У часто обновляемых сайтов это происходит быстрее. Поэтому чинить надо в день обнаружения, а не «на выходных».

Можно ли обойтись без тестовой площадки?
Для сайта-визитки с двумя плагинами — можно, достаточно свежей копии и обновления по одному расширению. Для магазина, сайта с интеграциями или кастомной темой тестовая площадка обязательна: цена одной неудачной ночи там выше стоимости поддомена.

Как понять, что сайт взломали, а не просто сломался?
Косвенные признаки: новые пользователи с правами администратора, незнакомые файлы в корне и в wp-content/uploads, редиректы на сторонние домены с мобильных, всплеск исходящих писем, предупреждение в Вебмастере о вредоносном коде. Проверяется сканером безопасности и сверкой файлов ядра с эталонной версией. При подтверждении меняются все пароли, включая доступ к базе и FTP.

Коротко

• Первым делом снимите код ответа страницы: 404, 200 без контента и 500 лечатся по-разному.
• Пересохранение постоянных ссылок закрывает большую часть случаев «записи есть в админке, но не открываются».
• Виновника ищут отключением плагинов и переключением на стандартную тему, ошибку читают в debug.log и в логе хостинга.
• После любого сбоя обязательно проверьте Вебмастер: коды обхода, исключённые страницы, переобход ключевых адресов.
• Копия перед обновлением, обновление по одному плагину, короткий чек-лист после — три привычки, которые снимают проблему целиком.

Разобраться, что сломалось после обновления, и починить — задача доработки сайта.

Из чего складывается продвижение сайта и как оно работает:

14:31

Техническую часть и удобство сайта привожу в порядок в рамках доработки сайта.