Если главная страница и большая часть сайта работают, но отдельные страницы не открываются, проблема обычно находится не в сервере целиком, а в конкретном URL, шаблоне, модуле, данных или правилах маршрутизации. В этом гайде разберём, как последовательно найти причину.
Иногда сайт в целом работает нормально: открывается главная страница, каталог, админка и большинство разделов, но один или несколько URL выдают ошибку, белую страницу, сообщение «Страница не найдена» или вообще перестают загружаться.
Такая ситуация отличается от полного падения сайта. Если не открываются только некоторые страницы, сервер, домен и PHP, скорее всего, продолжают работать. Причину нужно искать в конкретном URL, данных этой страницы, шаблоне, плагине, модуле, настройках ЧПУ или базе данных.
Ниже - последовательная диагностика, которая поможет понять, почему некоторые страницы недоступны и где именно возникла проблема.
Не стоит начинать с переустановки CMS, отключения всех плагинов или изменения PHP. Сначала нужно определить характер ошибки.
Откройте проблемную страницу и посмотрите, что именно происходит:
Тип ошибки значительно сужает круг возможных причин.
Ошибка 404 означает, что сервер или CMS не смогли сопоставить запрошенный URL с существующей страницей.
Если сама страница существует в административной панели, проверьте прежде всего структуру URL.
Сравните URL проблемной страницы с её текущим адресом в административной панели. Страница могла быть переименована, перенесена в другую категорию или получить новый ЧПУ-адрес.
Например, раньше страница находилась по адресу:
/catalog/product.htmlа после изменения структуры сайта стала доступна по адресу:
/catalog/category/productСтарый URL без настроенного 301-редиректа будет возвращать 404.
В WordPress достаточно иногда повторно сохранить настройки постоянных ссылок:
Настройки → Постоянные ссылки → Сохранить изменения.
Менять структуру при этом необязательно.
Так WordPress повторно формирует правила маршрутизации.
В OpenCart, Bitrix и других CMS необходимо проверить настройки SEO URL, модуль ЧПУ и правила в .htaccess.
Если правила перенаправления повреждены или были изменены вручную, часть URL может перестать обрабатываться.
Особенно это характерно для сайтов, где одновременно используются:
Ошибка в одном регулярном выражении способна затронуть только определённую группу страниц.
HTTP 500 означает, что при обработке запроса произошла серверная ошибка. Если остальные страницы работают, чаще всего причина связана с кодом, выполняемым только на проблемном URL.
Например, это может быть:
При ошибке 500 один из самых полезных источников информации - журнал ошибок PHP.
В зависимости от хостинга файл может называться:
error.log
php_error.log
error_logВ панели управления хостингом журнал также может находиться в разделе «Логи», «Журналы», «Ошибки PHP» или «Логи сайта».
Откройте проблемную страницу, после чего сразу проверьте последние записи журнала. Так проще связать конкретную ошибку с запросом.
Если выполнение PHP-кода аварийно прекращается, в журнале может появиться сообщение вроде:
PHP Fatal error: Uncaught Error...Особенно важно обратить внимание на:
Например, ошибка может возникать только в шаблоне карточки товара. Тогда главная страница и категории будут работать, а товары - нет.
Или проблема находится в функции вывода статей, поэтому весь сайт работает, кроме блога.
Если не открывается всего одна или несколько страниц одного типа, проблема может быть не в программном коде, а в их данных.
Например:
Хороший способ проверки - создать новую страницу того же типа.
Если новая страница работает, а старая нет, вероятно, проблема связана именно с данными конкретной записи.
Многие CMS используют разные шаблоны для разных типов контента.
Например, могут существовать отдельные файлы для:
Поэтому повреждение одного файла вовсе не обязательно приведёт к падению всего сайта.
Если все статьи перестали открываться, но остальные страницы работают, нужно проверить шаблон статьи и связанные с ним функции.
Если проблема возникает только в карточках товаров - проверяются шаблон товара, контроллер, модель и модули, подключаемые именно на карточке.
Плагин может работать только на определённых страницах. Поэтому конфликт расширения не всегда выводит из строя весь сайт.
Например:
Если проблема появилась после установки или обновления расширения, временно отключите именно его и повторите проверку.
Не следует сразу отключать десятки модулей на рабочем сайте. Сначала стоит определить, какие расширения вообще участвуют в формировании проблемной страницы.
Ситуация, когда не работает целая группа URL, часто указывает на проблему маршрутизации.
Например, работают:
/catalog/
/contacts/
/about/но не открываются:
/blog/article-1/
/blog/article-2/
/blog/article-3/В этом случае стоит проверить:
/blog/;Если все проблемные страницы имеют одинаковую часть URL, это важная диагностическая подсказка.
Иногда разные сущности сайта получают одинаковый адрес.
Например, URL /news/ одновременно используется:
В результате система может неправильно определять, какой контроллер должен обработать запрос.
Такая проблема нередко появляется после изменения структуры сайта или установки SEO-модуля.
Если CMS получает данные страницы из MySQL или другой базы данных, ошибка запроса может приводить к недоступности отдельных страниц.
В журнале могут встречаться сообщения:
Table doesn't exist
Unknown column
Duplicate entry
Column not found
SQL syntax errorТакже возможны проблемы с кодировками и сравнением строк.
Например:
Illegal mix of collationsПри этом ошибка может возникать только на тех страницах, где выполняется конкретный SQL-запрос.
Если определённый PHP-файл, шаблон или каталог имеет неправильные права, сервер может возвращать ошибку 403 или 500.
Обычно для большинства конфигураций используются:
файлы - 644
каталоги - 755Но конкретные требования зависят от конфигурации сервера и хостинга.
Не следует без необходимости назначать права 777. Это не универсальный способ исправления ошибок и может снизить безопасность сайта.
После обновления сайта часть страниц иногда продолжает использовать старые данные.
Очистить может потребоваться:
Особенно это актуально после изменения маршрутов, PHP-кода, шаблонов или структуры URL.
Если проблема наблюдается только у одного пользователя или браузера, откройте URL:
Это позволяет исключить локальный кеш, cookies и браузерные расширения.
Когда проблемная страница открывается значительно дольше остальных, причина часто связана с тяжёлой операцией:
В журнале при этом может появляться сообщение:
Maximum execution time exceededПростое увеличение лимита времени не всегда является правильным решением. Если обычная страница выполняется десятки секунд, сначала нужно найти медленный участок кода.
Такая ошибка означает, что PHP-процесс превысил разрешённый объём памяти.
Если она возникает только на некоторых страницах, вероятно, именно эти страницы обрабатывают больше данных или запускают ресурсоёмкий код.
Например, причиной могут быть:
Увеличение memory_limit может временно убрать ошибку, но сначала желательно понять, почему конкретной странице требуется столько памяти.
Один из самых быстрых способов найти причину - вспомнить, что менялось непосредственно перед появлением проблемы.
Это могло быть:
.htaccess;Если проблема появилась сразу после конкретного изменения, начинать диагностику нужно именно с него.
Если некоторые страницы сайта недоступны, оптимальная последовательность проверки выглядит так:
.htaccess.Такой подход обычно эффективнее, чем хаотично менять настройки сервера или отключать все расширения подряд.
При диагностике полезно искать общее между неработающими URL.
Например:
Чем точнее определена группа проблемных страниц, тем быстрее можно локализовать неисправность.
Для диагностики иногда включают вывод PHP-ошибок непосредственно на страницу. На рабочем сайте делать это постоянно не стоит.
Сообщения PHP могут раскрывать:
Безопаснее записывать ошибки в журнал и анализировать их там.
Резервная копия полезна, если точно известно, что до определённого изменения страницы работали.
Однако восстановление всего сайта не должно быть первым действием. Если причина находится, например, в одном неправильном URL или одной записи базы данных, полный откат может отменить полезные изменения и новые заказы.
Сначала желательно определить источник проблемы и восстановить только повреждённый компонент.
Для технической диагностики полезно подготовить:
error.log в момент открытия страницы;Эти данные позволяют значительно быстрее определить, находится ли проблема в PHP-коде, базе данных, шаблоне, модуле, маршрутизации или настройках сервера.
Если сайт работает, но некоторые страницы выдают ошибку, это обычно означает локальную проблему, а не полную неисправность сервера. Причину нужно искать в том, чем проблемные страницы отличаются от рабочих: URL, типом контента, шаблоном, выполняемым кодом, подключённым модулем или данными в базе.
Начните с кода ответа и журнала ошибок, затем сравните рабочие и нерабочие страницы. Последовательная диагностика позволяет найти источник проблемы значительно быстрее, чем переустановка CMS или изменение настроек наугад.
Переработана структура каталога интернет-магазина на OcStore 1.5.6.4: карточки товаров получили постоянные URL и стабильные хлебные крошки, старые адреса перенаправляются через 301 Redirect, а отдельные товары теперь можно выводить в плитках категорий вместе с подкатегориями.
Переработал страницы онлайн-оплаты туров: убрал устаревшие даты и служебные элементы, сделал кнопку оплаты заметнее и создал единый шаблон для всех направлений.
Пришлите ссылку на сайт и кратко опишите задачу — я посмотрю и предложу следующий шаг.