Вместо сайта открывается белая страница без сообщения об ошибке? Разбираем основные причины белого экрана и способы восстановления сайта. Пошаговые инструкции по проверке браузера, PHP, сервера, WordPress, OpenCart и других CMS.
Вместо привычного сайта открывается белая страница, меню и изображения отсутствуют, а браузер не показывает никаких сообщений об ошибке? Такая ситуация встречается на WordPress, OpenCart, других CMS и сайтах, разработанных с нуля. Иногда проблема возникает только на определённом устройстве или в одном браузере, а иногда сайт перестаёт работать у всех посетителей.
Белая страница вместо сайта не всегда означает серьёзную поломку сервера. Причиной могут быть ошибка PHP, неисправный плагин, повреждённый шаблон, неправильно работающий JavaScript или даже настройки браузера. Чтобы восстановить сайт, сначала нужно определить, на каком этапе перестаёт загружаться содержимое.
В этой инструкции разберём, почему страница сайта становится белой, как найти причину и что делать владельцу сайта или обычному посетителю. Начнём с простых проверок, для которых не нужны специальные знания, а затем перейдём к диагностике CMS, PHP и серверной части.
Белый экран - это ситуация, когда браузер открывает страницу, но не отображает ожидаемое содержимое. При этом адрес сайта может оставаться в адресной строке, индикатор загрузки исчезает, а сообщение об ошибке не появляется.
Внешне одинаковая белая страница может возникать по совершенно разным причинам:
Важно: белая страница и ошибка 500 - не одно и то же. Сервер действительно может возвращать HTTP 500 из-за внутренней ошибки, но иногда он отправляет статус 200 OK вместе с пустым документом. В других случаях HTML успешно загружается, однако посетитель ничего не видит из-за проблем с отображением страницы.
Прежде чем менять настройки сервера, отключать плагины или переустанавливать CMS, выполните несколько простых действий. Они помогут понять, где искать неисправность, и избежать ненужных изменений.
Нажмите Ctrl + F5 в Windows или Linux либо Command + Shift + R в Chrome на macOS. Такое обновление помогает заново запросить ресурсы страницы, хотя не всегда обходит все уровни кеширования.
Если после обновления сайт открылся, причиной могли быть устаревшие файлы в кеше браузера или временный сбой загрузки.
Откройте приватное окно браузера и перейдите на проблемную страницу. В Chrome для этого можно использовать сочетание Ctrl + Shift + N, в Firefox - Ctrl + Shift + P.
Если в обычном окне сайт белый, а в приватном работает, проверьте кеш, cookies, расширения и данные сайта. Учтите, что некоторые расширения могут работать и в режиме инкогнито, если им предоставлено соответствующее разрешение.
Попробуйте открыть тот же адрес в Chrome, Firefox, Яндекс Браузере или другом установленном браузере. Затем проверьте страницу на смартфоне или другом компьютере.
Если белый экран появляется только в одном браузере, сначала ищите причину в его настройках. Если проблема воспроизводится на разных устройствах, вероятность неисправности сайта или сетевой инфраструктуры становится выше.
Откройте главную страницу, несколько внутренних разделов и другую страницу, которая раньше работала.
Обратите внимание, появляется ли проблема после конкретного действия: авторизации, добавления товара в корзину, отправки формы или перехода по ссылке. Это поможет сузить круг возможных причин.
Если сайт принадлежит вам, установите, когда именно появилась белая страница. Проверьте, выполнялись ли перед этим обновление CMS, установка плагина, изменение шаблона, переход на другую версию PHP, перенос сайта на новый хостинг или изменение настроек сервера.
Последнее изменение не обязательно является причиной сбоя, но его проверка часто позволяет быстрее обнаружить источник неисправности.
Если вы не владелец сайта и не имеете доступа к его административной панели, начните с проверки браузера и подключения к интернету.
Не нужно переустанавливать браузер, сбрасывать все настройки устройства или менять DNS при первом появлении белой страницы. Сначала выясните, воспроизводится ли проблема в других условиях.
Если одинаковый белый экран появляется у всех посетителей, исправить серверную неисправность со своего устройства обычно невозможно. Потребуется вмешательство администратора сайта или хостинг-провайдера.
Этот раздел предназначен для владельцев сайтов и тех, кто занимается их обслуживанием. Инструменты разработчика позволяют выяснить, получил ли браузер содержимое страницы, какой ответ отправил сервер и не возникли ли ошибки при выполнении JavaScript.
В Chrome и большинстве браузеров на Chromium нажмите F12 или Ctrl + Shift + I. На macOS используйте Command + Option + I. Перейдите на вкладку Network («Сеть»), после чего обновите страницу.
Найдите запрос основного HTML-документа. Обычно он содержит адрес открываемой страницы и имеет тип document или Doc.
Откройте сведения о запросе и найдите поле Status Code на вкладке Headers («Заголовки»).
Если браузер показывает белую страницу, но HTML-документ вообще не запрашивается, проверьте адрес, перенаправления, кеш и наличие промежуточных обработчиков, включая service worker.
Выберите запрос основного документа и откройте вкладку Response («Ответ»).
Если ответ пустой или содержит лишь несколько строк, хотя ожидалась полноценная страница, необходимо проверить серверную часть и логи приложения.
Если HTML-код присутствует и содержит необходимые блоки, вероятнее проблема связана с отображением, выполнением скриптов или загрузкой дополнительных ресурсов.
Можно также нажать Ctrl + U для просмотра исходного HTML-кода страницы. Однако для диагностики конкретного запроса удобнее использовать вкладку Network, где одновременно видны статус, заголовки и содержимое ответа.
Перейдите на вкладку Console («Консоль») и обновите страницу. Обратите внимание на ошибки красного цвета.
Например, сообщение Uncaught TypeError может указывать на ошибку JavaScript. Сообщение Failed to load resource означает, что определённый ресурс загрузить не удалось; его HTTP-статус и адрес нужно проверить отдельно.
Не каждое сообщение в консоли связано с белым экраном. Например, ошибка загрузки стороннего счётчика статистики сама по себе не доказывает, что именно она нарушила работу страницы.
Подробную инструкцию по работе с инструментами разработчика можно найти в официальной документации Chrome DevTools.
PHP - язык программирования, на котором работают WordPress, OpenCart и многие другие CMS. Если выполнение PHP-кода завершается критической ошибкой до формирования страницы, посетитель может увидеть пустой экран.
Возможные причины: синтаксическая ошибка в коде, вызов отсутствующей функции, несовместимость модуля с используемой версией PHP, ошибка подключения обязательного файла или исчерпание доступной памяти.
Если показ ошибок на сайте отключён, браузер не всегда отображает объяснение случившегося. В таком случае нужно открыть журнал ошибок PHP и найти запись, совпадающую по времени с неудачной загрузкой.
После установки или обновления расширения может возникнуть конфликт с CMS, темой оформления, другим дополнением или серверным окружением.
Например, модуль может использовать функцию, которая отсутствует в установленной версии PHP, либо обращаться к файлу, который был удалён при обновлении.
Если белая страница появилась сразу после изменения расширения, сначала проверьте его логи и совместимость. При необходимости временно отключите именно этот компонент и повторите проверку.
Шаблон отвечает за формирование внешнего вида страницы. Если в его PHP-коде или подключаемых файлах возникла критическая ошибка, сайт может перестать выводить содержимое.
Другая ситуация: сервер формирует правильную HTML-страницу, но CSS скрывает основной контейнер, устанавливает нулевую прозрачность или располагает поверх страницы пустой белый блок.
Эти случаи требуют разной диагностики: PHP-ошибки ищут в серверных логах, проблемы отображения - через вкладки Elements и Styles инструментов разработчика.
Проблема может появиться после обновления WordPress, OpenCart, Joomla, Drupal, MODX, DLE, другого движка или перехода на новую версию PHP.
Старая тема или модуль могут оказаться несовместимыми с обновлённым программным окружением. Иногда нарушается работа собственного кода, который раньше использовал устаревшие функции.
Не следует сразу откатывать весь сайт к старой версии. Сначала изучите сообщение об ошибке, определите проблемный компонент и проверьте наличие совместимого обновления.
Каждый PHP-процесс использует определённый объём памяти. Если скрипту требуется больше, чем разрешено настройками, его выполнение может завершиться ошибкой.
В журнале PHP в таком случае может появиться сообщение Allowed memory size exhausted.
Увеличение лимита иногда позволяет восстановить работу, однако не устраняет причину чрезмерного потребления памяти. Ею может быть тяжёлый модуль, неправильный запрос к базе данных или ошибка программного кода.
Большинство CMS используют MySQL или MariaDB для хранения страниц, товаров, настроек и другой информации.
Если подключение к базе данных не работает, приложение может показать отдельное сообщение об ошибке, вернуть HTTP 500 либо завершить формирование страницы без видимого содержимого - в зависимости от движка и обработки исключений.
Проверьте доступность сервера базы данных, параметры подключения, существование необходимых таблиц и сообщения в логах.
Сайт может получать некорректную закешированную страницу даже после устранения первоначальной ошибки. Проблема может находиться в кеше браузера, CMS, серверного ускорителя или CDN.
Если при отключении кеширования сайт начинает работать, необходимо определить, какой именно уровень кеша возвращает неправильный ответ, и исправить исходную причину.
На сайтах, где значительная часть интерфейса создаётся JavaScript, ошибка при запуске приложения может оставить посетителю пустую страницу.
На обычном сайте ошибка JavaScript чаще нарушает отдельную функцию, а не удаляет всё содержимое. Однако если отображение основного блока зависит от успешного выполнения скрипта, посетитель также может увидеть белый экран.
CSS, в свою очередь, может скрывать содержимое, делать текст белым на белом фоне или выводить перекрывающий элемент поверх страницы.
На WordPress пустой экран часто называют White Screen of Death, сокращённо WSOD. Он может возникать из-за PHP-ошибок, конфликтов плагинов, неисправной темы или проблем с серверным окружением.
В современных версиях WordPress часть критических ошибок обрабатывается встроенным механизмом восстановления. Вместо белой страницы система может показать сообщение о технической неисправности сайта и отправить администратору письмо с инструкцией по входу в режим восстановления.
Если сайт полностью белый, действуйте последовательно.
Перед изменением файлов и настроек сохраните резервную копию базы данных и файлов сайта. Если у хостинга есть автоматические резервные копии или снимки файловой системы, проверьте дату последней доступной версии.
По возможности проводите диагностику на тестовой копии. На работающем интернет-магазине массовое отключение плагинов может нарушить оформление заказов, оплату и другие функции.
Попробуйте открыть административную панель по адресу https://ваш-домен/wp-admin/.
Если WordPress сообщает о критической ошибке, проверьте электронную почту администратора сайта, включая папку «Спам».
При наличии письма с предложением использовать режим восстановления перейдите по указанной в нём ссылке. В административной панели WordPress можно будет увидеть информацию о проблемном компоненте и попытаться отключить его или исправить ошибку.
Если письмо не пришло, это не исключает критическую ошибку: отправка почты с сервера тоже может не работать. В таком случае продолжайте диагностику через файловый менеджер хостинга или SFTP.
Откройте файловый менеджер хостинга или подключитесь к серверу по SFTP. Найдите файл wp-config.php в корневом каталоге установленного WordPress и сохраните его резервную копию.
Найдите строку define('WP_DEBUG', false); и замените значение false на true.
Дополнительно добавьте следующие параметры, если они ещё не определены в файле:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Важно: параметр WP_DEBUG должен быть определён только один раз. Если строка с ним уже существует, измените её, а не добавляйте второе определение. Все параметры необходимо разместить до строки /* That's all, stop editing! Happy publishing. */ или аналогичного комментария, обозначающего конец настроек. Формулировка комментария зависит от версии и локализации WordPress.
В приведённом примере запись ошибок включена, но вывод сообщений на экран отключён, чтобы посетители не видели технические сведения.
После сохранения файла снова откройте проблемную страницу. Затем проверьте наличие файла wp-content/debug.log.
Найдите записи, совпадающие по времени с появлением белого экрана. Особенно полезны сообщения с указанием Fatal error, Uncaught Error и Parse error.
Пример диагностического сообщения:
PHP Fatal error: Uncaught Error: Call to undefined function example_function() in /path/to/plugin/file.php on line 42Такое сообщение означает, что PHP попытался вызвать несуществующую функцию. В примере путь к файлу помогает определить, в каком компоненте произошла ошибка, а номер строки - найти проблемный участок кода.
Сам факт упоминания плагина в журнале ещё не доказывает, что исправлять нужно именно его: необходимо изучить контекст ошибки, цепочку вызовов и недавние изменения.
Если файл debug.log не появился, проверьте права на запись, настройки журнала PHP и момент возникновения ошибки. Например, сбой может происходить ещё до запуска механизма отладки WordPress. Не создавайте публично доступные файлы с конфиденциальной диагностической информацией.
Подробности приведены в официальной инструкции по отладке WordPress.
Если журнал указывает на конкретный плагин, начните с него. При доступной административной панели откройте раздел «Плагины», временно отключите подозрительное расширение и проверьте работу сайта.
Если административная панель тоже показывает белый экран:
wp-content/plugins/.problem-plugin в problem-plugin-disabled.Если после отключения плагина сайт заработал, проверьте его версию, совместимость с WordPress и PHP, а также конфликты с другими установленными расширениями. При необходимости восстановите работоспособную версию плагина из резервной копии.
Если конкретный компонент неизвестен, на тестовой копии можно временно отключить стандартные плагины, переименовав каталог wp-content/plugins в plugins-disabled. Затем верните исходное название и восстановите необходимые расширения по одному, проверяя сайт после каждого изменения.
Не используйте массовое отключение на работающем интернет-магазине без оценки последствий. Кроме того, этот способ не отключает автоматически все возможные компоненты WordPress: отдельно существуют обязательные плагины из каталога mu-plugins и плагины, которые могут загружаться через специальные серверные настройки.
Если отключение проблемных плагинов не помогло, проверьте тему сайта.
При доступной административной панели перейдите в раздел «Внешний вид» → «Темы» и временно активируйте совместимую стандартную тему WordPress, например одну из установленных тем семейства Twenty Twenty.
После смены темы проверьте главную страницу, внутренние разделы и административную панель.
Если сайт заработал, исследуйте активную ранее тему: ошибки в functions.php, подключаемых PHP-файлах, шаблонах страниц и совместимость с используемой версией PHP.
Если административная панель недоступна, безопаснее сначала определить ошибку по журналам или восстановить доступ через режим восстановления WordPress. Переименование папки активной темы без установленной работоспособной альтернативы может привести к новой ошибке. Поэтому такой способ применяйте только при наличии резервной копии и подходящей темы для замены.
Если белая страница появилась после обновления WordPress или изменения версии PHP, сопоставьте требования ядра, темы и плагинов с установленным серверным окружением.
Если проблема связана с конкретным несовместимым расширением, обновите или исправьте его. Временный возврат к предыдущей версии PHP допустим как диагностическая или аварийная мера, если такая версия доступна и её использование приемлемо с точки зрения безопасности.
Не оставляйте сайт на устаревшей версии PHP только потому, что на ней работает старый плагин. Устраните несовместимость и вернитесь к поддерживаемому программному окружению.
Когда причина обнаружена и сайт работает нормально, верните параметру WP_DEBUG значение false, если постоянная отладка не предусмотрена вашим окружением.
Проверьте, что журнал debug.log не доступен посетителям по прямому URL и не содержит конфиденциальной информации, которую можно получить через интернет. При необходимости переместите архив диагностики в защищённое место и удалите временный журнал из публичного каталога.
Если вместо интернет-магазина на OpenCart открывается белая страница, порядок диагностики зависит от версии движка, установленных расширений и серверного окружения.
Для OpenCart 1.5, 2.x, 3.x и 4.x нельзя использовать одну универсальную схему расположения всех файлов: структура каталогов, механизм расширений и размещение системного хранилища различаются.
Попробуйте открыть главную страницу, каталог, карточку товара, корзину и административную панель.
Если витрина магазина не работает, а административная часть открывается нормально, проверьте шаблон каталога, подключаемые модули и файлы, которые используются только на стороне покупателя.
Если не работает исключительно административная панель, начните с журналов ошибок и компонентов административной части.
Если белая страница появляется везде, проверьте PHP, общие файлы загрузки движка, конфигурацию и серверную инфраструктуру.
При доступной административной панели найдите раздел просмотра журнала ошибок в системных настройках. Его расположение и название могут различаться в зависимости от версии и локализации OpenCart.
Если панель управления не открывается, подключитесь к серверу через SFTP или файловый менеджер хостинга.
В зависимости от версии и настроек журнал может находиться в каталоге system/storage/logs/, в другом расположении системного хранилища либо по пути, определённому настройками конкретной установки.
В OpenCart 1.5 стандартный журнал часто расположен по пути system/logs/error.txt. В более новых установках путь к нему может отличаться, особенно если каталог storage вынесен за пределы публичной директории сайта.
Проверьте также журнал ошибок PHP в панели хостинга: при раннем сбое загрузки движка запись может появиться именно там.
Если белая страница появилась после установки модуля, изменения шаблона или применения OCMOD, проверьте соответствующие файлы и ошибки в журнале.
При доступной административной панели можно временно отключить подозрительное расширение, затем обновить модификаторы и очистить предусмотренный вашей версией OpenCart кеш.
Если панель недоступна, не удаляйте наугад содержимое каталогов system, storage, extension и других системных директорий. Сначала сохраните копию файлов и определите, какие из них относятся к неисправному расширению.
Особенно внимательно проверяйте модификаторы, меняющие общие файлы движка, контроллеры, загрузчик и механизм формирования страниц. Ошибка в таком компоненте может повлиять сразу на несколько разделов магазина.
Если ошибка связана с базой данных, сверьте параметры соединения в конфигурационных файлах установленной версии OpenCart с настройками хостинга. Проверьте доступность сервера базы данных и наличие необходимых таблиц.
Не публикуйте содержимое конфигурационных файлов: в них могут находиться учётные данные для подключения к базе данных и другие секреты.
Если белая страница появилась после смены PHP, проверьте требования именно вашей версии OpenCart, темы и расширений. Старые модули могут использовать функции, изменённые или удалённые в новых версиях PHP.
Исправьте несовместимый компонент, установите его подходящую версию или восстановите работоспособное состояние из резервной копии. Не устанавливайте случайные исправления из интернета без проверки их происхождения и соответствия вашей версии движка.
Общий принцип диагностики остаётся тем же: определить HTTP-статус и наличие HTML, проверить журналы ошибок, установить связь с последними изменениями, затем исследовать конкретный проблемный компонент.
На Joomla и Drupal проверьте журналы движка, системные расширения и совместимость шаблона. На MODX - журнал ошибок, работу сниппетов, плагинов и шаблонов, а также актуальность кеша. На DLE - недавно изменённые модули, шаблоны и настройки PHP.
На самописном сайте определите точку входа приложения, проверьте механизм обработки исключений, маршрутизацию, подключение зависимостей и формирование ответа. Если приложение использует PHP-фреймворк, ищите ошибки также в его собственных журналах.
Не переносите инструкции по переименованию файлов или отключению модулей из одной CMS в другую. У разных движков свои механизмы загрузки компонентов, и случайное изменение системных каталогов может усугубить неисправность.
Если неисправность воспроизводится в разных браузерах и устройствах, а браузер получает пустой ответ или HTTP 500, переходите к диагностике серверной части.
Откройте панель управления хостингом и найдите раздел журналов или ошибок сайта. Если у вас VPS либо выделенный сервер, журналы могут находиться в системе логирования веб-сервера, PHP-FPM или приложения.
Типичные места хранения зависят от операционной системы и конфигурации. Например, журналы Nginx и Apache часто находятся в каталоге /var/log/, но хостинг-провайдер может использовать собственные пути и отдельные логи для каждого сайта.
Сопоставьте время ошибки с моментом загрузки белой страницы. Проверьте также, не выполнялась ли в этот период перезагрузка сервера, обновление ПО, изменение конфигурации или автоматическая задача.
В журнале могут встречаться разные сообщения. Вот что они обычно означают:
Parse error - PHP обнаружил синтаксическую ошибку. Необходимо проверить указанный файл и строку.Uncaught Error - возникла ошибка, которую приложение не обработало. Для определения причины изучите текст сообщения и цепочку вызовов.Allowed memory size exhausted - PHP исчерпал выделенную ему память. Проверьте лимит и фактическое потребление памяти приложением.Maximum execution time exceeded - выполнение скрипта превысило установленное ограничение по времени.Failed opening required - не удалось подключить обязательный файл. Проверьте его существование, путь, доступность и права.Исправлять нужно первопричину, а не просто скрывать сообщение. Например, увеличение лимита выполнения PHP не поможет, если скрипт бесконечно повторяет одну и ту же операцию.
В панели хостинга посмотрите использование оперативной памяти, процессорного времени, доступного места на диске и количество одновременно работающих процессов.
Если диск полностью заполнен, приложение может перестать записывать кеш, временные файлы и журналы. Если сервер испытывает нехватку оперативной памяти, процессы могут аварийно завершаться.
При использовании PHP-FPM проверьте его состояние и журналы, а также наличие свободных обработчиков запросов. Настройки PHP следует менять только после определения причины ошибки и с учётом доступных ресурсов сервера.
Если журнал содержит ошибку подключения к MySQL или MariaDB:
Не изменяйте массово таблицы и не запускайте запросы на восстановление базы без резервной копии. Если есть признаки повреждения данных, сначала определите масштаб проблемы.
Если журнал указывает на невозможность прочитать или подключить определённый файл, проверьте его наличие, владельца и права доступа.
Не устанавливайте права 777 на все файлы и каталоги ради восстановления сайта. Это может создать серьёзные проблемы безопасности и не гарантирует устранения ошибки.
Если неисправность появилась после изменения конфигурации Apache или Nginx, сравните её с предыдущей работоспособной версией. На Apache также проверьте недавние изменения в файле .htaccess, если он используется.
Перед исправлением сохраните копию конфигурации и убедитесь, что новое значение корректно для вашего серверного окружения.
Если в Network основной HTML-документ имеет статус 200 и содержит ожидаемую разметку, не начинайте диагностику с переустановки CMS. Сначала проверьте, почему браузер не отображает уже полученное содержимое.
Особое внимание уделите ошибкам, которые возникли после сборки и публикации новой версии сайта.
Например, старый HTML может ссылаться на JavaScript-файл, который уже удалён при обновлении. Если интерфейс полностью формируется этим скриптом, посетитель увидит пустую страницу, пока не будут исправлены пути и правила кеширования.
На сайтах с React, Vue и другими клиентскими приложениями проверьте ошибки инициализации, маршрутизации и загрузки данных. Сбой при запуске приложения может не позволить ему сформировать пользовательский интерфейс.
Перейдите на вкладку Elements («Элементы») и посмотрите, присутствуют ли в HTML необходимые блоки страницы.
Если содержимое есть, выберите его основной контейнер и проверьте CSS-свойства:
display: none - элемент не участвует в отображении страницы;visibility: hidden - элемент скрыт;opacity: 0 - элемент полностью прозрачен;color: #fff при белом фоне - текст может быть невидимым;z-index и свойства позиционирования - поверх страницы может находиться перекрывающий блок.Также проверьте загрузку файлов стилей и отсутствие незавершённого экрана загрузки.
Например, если анимация загрузки должна скрываться после выполнения JavaScript, но скрипт завершился ошибкой, белый экран загрузки может остаться поверх основного содержимого.
Временно изменяя свойства в инструментах разработчика, можно проверить гипотезу без сохранения изменений на сервере. После подтверждения причины исправьте соответствующий файл CSS или JavaScript и проверьте результат на тестовой копии сайта.
Если HTML ссылается на отсутствующие версии CSS или JavaScript, проверьте кеш страниц, серверный кеш, CDN и настройки публикации статических файлов.
После исправления убедитесь, что посетителям не выдаётся старая HTML-страница с несуществующими ссылками на ресурсы. Очистку кеша выполняйте адресно и только на том уровне, где обнаружена проблема.
Если сайт показывает белый экран на смартфоне, но нормально работает на компьютере, проверьте не только браузер и интернет-соединение, но и мобильную версию самого сайта.
Если проблема возникает в Chrome или другом браузере на Android:
Если другие сайты открываются, а один определённый ресурс показывает белую страницу во всех браузерах, сообщите владельцу сайта об ошибке и укажите модель устройства, версию браузера и адрес страницы.
На iPhone попробуйте открыть сайт в Safari и другом установленном браузере. Проверьте приватную вкладку, другую сеть и наличие обновлений iOS.
Если проблема воспроизводится только на определённом сайте, не нужно сразу сбрасывать настройки iPhone. Сначала установите, влияет ли на загрузку блокировщик контента, сохранённые данные сайта или конкретная мобильная версия страницы.
Владельцу сайта необходимо проверить адаптивный шаблон, мобильные стили, JavaScript и ресурсы, которые подключаются только на небольших экранах.
Если используется отдельная мобильная версия сайта, проверьте её шаблоны и перенаправления. Также убедитесь, что сервер не возвращает некорректную закешированную страницу для определённой группы устройств.
Для предварительной проверки откройте инструменты разработчика на компьютере и включите эмуляцию мобильного устройства. Однако такой режим не полностью воспроизводит работу реального смартфона, поэтому окончательно проверить исправление следует и на физическом устройстве.
Исчезновение белой страницы не означает, что все функции сайта работают правильно. После устранения причины необходимо проверить не только главную страницу, но и основные пользовательские сценарии.
Да. Если поисковый робот получает пустой документ, не видит основное содержимое или регулярно сталкивается с серверными ошибками, это может повлиять на обход, обработку и индексирование страниц.
Особенно важно проверить страницы, которые после сбоя начали возвращать пустой ответ со статусом 200 OK. Успешный HTTP-статус не означает, что поисковая система получила ожидаемый текст страницы.
После восстановления сайта проверьте доступность важных URL, корректность HTTP-ответов, наличие основного содержимого и статистику обхода в Яндекс Вебмастере или Google Search Console, если используете эти инструменты.
Не закрывайте проблемные страницы от индексации и не настраивайте массовые 301-редиректы только ради скрытия технической неисправности. Сначала устраните её причину. Если сайт находится на кратковременном техническом обслуживании и соответствующий ответ действительно уместен, можно использовать HTTP 503 с корректно настроенной страницей обслуживания.
Сервер может не сформировать HTML из-за критической ошибки PHP, вернуть пустой ответ или отправить корректную страницу, содержимое которой скрыто стилями либо не отображается из-за JavaScript. Кроме того, неисправность может возникать только в браузере пользователя. Чтобы определить причину, проверьте HTTP-статус, содержимое ответа и журналы ошибок.
Проверьте сайт в приватном окне, другом браузере и через другую сеть. Если проблема воспроизводится только на вашем устройстве, проверьте кеш, cookies, расширения браузера и сетевые фильтры. Если она наблюдается у определённой группы пользователей, владелец сайта должен также проверить мобильную версию и особенности кеширования.
Обновление могло привести к несовместимости плагина, модуля, шаблона или собственного кода с новой версией CMS или PHP. Найдите сообщения об ошибках, определите неисправный компонент и проверьте совместимость установленных версий.
Причина может находиться в шаблоне главной страницы, используемом только на ней модуле, ошибке загрузки данных или некорректной закешированной версии. Сравните HTTP-ответ главной страницы с ответом работоспособного раздела, затем проверьте различающиеся компоненты.
Вероятно, неисправность затрагивает компоненты, используемые только в публичной части сайта: тему, шаблон каталога, контроллер страницы или подключаемые скрипты. Однако это не исключает серверные ошибки. Начните с проверки журнала и HTTP-ответа проблемной страницы.
Не обязательно. Если причина в неисправном плагине, шаблоне, базе данных, версии PHP или настройках сервера, переустановка ядра может не устранить ошибку. Более того, неосторожная переустановка способна привести к потере изменений. Сначала определите источник неисправности и создайте резервную копию.
Да, если у вас есть доступ к файловому менеджеру хостинга, SFTP, серверным журналам или резервным копиям. Для WordPress, например, можно проверить wp-config.php, журнал ошибок и временно отключить конкретный проблемный плагин переименованием его каталога. Если нет доступа ни к административной панели, ни к файлам, обратитесь к владельцу хостинга или администратору сайта.
Если вместо сайта открывается белая страница, не начинайте с переустановки CMS или массового удаления плагинов. Сначала проверьте сайт в другом браузере и на другом устройстве. Затем определите HTTP-статус и выясните, получил ли браузер HTML-содержимое.
Если сервер возвращает ошибку или пустой ответ, изучите журналы PHP, веб-сервера и приложения. Если HTML загружается, но посетитель видит пустую страницу, проверьте JavaScript, CSS и подключаемые ресурсы. Последовательная диагностика позволяет обнаружить причину и устранить её без лишних изменений.
Не получается восстановить работу сайта самостоятельно? Я занимаюсь диагностикой и исправлением технических ошибок на WordPress, OpenCart, Joomla, Drupal, MODX, DLE и самописных проектах. Могу найти причину белого экрана, исправить программную ошибку, восстановить работу модулей, шаблона и серверной части без полной переделки сайта. Подробнее об услуге - на странице исправления ошибок сайтов.
Переработана структура каталога интернет-магазина на OcStore 1.5.6.4: карточки товаров получили постоянные URL и стабильные хлебные крошки, старые адреса перенаправляются через 301 Redirect, а отдельные товары теперь можно выводить в плитках категорий вместе с подкатегориями.
Переработал страницы онлайн-оплаты туров: убрал устаревшие даты и служебные элементы, сделал кнопку оплаты заметнее и создал единый шаблон для всех направлений.
Пришлите ссылку на сайт и кратко опишите задачу — я посмотрю и предложу следующий шаг.