Главная » WordPress » На сайте возникла критическая ошибка WordPress | Как исправить?
Ошибка, которую вы увидели на экране: «На сайте возникла критическая ошибка WordPress«, полный текст выглядит следующим образом:
На сайте возникла критическая ошибка. Пожалуйста, проверьте входящие сообщения почты администратора для дальнейших инструкций.
Существуют различные другие версии этой ошибки, которые появляются в зависимости от того, какие изменения вы делаете: обновления php, ошибка wordpress install, ошибка при неудачном входе, ошибка при активации woocommerce и т.д.
Начиная с версии WordPress 5, благодаря режиму отладки, на экране появляется сообщение о том, что на сайте возникли технические проблемы. В WordPress 5.2 — 5.3 мы получали сообщение об ошибке «На сайте возникли технические проблемы«. Но в последнем выпуске WordPress 5.4 разработчики WordPress изменили сообщение. В этой статье я рассмотрю, как это исправить.
Существует множество распространенных ошибок wordpress, с которыми вы можете столкнуться, например:
- 500 internal server error,
- 504 Gateway Timeout error,
- 404 Page Not Found ,
- 405 Method Not Allowed Error,
- WordPress File And Folder Permissions Error,
- Error Establishing a Database Connection in WordPress,
- White Screen of Death (WSOD) Error и многие другие. Я подробно рассматривал все эти ошибки в других статьях моего блока.
Содержание
- Что означает эта критическая ошибка WordPress?
- Как исправить критическую ошибку в WordPress?
- Включите режим отладки в WordPress
- WordPress обновление PHP до версии 7.4 или выше
- Проверка версии PHP в WordPress
- Устранение проблем, связанных с конфликтом тем
- Устранение проблем, связанных с конфликтом плагинов
- Исправление ошибочных пользовательских кодов
- Вывод
- Нужна помощь от эксперта по WordPress?
Что означает эта критическая ошибка WordPress?

WordPress 6.1.1 имеет встроенную функцию, которая обнаруживает, когда плагин или тема вызывают фатальную ошибку на сайте. Она уведомляет вас об этом автоматическим письмом. Такого рода проблемы генерируют PHP FATAL ошибки. Фатальные ошибки возникают, когда PHP перестает работать и требует, устранение неполадки, прежде чем вы сможете завершить процесс.
Существует довольно много причин, по которым вы можете столкнуться с критической ошибкой в WordPress, поэтому постарайтесь вспомнить, каким было ваше последнее действие.
- Вы установили или удалили плагин?
- Вы активировали или деактивировали плагин?
- Загрузили, активировали или деактивировали новую тему?
- Вносили ли вы какие-либо изменения в веб-хостинг?
- Обновляли ли вы что-либо через FTP?
- Обновляли ли вы версию PHP?
CMS WordPress и некоторые из активных плагинов требуют использования большого количества памяти, либо на сайте много одновременных посещений, может возникнуть высокое потребление памяти PHP. Если потребности в памяти превысят установленные лимиты, на сайте возникнет ошибка: «На сайте произошла критическая ошибка WordPress«.
Эта ошибка является очень общей и не несет никакой информации, поскольку она показывается всем пользователям, которые просматривают сайт. Поэтому логично, что в целях безопасности она не показывает больше информации.
При фатальной ошибке ваш запрос не может быть выполнен. Вместо того чтобы показывать сломанные страницы с многочисленными ошибками, WordPress теперь показывает приличный экран. Вот и все.
Для отладки фактической возникшей ошибки и ее причины необходимо активировать режим отладки в WordPress. Далее я объясню, как это сделать.
Как исправить критическую ошибку в WordPress?
Включите режим отладки в WordPress
Войдите на свой сайт с помощью FTP и проверьте журналы ошибок. Если это не поможет, попробуйте включить режим отладки.

Существует несколько вариантов активации режима отладки в WordPress. Один из самых быстрых и эффективных — изменить файл wp-config.php, который будет находиться в корне нашего сайта. Для этого подключитесь к файлам сайта по FTP и откройте файл wp-config.php из корневой папки WordPress в текстовом редакторе. Найдите следующие строки и отредактируйте добавив следующие строки:
|
define(‘WP_DEBUG’, true); define( ‘WP_DEBUG_LOG’, true ); define( ‘WP_DEBUG_DISPLAY’, false ); @ini_set( ‘display_errors’, 0 ); |
Измените значения false на true и сохраните. Теперь, когда вы обновите страницу сайта, вы можете увидеть другие ошибки, которые могут дать вам лучшее понимание того, откуда исходит ошибка. Вы также можете проверить журналы отладки через FTP. Не забудьте вернуть значение false после завершения работы.
Возможно, файл уже содержит некоторые из этих строк, если это так, проверьте, что они одинаковые, и оставьте одну из них WP_DEBUG_LOG. Сохраните изменения в файле wp-config.php, и с этого момента WordPress будет записывать в этот файл любое предупреждение, уведомление или ошибку, возникающую на сайте. Расположение будет в папке wp-content/debug.log
Предыдущими строками мы указываем WordPress сохранять возможные ошибки, которые могут возникнуть, в файле debug.log и не показывать их на экране.
Это настоятельно рекомендуется, чтобы не показывать конфиденциальную информацию пользователю, который переходит на наш сайт. Если мы разрабатываем сайт и он еще не опубликован, то можем выводить ошибки на экран.
Как только активировали режим отладки, можем загрузить или прочитать файл напрямую /www/wp-content/debug.log, который будет иметь содержание, аналогичное следующему:

В зависимости от уровня журнала он покажет нам предупреждения, уведомления, ошибки или все вместе. В нашем случае он покажет все уровни журнала. В основном сосредоточимся на строках, которые начинаются с «PHP Fatal error» или «Error», которые являются теми ошибками, которые могут привести к тому, что веб-страница не будет показана пользователю.
Существуют и другие уровни ошибок, но эти — самые важные. Теперь давайте узнаем, как решить эту проблему, обновив версию PHP.
WordPress обновление PHP до версии 7.4 или выше
WordPress написан на языке PHP, и ваш хостинг устанавливает его версию.
Прежде чем приступить к обновлению версии PHP, мы настоятельно рекомендуем вам сделать резервную копию вашего сайта и базы данных. В случае если что-то пойдет не так, вы сможете восстановить сайт из резервной копии.
Как и при обновлении WordPress, плагинов и тем, также важно обновить PHP WordPress до последней версии. Есть две причины, по которым вам необходимо обновить версию PHP.
- Сайт WordPress будет работать быстрее
- Новая версия PHP более эффективна. Вы можете увеличить производительность вашего сайта в 3-4 раза.
Также сайт будет более безопасным. WordPress — самая популярная CMS, построенная на PHP. Следовательно, хакерам легко взломать сайт wordpress. Обновив PHP, вы получите новейшие функции безопасности, которые отсутствуют в предыдущей версии PHP. Поэтому очень важно обновить PHP до последней версии.
Проверка версии PHP в WordPress
Чтобы проверить текущую версию PHP, вы можете создать новый файл, допустим serverinfo.php. Теперь отредактируйте этот файл и добавьте в него следующий код. После этого запустите файл, и он предоставит вам всю информацию о системе, на которой работает ваш сервер.
|
<?php phpinfo(); // Функция информации о версии php |
Устранение проблем, связанных с конфликтом тем
Для этого просто активируйте тему по умолчанию, например, Twenty Twenty или выше.
К сожалению, поскольку ваш сайт отображает ошибку, вам придется устранять неполадки с помощью файлового менеджера вашего хостера (например, файлового менеджера cPanel) или использовать FTP или sFTP (это защищенная версия FTP).
Важно отметить, что при смене темы вы не потеряете настройки выбранной темы.
Для этого переименуйте папку с активной темой, добавив в конце названия папки DISABLE или DISABLED. Например, если вы используете Twenty Nineteen и папка называется «twentynineteen «, вы назовете ее «twentynineteenDISABLE» или «twentynineteenOLD». Вернитесь в верхнюю часть сайта и обновите страницу.
Цель — посмотреть, исчезнет ли ошибка. Если не исчезнет, то это что угодно, но не тема.
Устранение проблем, связанных с конфликтом плагинов
Если дело не в теме, это может быть проблема с плагином. В некотором смысле, поиск и устранение неисправностей схожи. Однако гораздо проще переименовать папку плагина в «pluginsOFF». Посетите сайт и войдите в систему. Это приведет к закрытию всех плагинов. Обратите внимание, что это не удалит первоначальные настройки этих плагинов, так как они сохранятся, когда вы снова включите их позже.
После того, как плагины будут отключены, вернитесь и переименуйте папку в начальный вид «plugin». Зайдите в админку WordPress и снова включите каждый из них по очереди, пока не появится сообщение «На сайте возникла критическая ошибка».
Когда вы обнаружили проблему, вам, вероятно, нужно восстановить объект или модуль, который ее вызвал. Вы можете сделать это несколькими способами.
Скачайте оригинальные файлы плагина прямо из каталога плагинов WordPress и замените плагин через Файловый менеджер вашего хостера (или cPanel) или через FTP или sFTP.
Использовать плагин WP Rollback для восстановления плагина до предыдущей версии.
Если вы используете WP Rollback, есть несколько версий на выбор. Он подскажет вам, какая версия у вас установлена. Выберите плагин для восстановления. Нажмите на «Rollback», если он доступен в списке плагинов в вашем администраторе WordPress.
Исправление ошибочных пользовательских кодов
Если ничего из вышеперечисленного не помогло, то ни плагины, ни темы не являются виновниками, и следующее, что нужно сделать, это проверить, не имеют ли какие-либо из ваших пользовательских кодов несовместимости с текущей версией WordPress, темы, плагинов или PHP.
Чтобы исправить это, просто удалите пользовательские коды из файла functions.php темы или из того места, куда вы их добавляли, и проверьте, нет ли больше критических ошибок WordPress.
Если критические ошибки исправлены, то вы уже знаете, что виновником является:
- Ваш пользовательский код.
- Или версия PHP, из-за проблем с совместимостью между ними.
Вывод
Увидеть сообщение «На сайте возникла критическая ошибка WordPress» может показаться тревожным сигналом, но теперь она предупреждает вас и даже предлагает ссылку, по которой можно узнать, как отладить такие ошибки WordPress.
Кроме того, сайт WordPress отправит вам электронное письмо с инструкциями, а иногда даже активирует режим восстановления WordPress.
Если вы не получили письмо от WP, вы можете посмотреть в журналы сервера и получить запись, связанную с этой проблемой?
Это также может помочь вам найти решение. Вы можете получить доступ к журналу ошибок через FTP или cPanel, зайдя в корневой каталог установки WordPress. Вы также можете поговорить с вашим хостинг-провайдером, чтобы узнать, где хранятся журналы ошибок, так как у каждого хостера они разные.
Нужна помощь от эксперта по WordPress?
Нет технических знаний? Поможем исправить. На вашем веб-сайте произошла критическая ошибка? Свяжитесь с нами прямо сейчас и мы мгновенно исправим проблемы с WordPress.
Большинство пользователей интернета знакомы с ошибками, которые иногда возникают при работе с сайтом или поиске той или иной информации в поисковых системах. Если вы являетесь владельцем сайта, который вдруг начал выдавать подобные ошибки, вам важно понимать, что они означают, причину их возникновения и способ их устранения.
Часто на различных форумах в интернете можно увидеть обсуждения на тему устранения ошибок на сайте. Порой возникшие проблемы незначительны и могут быть решены пользователем самостоятельно, без обращения к специалистам.
Для того, чтобы знать, что делать в непредвиденной ситуации, стоит познакомиться с описанием самых распространенных ошибок, а также прочитать руководство по их устранению.
Типы ошибок
Ошибки протокола HTTP возникают в том случае, если веб-сервер по какой-то причине не может успешно отправить пользователю запрашиваемый документ. В этом случае сервер сообщит пользователю в HTTP-заголовке код возникшей ошибки.
Коды ошибок бывают положительными и отрицательными или успешными и не успешными.
Всего существует 4 типа кодов (хх — сочетание любых цифр):
- 2xx — запрос выполнен успешно;
- 3xx — запрос успешно перенаправлен (тоже положительный код);
- 4xx — ошибка — документ не был отправлен пользователю, так как произошла критическая ошибка. Класс кодов 4xx предназначен для указания ошибок со стороны клиента;
- 5xx — ошибка сервера — критическая ошибка на сервере. Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера.
Наибольший интерес для владельца сайта представляют коды, указывающие на ошибки со стороны клиента или сервера. Причины возникновения и способы устранения данных ошибок представлены ниже.
Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей
Подписаться
Ошибка 400
Bad Request
При переходе на сайт браузер может выдавать “400 Bad Request”. Это означает, что сервер обнаружил синтаксическую ошибку в запросе, который ввел пользователь. Однако подобная ошибка может появляться не только, когда вы вводите адрес сайта, но и, например, при входе в панель управления вашим сайтом. Причин возникновения может быть несколько:
- блокировка браузера антивирусом;
- блокировка брендмауэра Windows браузером;
- большое количество файлов cookies и данных в сache;
- перебои в работе интернета.
Для того, чтобы определить, какой из перечисленных вариантов относится к вашей ситуации, необходимо провести проверку каждого из них до полного устранения проблемы. Начнем с первой возможной причины.
Блокировка браузера
- Изучите настройки вашего антивируса в разделе под названием “Правила для приложений” или схожим с ним.
- Проверьте, есть ли ваш браузер в списке, и каков уровень доверия к нему.
- Повысьте уровень доверия к вашему браузеру, если он низкий.
- Сохраните новые настройки и попробуйте снова зайти в панель управления.
Если ошибка сохраняется, то переходите к проверке следующей причины.
Блокировка брендмауэра Windows
- Попробуйте отключить брендмауэр на время: меню Пуск — Панель управления — Система и безопасность — Брандмауэр Windows — Включение и отключение.
- Очистите кэш и куки.
- Обновите страницы с ошибкой.
- Если проблема устранена, то для завершения добавьте в брандмауэр разрешенные программы: Пуск — Панель управления — Система и безопасность — Брандмауэр — Разрешение запуска программы через брандмауэр.
Если проблема осталась — продолжайте проверку.
Cache и cookies
- Удалите cookies и очистите cache: нажмите Shift + Ctrl + Delete в то время, когда браузер открыт.
- Удалите ненужные файлы.
- Проверьте работу вашего браузера.
Перебои в работе интернета
- Свяжитесь со своим интернет-провайдером и узнайте, проводятся ли у них какие-то работы.
- Уточните, сколько времени займут работы.
Ошибка 403
Forbidden
Ошибка 403 означает, что сервер не может выполнить запрос из-за запрета на доступ к запрашиваемым файлам или страницам. Эта ошибка может возникать по ряду причин. Рассмотрим самые распространенные:
- Индексный файл index.html не загружен в директорию public_html вашего сайта или является некорректным. Для устранения этой ошибки создайте файл с именем index.html или переименуйте уже имеющийся файл. Возможные варианты для имени файла: index.html, index.htm или index.php.
- Для директории, в которой находится запрашиваемый файл, установлены такие права, что веб-сервер Apache не смог прочитать файл на диске сервера. Для устранения этой ошибки попробуйте изменить права доступа в разделе, отвечающем за настройку прав.
- Файлы сайта загружены в неправильную директорию. Для устранения этой ошибки проверьте, располагаются ли файлы сайта в директории site/public_html, где site — название вашего сайта.
Ошибка 404
Not Found
Ошибка 404 означает, что сервер не может найти данные по запросу пользователя.
Причины возникновения данной ошибки:
- Некорректный URL, введенный в адресное поле браузера. Для устранения данной ошибки проверьте, корректно ли указана ссылка.
- Файл, запрашиваемый по URL, отсутствует на сервере. Для устранения этой ошибки необходимо проверить наличие запрашиваемого файла в директории public_html вашего сайта.
Ошибка 500
Internal Server Error
Ошибка 500 означает, что на сервере есть внутренняя ошибка. Эта проблема может возникнуть по двум причинам:
- Невозможно запустить скрипт. Скорее всего, указаны неправильные права доступа на папки и файлы. Если на PHP файлы скриптов, размещенных на вашем хостинге, стоят права доступа 777, то исполнение данных скриптов может быть заблокировано сервером. Происходит это из-за того, что права доступа 777 позволяют всем производить любые изменения с данным файлом, что существенно влияет на безопасность и целостность вашего сайта. Для устранения этой ошибки следует проверить права доступа на папки и файлы сайта. Для папок рекомендовано установить права доступа 755, для исполняемых скриптов 600, а для всех остальных файлов 644.
- Неправильная инструкция в файле .htaccess или наличие в нём неподдерживаемых директив. Возможно, вы ошиблись в написании названия нужной директивы или параметров к ней. Данную ошибку можно устранить, включив лог ошибок error.log. Веб-сервер укажет вам, какую конкретно директиву он посчитал ошибочной — ее нужно будет исправить.
Ошибка 502
Bad Gateway
Данная ошибка — результат запроса, при котором был получен недопустимый ответ от сервера. Причин возникновения проблемы может быть несколько:
- Проблемы в работе прокси-сервера. Для устранения этой ошибки попробуйте набрать в адресной строке браузера ссылку на какой-либо другой сайт. Тем самым вы можете проверить, есть ли доступ в Интернет вообще. Если вы обнаружили, что доступ в Интернет есть, но ваше обращение к конкретному сайту все равно дает ошибку 502, попробуйте удалить файлы cookies в браузере.
- Нехватка ресурсов сервера. Это может означать, что нагрузка на сервер превышает ресурсы, доступные на выбранном тарифе хостинга. Уточните у своего хостинг-провайдера информацию о тарифах с большим объемом ресурсов и, в случае необходимости, увеличьте оперативную память или доступный объем диска.
Ошибка 503
Service Temporarily Unavailable
У каждого аккаунта на сервере хостинга есть определенное количество рабочих процессов, выделенное в соответствии с выбранным тарифным планом. Работа с запросами ведется в порядке очереди, они поступают на сервер, где легкие запросы обрабатываются мгновенно, а тяжелые – медленно. Всякая очередь ограничена тем или иным количеством запросов. Если новый запрос находится за пределами этой границы, принят он не будет, и вместо результата браузер выдаст оповещение “Сервис временно недоступен”.
Чтобы исправить данную ошибку нужно знать причины, по которым она может появляться:
1. Зависание скриптов при передаче больших статичных файлов через PHP. Скрипты работают определенное время, а не постоянно. При окончании времени работы скрипта прерывается передача файла, соответственно, файл не будет передан полностью, а также запрос оставит процесс веб-сервера работать еще длительное время. Устранить ошибку вы сможете посредством следующих шагов:
- Проверить все компоненты и плагины вашей CMS, отключая их по очереди, и найдите самые тяжёлые или испорченные, при работе которых загрузка сайта замедляется. По возможности откажитесь от таких компонентов или поищите более быстрый аналог.
- Проверить наличие у вас медленных запросов — в папке logs вашего аккаунта создается файл mysql-slow.log. Информация в этом файле обновляется раз в сутки и содержит только самые проблемные SQL-запросы.
- Если в PHP-скриптах используются Include-функции, загружающие части движка, расположенные на одном аккаунте, убедитесь, что в них используется локальный путь, а не URL вида «http://…». Наличие URL заставляет сервер делать дополнительный HTTP-запрос — это занимает лишнее время и сильно замедляет загрузку сайта.
2. Большое количество запросов к серверу. Причин возникновения таких запросов несколько:
- Загружаемый ресурс разбит/содержит ссылки на слишком больше число файлов (картинки, таблицы стилей JS-скрипты), которые подгружаются через отдельные запросы. В этом случае следует объединить ресурсы в один файл, где это возможно.
- DDoS-атаки, флуды, спамы в комментарии также могут вызывать большое количество запросов. В случае DDoS-атаки необходимо определить ее тип, и, согласно ее уровню, предпринять действия по устранению. Подробнее про DDoS-атаки вы можете прочитать в статье «DDoS-атаки: взгляд со стороны Timeweb».
Когда на вашем веб-сайте отображается “Белый экран смерти” со страшным сообщением “На этом веб-сайте произошла критическая ошибка” может показаться, что это было на вашем сайте. К счастью, еще не все потеряно, и есть несколько способов исправить это.
Продолжайте читать, пока мы’ Мы собрали лучшие методы для устранения этой ошибки и мгновенного восстановления работоспособности вашего сайта.
Сбой, из-за которого весь ваш веб-сайт и, возможно, серверная часть отображаются в виде белой страницы, может вызывать беспокойство. WordPress сообщает о наличии проблемы следующим сообщением: “Произошла критическая ошибка” и проверить электронную почту администратора для получения дополнительных инструкций. Помимо легкой паники, это сообщение может заставить вас задуматься о том, что может быть причиной этого.
В целом критические ошибки в WordPress вызываются следующими причинами:
- Проблема с PHP
- Превышен лимит памяти
- Неисправный плагин, тема или код
- Плагин конфликтует с другим
- Поврежденная база данных
На вашем сайте может возникать несколько ошибок. Понимание того, что они означают, облегчает устранение неполадок.
- “HTTP 502 Bad Gateway:” Проблема с сервером, вызванная перегрузкой посетителей.
- “Служба HTTP 503 недоступна:” Проблема с сервером.
- “500 Внутренняя ошибка сервера:” Это еще одна критическая ошибка, обычно вызванная повреждением файла сервера.
- “Ошибка установления соединения с базой данных:” Эта проблема может быть вызвана поврежденной базой данных или сервером базы данных.
- “ERR_CACHE_MISS:” Кэш вашего веб-сайта или инструменты PHP, такие как плагины, скорее всего, вызовут эту проблему.
- “ERR_CONNECTION_TIMED_OUT:” Ошибка может возникнуть из-за перегрузки или медленной работы веб-сервера.
Если вы получаете какие-либо другие странные ошибки, вы можете проверить их значение, используя это руководство по кодам ошибок WordPress HTTP.
Как исправить критическую ошибку WordPress
Вот наиболее распространенные способы устранения неполадок советы по восстановлению вашего веб-сайта.
Активировать режим отладки в WordPress
Первое, что нужно сделать при решении проблемы с WordPress, — активировать функцию отладки. При включенном режиме отладки вы увидите различные ошибки PHP, возникающие на вашем сайте. Эту информацию можно использовать для поиска основной причины.
Если вы не можете получить доступ к панели управления, вам потребуется включить журнал отладки, чтобы собрать все ошибки PHP. Выполните следующие действия, чтобы получить доступ к журналу отладки и включить отладку.
- Подключитесь к своему сайту с помощью FTP.

- Найдите файл “wp-config-php” через корневую папку и откройте ее с помощью IDE или текстового редактора.

- Скопируйте и вставьте следующий код перед последним сообщением, затем сохраните и закройте файл.

define(‘WP_DEBUG’, true ); определить(‘WP_DEBUG_DISPLAY’, ложь); определить(‘WP_DEBUG_LOG’, true );
Все ошибки для вашего сайта теперь будут записываться в журнал “debug.log” файл, найденный в папке “wp-content” папку.
Пройдитесь по ошибкам, чтобы найти названия установленных плагинов или тем или ссылки на определенные файлы, указывающие на наличие проблемы.
После того, как вы закончите просматривать журнал, удалите строки кода из “wp-config-php” файл.
Восстановить резервную копию сайта
Откат вашего сайта до последней резервной копии может быть быстрым и простым способом устранения ошибок WordPress. Этот совет не дает стопроцентной гарантии решения проблемы, но попробовать стоит. Если проблема возникнет снова, возможно, будет проще определить причину.
Восстановление веб-сайта зависит от процесса резервного копирования. Если вы используете плагин резервного копирования, следуйте документированным инструкциям. Если ваш хостинг-провайдер включает резервные копии, вы можете восстановить их с панели управления хостингом.
Отключить все плагины
Плагины обычно виноваты в критической ошибке WordPress. Найти проблемный может быть сложно, если на вашем сайте установлено несколько плагинов. Быстрый способ узнать, является ли проблема плагином, — отключить их все, чтобы увидеть, исчезнет ли проблема. Если это так, включайте их по одному, пока не найдете тот, который снова нарушает работу сайта.
Выполните следующие действия, чтобы отключить, а затем включить ваши плагины.
- Войдите в панель управления WordPress.

- Выберите “Плагины” и “Установленные подключаемые модули”

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

- Нажмите “Массовые действия” затем “Деактивировать” Это должно разрешить все конфликтующие плагины и восстановить ваш сайт.

Вы также можете удалить плагины, чтобы удалить связанные с ними файлы. Однако вам потребуется переустановить их или восстановить резервную копию.
Выберите параметр «Активировать» под каждым подключаемым модулем, чтобы включить его. После каждого проверяйте, не вернулась ли критическая ошибка. Как только вы найдете виновника, удалите его и найдите замену или найдите информацию о проблемах совместимости с плагином.
Вернуться к теме по умолчанию
Конфликтующая тема также может стать причиной критических ошибок. Проверьте, так ли это, временно переключив свою тему на тему по умолчанию, например “Twenty Nineteen” «Двадцать двадцать» или «Двадцать двадцать один». Если проблема связана с темой, это должно решить ее немедленно.
Сначала убедитесь, что у вас есть резервная копия, чтобы было проще вернуть все файлы темы. Переустановка вашей темы может не включать ваш индивидуальный стиль.
Выполните следующие действия, чтобы переключиться на тему по умолчанию.
- Войдите в панель инструментов WordPress.

- Перейдите к разделу “Внешний вид” затем “Темы.”

- Нажмите текущую тему, чтобы выберите его, затем в правом нижнем углу всплывающего окна нажмите “Удалить”

- Если возможность удалить тему недоступна, попробуйте загрузить и изменить тему на тему WordPress по умолчанию.
Увеличьте лимит памяти PHP
Даже если тема или плагин вызвал сбой вашего веб-сайта, фактической причиной часто является ограничение памяти PHP.
Ваш веб-сервер будет иметь определенный объем памяти или ОЗУ. WordPress ограничивает объем памяти, который может использовать PHP-скрипт. Белый экран и сообщение о критической ошибке будут отображаться, если этот предел превышен.
Установка слишком высокого предела памяти приведет к тому, что неправильно настроенные скрипты замедлят работу вашего сайта, но значение может быть слишком низким. Небольшое увеличение лимита PHP может исправить ситуацию мгновенно.
Выполните следующие действия, чтобы увеличить лимит PHP.
- Зайдите на свой веб-сайт через FTP.

- Откройте файл “wp-config.php” файл.

- Скопируйте и вставьте следующий код перед последней строкой, затем сохраните.
define(‘WP_MEMORY_LIMIT’, ‘128’ );
Если это не так, устраните ошибку, попробуйте ограничить память “256M” Все, что выше этого, является чрезмерным, если это явно не указано в документации плагина.
Обновите версию PHP
Старые версии PHP могут вызывать критические ошибки. На вашем сайте должна быть установлена последняя версия PHP, поддерживаемая WordPress.
Некоторые пользователи WordPress предпочитают как можно дольше использовать старые версии PHP из-за проблем с совместимостью плагинов. Если на вашем веб-сайте используется PHP 5.x, обновление необходимо как можно скорее, поскольку конфликты могут быть серьезными. Обновления PHP имеют большое значение, поэтому обязательно сделайте резервную копию перед обновлением.
Все хостинговые компании WordPress позволяют легко обновить версию PHP. Вот как это делается в Bluehost.
- Войдите в панель управления Bluehost.

- Выберите “Дополнительно” вкладку слева.

- На странице “Дополнительные инструменты” нажмите кнопку “МультиPHP-менеджер” icon.

- На следующей странице нажмите “Версия PHP” Стрелка раскрывающегося списка, чтобы выбрать версию PHP, которую вы хотите обновить.

- Нажмите “Применить.”

Очистить кэш веб-сайта
Хотя кеширование — лучший способ ускорить ваш сайт, иногда кеш может быть поврежден. Простая очистка кеша удалит застрявшие и поврежденные файлы, после чего ваш сайт будет работать как положено. Не нужно беспокоиться об удалении кеша вашего веб-сайта, так как кешированная версия ваших страниц восстанавливается, поэтому ваш сайт может продолжать быстро загружаться.
Различные хостинг-провайдеры будут использовать аналогичные шаги для очистки кеша веб-сайта через панель инструментов. . Bluehost упрощает это, предоставляя опцию в области администрирования WordPress. Следующие шаги помогут вам понять, как это делается.
- Войдите в панель управления WordPress.

- Перейдите в раздел “Кэширование” на панели инструментов вверху.

- Выберите “Очистить все .”

Bluehost немедленно удалит файлы из вашего кэш веб-сайта.
Проверить наличие вредоносного ПО
Вредоносное ПО также может вызывать критические ошибки на веб-сайтах и может быть причиной в этом сценарии, если вы заметите странные скрипты PHP, которые вы не можете отследить до темы или плагина. Если вы заблокированы на своем веб-сайте, вы не сможете запустить сканирование. Кроме того, может быть трудно определить, является ли файл законным или был добавлен вредоносным ПО. Вредоносное ПО также может изменять файлы PHP, что вы можете не заметить, если только вы не разработчик.
Если вы считаете, что причиной критической ошибки может быть вредоносное ПО, обратитесь за помощью к своему веб-хостингу.
Верните свою домашнюю страницу
Нет ничего более тревожного, чем видя сообщение “На этом веб-сайте произошла критическая ошибка” сообщение вместо вашей прекрасной домашней страницы при посещении вашего сайта. Если ваш веб-сайт приносит вам деньги, его быстрое восстановление является приоритетом. Хотя критическая ошибка может показаться концом света, существует множество способов ее решения.
Обычно виновата проблемная тема или плагин, что быстро устраняется отключением плагина или временным изменением тема. Также известно, что обновление до последней версии PHP помогает. Обязательно создайте резервную копию своего сайта, прежде чем пытаться исправить что-либо, чтобы при необходимости было проще вернуться к вашим индивидуальным настройкам.
Ваш сайт работает должным образом? Если да, то что вы делали, чтобы сбросить ошибку? Расскажите нам об этом в разделе комментариев ниже.
Ссылка на хостинг: Сегодня поговорим об ошибках на WordPress. На сайте возникла критическая ошибка WordPress — разбираем эту и другие ошибки WordPress!
Решение проблемы с белым экраном.
На сайте возникла критическая ошибка WordPress — разбираем эту и другие ошибки WordPress! В этом видео покажем, что …

Ошибка WordPress: белый экран. На сайте возникла критическая ошибка WordPress

Критическая ошибка на сайте WordPress

Как исправить – на сайте возникли временные проблемы технического характера WordPress

Как создал сайт и не наполняю… | Критическая ошибка на сайтах WordPress. ВАЖНО!!!

ТОП 5 ошибок WordPress и их решения

Ошибка 500 Internal Server Error: что это значит и как исправить

Ошибки WordPress | Топ 3 способа их исправить.

Как решить проблемы в здоровье сайта WordPress: Curl error 28, Operation timed out и др.

Плагин для решения проблем на вашем сайте WordPress

Как исправить 🎅 ошибку добавления и редактирования статей заметок на сайте WordPress Сделать сайт

белый экран на сайте wordpress как исправить

Как исправить ошибку Internal Server Error в WordPress?
Еще читайте: Как заставить работать кнопку «Добавить медиафайл» в WordPress.
ТОП 5 ошибок WordPress по моему мнению, с которыми сталкиваются владельцы сайтов.
Занимаюсь разработкой WordPress c 2016 года, автор нескольких плагинов и шаблонов. Участвую в развитии сообщества WP на GitHub.
При работе с WordPress вебмастеру иногда приходится сталкиваться с трудностями, ошибками, которые следует оперативно исправлять. В этой статье мы рассмотрим одну из таких проблем, которая иногда возникает при работе с WordPress. Появляется сообщение “На сайте возникла критическая ошибка”, что делать, как решить это и как восстановить работу сайта.

Оглавление
- 1 Сообщение в WordPress “На сайте возникла критическая ошибка”
- 2 Поиск проблемы в плагинах
- 3 Поиск проблемы в теме
- 4 Восстановление сайта из резервной копии
Проблема характеризуется тем, что сообщение о критической ошибке появляется при обращении к любой странице сайта: в панели управления и фронтэнду. То есть сайт не работает вообще, ни одну страницу нельзя посетить. Это затрудняет решение проблемы, ведь зайти в консоль, чтобы изменить настройки, теперь невозможно.
Если сайт уже продвигается в поиске и индексируется, то появляется необходимость решить эту проблему как можно быстрее. Потому что если индексирующий робот посетит сайт, когда он недоступен, это негативно скажется на продвижении.
Как правило, сообщение в WordPress “На сайте возникла критическая ошибка” появляется после того, как вы что-то изменили на сайте, установили какой-то плагин или тему, или поменяли их настройки. Также она может появиться после выполнения одного из обновлений.

Поиск проблемы в плагинах
Если вы думаете, что делать, если видите сообщение “На сайте возникла критическая ошибка”, то первым делом проверьте плагины, потому что это самая частая причина. В этом сообщении также говорится о том, что нужно проверить почту администратора сайта для подробной информации об ошибке. Поэтому зайдите на свою почту и найдите это письмо (оно может попасть в папку “Спам”). В письме может быть указанно, какой именно плагин вызывал проблему. Зная название плагина, вы можете удалить его.
Чтобы удалить плагин, не имея доступа к консоли WordPress, обратитесь к файловому менеджеру. который есть в панель управления любого хостинга. В файловом менеджере в корневой папке вашего сайта откройте папку wp-content/plugins. В этой папке хранятся файлы всех плагинов. Если по пришедшему письму вы поняли, какой плагин вредит, то удалите здесь его папку – она будет называться примерно так же, как и плагин. После удаления проверьте наличие ошибки и скорее всего сайт восстановится.
Если письмо с отчётом об ошибке вам не пришло или из него не понятно, какой именно плагин в этом виноват, то придётся пойти более долгим путём. Сначала определите, что это вообще вина плагина. Для этого переименуйте саму папку wp-content/plugins, например, назвав её plugins1 (имя не имеет значения, главное, чтобы оно было не plugins и чтобы потом вы могли легко вернуть прежнее имя). Это действие деактивирует все плагины на сайте.
После этого проверьте, доступен ли сайт. Если критическая ошибка в WordPress осталась, значит дело не в плагине. Тогда верните папке plugins прежнее имя. Если ошибка пропала, значит дело в плагине, и тогда тоже верните папке plugins прежнее имя, затем откройте её и переименуйте папку каждого из установленных плагинов, добавляя к его имени лишний символ. После каждого такого переименования проверяйте доступность сайта. Когда вы измените имя папки плагина, который вызывает проблему, вы отключите его и тогда сайт заработает. Так вы выясните, какой плагин виноват. Не забудьте вернуть прежние имена плагинам, которые не виноваты в этой проблеме.
Виновный плагин удалите, удалив его папку из каталога plugins. И подберите ему замену, если нуждаетесь в его функционале.
Поиск проблемы в теме
Тема также может стать источником проблемы, если “На сайте возникла критическая ошибка” в WordPress и делать в этом случае следует примерно то же, что и при проверке плагинов. Кстати, если письмо на почту администратора всё-таки пришло, то из него, возможно, будет понятно, что дело именно в теме.
Так как доступа в консоль нет, зайдите в файловый менеджер хостинга и из корневой папки откройте каталог wp-content/themes. В ней хранятся все темы, установленные на сайте – каждая в своей папке. Вызывать проблему может только активированная тема, а активированной может быть только одна тема. Поэтому по названию найдите папку той темы, которая сейчас активирована на сайте и переименуйте её, добавив один лишний символ к имени. Затем проверьте доступность сайта.
Зайти на фронтэнд не получится, потому что активная тема после переименования деактивировалась. Поэтому сразу заходите в консоль. Если она доступна, значит дело в теме. Удалите её папку из файлового менеджера. Если консоль также не доступна и появляется уведомление о том, что на сайте появилась критическая ошибка, то дело не в активированной теме, тогда верните папке темы прежнее имя, убрав лишний добавленный символ.
Если проблема всё-таки в теме, то замените её на другую. Несмотря на то, что после удаления активированной темы, фронтэнд сайта не работает, в консоли можно как и раньше найти, установить и активировать любую тему и тогда сайт начнёт нормально работать не только из панели управления.
Восстановление сайта из резервной копии
Этот способ позволит быстро восстановить работу сайта на WordPress, если появилось сообщение “На сайте возникла критическая ошибка”. Каждый нормальный хостинг делает резервную копию сайта, обычно раз в сутки. Поэтому восстановите сайт из бекапа, который создал хостинг на ту дату, когда проблемы ещё не было.
После этого сайт восстановит работу и вы сможете управлять им как и прежде. Вероятно, вы проделаете какие-то действия, которые снова приведут к критической ошибке на WordPress – обновите плагин или тему, измените настройки или сделаете что-то ещё. Тогда запомните, после какого именно вашего действия появляется сообщение “На сайте возникла критическая ошибка”, восстановите сайт из резервной копии снова и больше не делайте это действие.
Конечно, не делать обновления плагинов или тем недопустимо. Тогда лучше отказаться от продуктов, которые вызывают проблему и поменять их на альтернативные.
Если вы являетесь владельцем сайта, который вдруг начал выдавать подобные ошибки, вам важно понимать, что они означают, причину их возникновения и способ их устранения.
Часто на различных форумах в интернете можно увидеть обсуждения на тему устранения ошибок на сайте. Порой возникшие проблемы незначительны и могут быть решены пользователем самостоятельно, без обращения к специалистам.
Для того, чтобы знать, что делать в непредвиденной ситуации, стоит познакомиться с описанием самых распространенных ошибок, а также прочитать руководство по их устранению.
Типы ошибок
Ошибки протокола HTTP возникают в случае, если веб-сервер по какой-то причине не может успешно отправить пользователю запрашиваемый документ. В этом случае сервер сообщит пользователю в HTTP-заголовке код возникшей ошибки.
Коды ошибок бывают положительными и отрицательными или успешными и не успешными.
Всего существует 4 типа кодов (хх — сочетание любых цифр):
- 2xx — запрос выполнен успешно
- 3xx — запрос успешно перенаправлен — тоже положительный код.
- 4xx — ошибка — документ не был отправлен пользователю, так как произошла критическая ошибка. Класс кодов 4xx предназначен для указания ошибок со стороны клиента.
- 5xx — ошибка сервера — критическая ошибка на сервере. Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера.
Наибольший интерес для владельца сайта представляют коды, указывающие на ошибки со стороны клиента или сервера. Причины возникновения и способы устранения данных ошибок представлены ниже.
Ошибка 400 — “Плохой запрос”
При переходе на сайт браузер может выдавать “400 Bad Request”. Это означает, что сервер обнаружил синтаксическую ошибку в запросе, который ввел пользователь. Однако, подобная ошибка может появляться не только когда вы вводите адрес сайта, но и, например, при входе в панель управления вашим сайтом. Причин возникновения может быть несколько:
- Блокировка браузера антивирусом
- Блокировка брендмауэра Windows браузером
- Большое количество файлов cookies и данных в сache
- Перебои в работе интернета
Для того, чтобы определить, какой из перечисленных вариантов относится к вашей ситуации, необходимо провести п проверку каждого из них до полного устранения проблемы. Начнем с первой возможной причины.
Блокировка браузера
- Изучите настройки вашего антивируса в разделе под названием “Правила для приложений” или схожим с ним.
- Проверьте, есть ли ваш браузер в списке и каков уровень доверия к нему
- Повысьте уровень доверия к вашему браузеру, если он низкий
- Сохраните новые настройки и попробуйте снова зайти в панель управления
Если ошибка сохраняется, то переходите к проверке следующей причины.
Блокировка брендмауэра Windows
- Попробуйте отключить брендмауэр на время: меню Пуск — Панель управления — Система и безопасность — Брандмауэр Windows — Включение и отключение
- очистите кэш и куки
- обновите страницы с ошибкой
- Если проблема устранена, то для завершения добавьте в брандмауэр разрешенные программы: Пуск — Панель управления — Система и безопасность — Брандмауэр — Разрешение запуска программы через брандмауэр.
Если проблема осталась — продолжайте проверку.
Cache и cookies
- Удалите cookies и очистите cache: нажмите Shift + Ctrl + Delete в то время, когда браузер открыт.
- Удалите ненужные файлы
- Проверьте работу вашего браузера
Перебои в работе интернета
- Свяжитесь со своим интернет-провайдером и узнайте, проводятся ли у них какие-то работы
- Уточните, сколько времени займут работы
Ошибка 403 — Доступ запрещен
Ошибка 403 означает, что сервер не может выполнить запрос из-за запрета на доступ к запрашиваемым файлам или страницам. Эта ошибка может возникать по ряду причин. Рассмотрим самые распространенные:
- Индексный файл index.html не загружен в директорию public_html вашего сайта или является некорректным. Для устранения этой ошибки создайте файл с именем index.html или переименуйте уже имеющийся файл. Возможные варианты для имени файла: index.html, index.htm, или index.php.
- Для директории, в которой находится запрашиваемый файл, установлены такие права, что веб-сервер Apache не смог прочитать файл на диске сервера. Для устранения этой ошибки попробуйте изменить права доступа в разделе, отвечающем за настройку прав.
- Файлы сайта загружены в неправильную директорию. Для устранения этой ошибки проверьте, располагаются ли файлы сайта в директории site/public_html, где site — название вашего сайта.
Ошибка 404 — Файл не найден
Ошибка 404 означает, что сервер не может найти данные по запросу пользователя.
Причины возникновения данной ошибки:
- Некорректный URL, введенный в адресное поле браузера. Для устранения данной ошибки проверьте, корректно ли указана ссылка.
- Файл, запрашиваемый по URL, отсутствует на сервере. Для устранения этой ошибки необходимо проверить наличие запрашиваемого файла в директории public_html вашего сайта.
Ошибка 500 — Внутренняя ошибка сервера
Ошибка 500 означает, что на сервере есть внутренняя ошибка. Эта проблема может возникнуть по двум причинам:
- Невозможно запустить скрипт. Скорее всего указаны неправильные права доступа на папки и файлы. Если на PHP файлы скриптов, размещенных на вашем хостинге, стоят права доступа 777, то исполнение данных скриптов может быть заблокировано сервером. Происходит это из-за того, что права доступа 777 позволяют всем производить любые изменения с данным файлом, что существенно влияет на безопасность и целостность вашего сайта. Для устранения этой ошибки следует проверить права доступа на папки и файлы сайта. Для папок рекомендовано установить права доступа 755, для исполняемых скриптов 600, а для всех остальных файлов 644.
- Неправильная инструкция в файле .htaccess или наличие в нём неподдерживаемых директив. Возможно, вы ошиблись в написании названия нужной директивы или параметров к ней. Данную ошибку можно устранить, включив лог ошибок error.log. Веб-сервер укажет вам, какую конкретно директиву он посчитал ошибочной — ее нужно будет исправить.
Ошибка 502 — Bad Gateway
Данная ошибка — результат запроса, при котором был получен недопустимый ответ от сервера. Причин возникновения проблемы может быть несколько:
- Проблемы в работе прокси-сервера. Для устранения этой ошибки попробуйте набрать в адресной строке браузера ссылку на какой-либо другой сайт. Тем самым вы можете проверить, есть ли доступ в Интернет вообще. Если вы обнаружили, что доступ в Интернет есть, но ваше обращение к конкретному сайту все равно дает ошибку 502, попробуйте удалить файлы cookies в браузере.
- Нехватка ресурсов сервера. Это может означать, что нагрузка на сервер превышает ресурсы, доступные на выбранном тарифе хостинга. Уточните у своего хостинг-провайдера о тарифах с большим объемом ресурсов и, в случае необходимости, увеличьте оперативную память или доступный объем диска.
Ошибка 503 — Service Temporarily Unavailable
У каждого аккаунта на сервере хостинга есть определенное количество рабочих процессов, выделенное в соответствии с выбранным тарифным планом. Работа с запросами ведется в порядке очереди, они поступают на сервер, где легкие запросы обрабатываются мгновенно, а тяжелые – медленно. Всякая очередь ограничена тем или иным количеством запросов. Если новый запрос находится за пределами этой границы, принят он не будет и вместо результата браузер выдаст оповещение “Сервис временно недоступен”.
Чтобы исправить данную ошибку нужно знать причины, по которым она может появляться:
- Зависание скриптов при передаче больших статичных файлов через PHP. Скрипты работают определенное время, а не постоянно. При окончании времени работы скрипта прерывается передача файла, соответственно файл не будет передан полностью, а также запрос оставит процесс веб-сервера работать еще длительное время. Устранить ошибку вы сможете посредством следующих шагов:
- Проверить все компоненты и плагины вашей CMS, отключая их по очереди, и найдите самые тяжёлые или испорченные, при работе которых загрузка сайта замедляется. По возможности откажитесь от таких компонентов, либо поищите более быстрый аналог.
- Проверить наличие у вас медленных запросов- в папке logs вашего аккаунта создается файл mysql-slow.log. Информация в этом файле обновляется раз в сутки и содержит только самые проблемные SQL-запросы.
- Если в PHP-скриптах используются Include-функции, загружающие части движка, расположенные на одном аккаунте, убедитесь, что в них используется локальный путь, а не URL вида «http://…». Наличие URL заставляет сервер делать дополнительный HTTP-запрос — это занимает лишнее время и сильно замедляет загрузку сайта.
- Большое количество запросов к серверу. Причин возникновения таких запросов несколько:
- Загружаемый ресурс разбит/содержит ссылки на слишком больше число файлов (картинки, таблицы стилей JS-скрипты), которые подгружаются через отдельные запросы. В этом случае следует объединить ресурсы в один файл, где это возможно.
- DDoS-атаки, флуды, спамы в комментарии так же могут вызывать большое количество запросов. В случае DDoS-атаки, необходимо определить ее тип, и, согласно ее уровню, предпринять действия по устранению. Подробнее о том, что необходимо делать, если ваш сайт под DDoS-атакой, мы писали в одной из статей нашего блога.
Действия при появлении ошибки
Перечисленные ошибки могут возникать довольно часто, поэтому знание причин их возникновения и способов устранения помогут вам самостоятельно решить появившуюся проблему, экономя время на ожидании ответа и поиска причины технической поддержкой.
Выберите надежный и мощный хостинг.
Ошибки в работе сайта могут возникать по разным причинам. Иногда они вызваны неточностями в коде, ненастроенной адаптивностью, плохой оптимизацией загрузки страницы и т. д. Все ошибки так или иначе влияют на посещаемость и продвижение сайта, что негативно сказывается на объеме продаж и монетизации.
Для поиска и устранения сбоев чаще всего используют автоматизированные средства. Это могут быть встроенные инструменты Google и Яндекс, а также ПО сторонних производителей. О том, какие ошибки в работе сайта наиболее распространены, как их найти и устранить, вы узнаете из нашего материала.
Основные ошибки в работе сайта
Случаи, когда при переходе по ссылке вместо ожидаемой страницы сайта появляется сообщение о проблеме и трехзначный цифровой код, может припомнить каждый пользователь. Для собственника ресурса это крайне неприятная ситуация, ведь он теряет посетителей. На какие ошибки в работе сайта указывают эти цифры и что предпринять, чтобы они не появлялись впредь?
В первую очередь разберемся, что скрывается за трехзначными кодами. При попытке перейти на страницу на сервер отправляется HTTP-запрос, каждому из которых присваивается код состояния. Он состоит из трех цифр, причем первая означает принадлежность к одному из пяти классов:
- 1**: информационные;
- 2**: успешные;
- 3**: перенаправления;
- 4**: ошибки на стороне клиента;
- 5**: ошибки на стороне сервера.
С четверки начинаются коды, свидетельствующие о проблемах на стороне пользователя – неполадки браузера или опечатки в ссылках. Однако не исключено, что источник ошибки – сам сайт. Если первая цифра кода 5, это говорит о невозможности сервера обработать запрос пользователя.
Большое количество отказов посетителям сайта следует воспринимать как повод разобраться в причинах такой ситуации и принять меры к избавлению от проблемы.
Ошибки в работе сайта со стороны клиента
400: Bad Request
Когда сервер не может распознать пользовательский запрос, он присваивает ему код 400. Чаще всего это происходит из-за неправильных настроек браузера.
Исправляется ошибка несколькими способами:
- Если она вызвана повреждением файлов cookie, поможет очищение кэша и cookies.
- Когда причина – во внутренней ошибке браузера, его достаточно переустановить или просто обновить.
- При банальной опечатке (например в консольных командах wget или curl) проблема решается верным вводом запроса.
401: Unauthorized
Появляется при попытке войти на сайт или его отдельные страницы без действительного идентификатора и пароля. Речь идет о ресурсах, доступ к которым открывается после авторизации. Пользователь может допустить опечатки в логине или указать неверный пароль. Сервер отвечает отказом, пока учетные данные не будут написаны правильно.
В редких случаях сообщение об этой ошибке в работе сайта сохраняется даже при верных логине и пароле. Это значит, что администратору стоит проверить целостность файла .htpasswd, где хранятся данные пользователей для успешного входа на веб-сайт.
403: Forbidden
Пользователю отказано в посещении ресурса, отдельной страницы или файла из-за отсутствия доступа.
Причин может быть несколько:
- Права на открытие файла не предоставлены. Проверить, что это не ошибка, можно при помощи команды chmod.
- Ограничение доступа конкретным адресам в файле .htaccess.
- В запрашиваемой директории отсутствует индексный файл. Для исправления надо включить в конфигурации сервера листинг директорий.
404: Not Found
Появляется, когда сервер не обнаруживает ресурс, соответствующий запросу. Искомая страница может быть удалена, но иногда ошибка с кодом 404 возникает, когда ресурс на самом деле существует.
В этом случае стоит поискать опечатки в ссылке. Кроме того, у пользователя может не быть доступа к директории с искомым файлом. Для исправления ошибки добавляется разрешение на чтение и выполнение для каталога.
Ошибки в работе сайта со стороны сервера
500: Internal Server Error
Если сбой не относится к другим кодам, начинающимся с пятерки, ему присваивается комбинация 500. Такой набор цифр указывает на проблему, связанную с настройками сервера.
Чтобы обнаружить причину неполадки, проверяют:
- Нет ли ошибок в файле .htaccess. Для этого его переименовывают и убеждаются в работоспособности сайта.
- Все ли необходимые пакеты в наличии и насколько верно выбрана версия PHP. При необходимости ее меняют и добавляют отсутствующие модули.
- Код сайта. Возможно, ошибка кроется в нем, и восстановление сайта из резервной копии исправит ситуацию.
502: Bad Gateway
Регулярное появление этого кода – повод для обращения в службу поддержки хостинг-провайдера. Чтобы специалистам было проще понять, в чем причина неполадок, подробно опишите, в результате каких действий появляется сообщение об ошибке, а также в какое время это происходит.
503: Service Unavailable («Сервис недоступен»)
Такая ошибка в работе сайта связана с превышением лимита на HTTP-запросы. Убедиться в этом позволит тщательное изучение технических характеристик хостинга. Излишнее количество обращений часто вызвано тем, что код, формируя страницу, запрашивает очень много изображений, стилей и другие файлы.
Чтобы исправить ошибку, можно внести коррективы в код и тем самым снизить количество запросов или сменить тариф хостинга, выбрав более производительный.
504: Gateway Timeout
Код свидетельствует об истечении времени ожидания сайтом ответа от сервера. Как правило, на это отводится 300 секунд.
Причина чаще всего заключается в том, что выполнение скриптов сайта занимает очень много времени, например, при выгрузке баз данных. Преодолеть это препятствие помогает обращение к сайту напрямую, через порт 8081 (если ресурс работает на панели управления ISPmanager) или 8080 (для cPanel и Plesk). Интервалы ожидания можно настроить вручную на VPS.
Поиск и исправление некоторых ошибок в работе сайта
В первую очередь при словах «ошибки сайта» представляются неполадки с визуальным образом страниц: верстка и расположение изображений не соответствует задумке веб-мастера, в мобильном приложении ресурс выглядит непривычно из-за отсутствия адаптации, а в некоторых браузерах отражаются не все элементы оформления. Но этим проблемы не исчерпываются.
1. Визуальные проблемы сайта
У подавляющего большинства пользователей установлен Chrome, включая работающий на его движке браузер Opera. Следовательно, прежде всего необходимо убедиться, что сайт правильно отображается именно в Chrome. Исключить визуальные проблемы в других браузерах поможет Browser Shots.
Популярность мобильных устройств постоянно растет, все чаще для просмотра ресурсов применяются смартфоны, поэтому наличие любых недочетов приведет к потере значительной части аудитории. Проверить, насколько удачно сайт адаптирован к мобильным устройствам, можно с помощью WebPageTest и Cross Browser Testing.
Эти инструменты по итогам проверки представляют скриншоты страниц, где сразу заметны отклонения от задуманного веб-мастером оформления («поехала» верстка, сдвинулось изображение и т. д.).
Есть еще один подход к приведению сайта в надлежащий вид – добиться соответствия страниц стандартам, которые отвечают за визуальную составляющую, – HTML, CSS, WCAG.
Правда, если используется кроссбраузерная верстка, привести ресурс в соответствие с CSS не получится. Но даже отсутствие расхождений с протоколами HTML и WCAG гарантирует беспроблемную работу сайта, как с технической стороны, так и с точки зрения удобства для пользователей.
Чтобы проверить ресурс на соответствие стандарту HTML, задействуются возможности сервиса validator.w3.org, а убедиться, что сайт не противоречит WCAG, можно с помощью сервиса AChecker. По итогам проверки вы получите перечень технических ошибок, исправление которых избавит от визуальных проблем.
2. Ненайденные ресурсы
Под этим названием скрывается целых блок технических ошибок в работе сайта, негативно сказывающихся на таких показателях, как поисковое продвижение, юзабилити и конверсия. К ненайденным ресурсам относятся: «битые» ссылки, обнаруженные поисковиками или посетителями сайта; ошибки разработки, когда ресурсы, необходимые для просмотра страниц, отсутствуют полностью; структурные ошибки, которые могут проявиться не сразу, а спустя некоторое время. Примеры таких проблем – внутренние редиректы или «битая» ссылка в динамическом меню.
Выявить «битые» ссылки лучше до того, как это сделает поисковый робот и примет соответствующие меры, плохо влияющие на продвижение ресурса. Обнаружить такую проблему позволят отчеты Google Webmasters или Яндекс.Вебмастер. Ошибки разработки можно найти, проанализировав логи посещаемости (access.log). Доступ к логам сайта получают в панели хостинг-провайдера или облачном сервисе, а затем подключают возможности AWStats или аналогичной программы.
Отыскать структурные ошибки возможно только в ходе проверки ресурса вручную или с помощью сервисов для сканирования сайта типа Xenu. Кстати, это позволит выявить и отдельные недочеты из первых двух групп.
Исправление ошибок этого блока осуществляется по-разному и зависит от особенностей сайта, но в целом действия направлены на устранение общих причин, по которым не обнаруживаются некоторые ресурсы:
- Определенная доля ошибок разработки вызвана отсутствием иконок сайта (apple-touch-icon.png, apple-touch-icon-precomposed.png, browserconfig.xml и т. д.). Еще одной причиной возникновения проблем являются промахи разработчика при сборке сайта. Веб-мастер может не предусмотреть фоновые изображения для элементов управления, JavaScript-библиотеки или файлы стилей, используемых сторонними модулями. Исправляются «битые» ссылки либо перемещением ресурса в нужное место на хостинге, либо удалением вызова из требуемого файла. Кроме того, ошибки этого типа могут появиться в результате неправильного автоматического наименования изображений или ресурсных файлов.
- После устранения недочетов, относящихся к «битым» ресурсам, необходимо решить проблему «битых» ссылок внутри сайта. Они могут быть обнаружены пользователями (ошибка 404 из панели Google и Яндекса), поисковыми роботами или по итогам проверки по логам. Для исправления придется просмотреть каждый случай и поставить нужные страницы. В результате пользователи при переходе по ссылке будут видеть именно тот раздел сайта, который изначально предусматривался веб-мастером, а поисковики смогут учитывать вес «битой» страницы. Затем формируются правила редиректов для всего перечня неправильных и правильных страниц через .htaccess, конфигурацию nginx или инструментами системы управления сайтом.
- К структурным относятся не столь распространенные ошибки, связанные с пагинацией или разделами меню. Чтобы устранить их, дорабатывают шаблон сайта, вносят коррективы в настройки или внутренние модули. Встречаются и проблемы, обусловленные перемещением разделов сайта, когда ссылка ведет на прежнее место его размещения. Кроме того, ошибки могут быть вызваны несоответствием протоколу, когда осуществляется вызов ресурса по http:// с редиректом на https:// .
Исправление недочетов этой группы при всех прочих плюсах позволит снизить нагрузку на хостинг. Как правило, эти страницы не кэшируются, а при попытках системы управления сайтом подобрать идентичную страницу ресурсы хостинга расходуются чрезмерно.
3. Проблемы скорости сайта
Долгое ожидание отклика негативно сказывается на репутации ресурса, пользователь может покинуть его, чтобы перейти на веб-страницы, работающие быстрее. Проверить показатель скорости на этапе запуска поможет сервис Google PageSpeed Insights.
Возможно, что сайт тормозит из-за проблем с сервером. Исправив ошибки такого типа, вы значительно ускорите открытие страниц и избавите посетителей от томительного ожидания.
При необходимости можно прибегнуть к глубокой диагностике скорости, задействовав возможности сервисов Айри.рф или WebPageTest.
6 критических ошибок в коде сайта
Правильность отображения страниц ресурса в браузере и степень ее оптимизации зависят от нескольких факторов, но к числу критических можно отнести шесть ошибок. О каждой из них расскажем подробно.
Перечень критических ошибок в работе сайта выглядит так:
- Доступность страниц ресурса для индексирования
- <!DOCTYPE>
- Адаптивность
- Наличие viewport
- h1 на странице
- Подзаголовки страницы
Наличие этих недочетов приводит к тому, что поисковые роботы совсем не могут индексировать страницу или сталкиваются при этом с серьезными затруднениями. Кроме того, такие ошибки отрицательно сказываются на отображении сайта в разных браузерах.
Определить, есть ли такие проблемы на вашем ресурсе, несложно. Код страницы в любом браузере (на приведенном ниже примере это Google Chrome) можно увидеть, нажав F12 или комбинацию кнопок Ctrl+Shift+I.
HTML-код будет виден в открывшемся окне.
Расскажем, как обнаружить в нем критические ошибки.
1. Открыт ли сайт или страница для индексирования
После открытия файла ВашДомен/robots.txt проверяем, есть ли у поисковиков доступ к странице. User-agent * показывает, для какого робота указанные в robots.txt правила действительны, а Disallow подтверждает запрет на индексирование некоторых разделов или страниц.
Например, посмотрим на ВашДомен/catalog/. Наличие в файле robots.txt конструкции типа Disallow: /catalog/ говорит о том, что поисковым роботам запрещено индексировать страницу. Для исправления ошибки конструкцию убирают. Код Disallow: / также подлежит удалению, поскольку он препятствует индексации всего сайта.
Затем нажимаем F12, получаем доступ к HTML-коду страницы. Комбинацией Ctrl+F вызываем поле для поиска.
В появившейся строке вводим:
- <meta name=“robots”
и начинаем искать ошибки. Если они обнаружены, строка примет вид:
- <meta name=“robots” content=“noindex,nofollow”> или <meta name=“robots” content=“noindex”>,
Для исправления недочетов удаляем ее или меняем на
- <meta name=“robots” content=“index,follow”>
2. <!DOCTYPE>
Этот элемент содержит описание версии HTML-разметки, использованной в текущем документе. Отсутствие <!DOCTYPE> приводит к тому, что код перестает быть валидным. Это приводит к тому, что браузеры самостоятельно трактуют версию HTML-кода, в результате это может стать причиной некорректного отображения страниц вашего ресурса.
3. Адаптивность
Пользователи просматривают сайт на разных устройствах, и на каждом из них страницы должны выглядеть нормально, все элементы должны быть доступны, текст и изображения – помещаться в текущее окно. Для этого веб-ресурс проверяют на соответствие стандарту адаптивности, благодаря соблюдению которого любой посетитель не испытывает никаких затруднений при знакомстве с сайтом.
Существует несколько способов добиться адаптивности страниц интернет-ресурса:
- Использование гибкого макета на базе сетки (англ. flexible, grid-based layout);
- Работа с медиазапросами (англ. media queries);
- Bootstrap (front-end framework).
Убедиться в том, что ваш сайт адаптирован к различным браузерам, очень просто, не понадобится даже открывать HTML-код. Просто внесите изменения в размеры окна и посмотрите, как отреагируют на это элементы страницы.
Ширина окна 1024 px:
Ширина окна 768px:
Важно, чтобы сайт корректно воспринимался пользователями мобильных устройств. Для проверки этого показателя подходит Google Mobile Friendly (Google Search Console), который находится по адресу https://search.google.com/test/mobile-friendly.
Чтобы убедиться в адаптированности ресурса к экранам разных размеров, вводим полный URL в строку и меньше чем через минуту видим результат проверки.
4. Наличие viewport
Кроме того, необходимо запустить по коду поиск метатега
- <meta name=»viewport» content=»width=device-width, initial-scale=1″>,
который выполняет функцию оптимизации сайта для гаджетов.
5. H1 на странице
Присутствие и содержание тега заголовка имеет решающее значение для занятия сайтом наиболее выгодной позиции в результатах поиска. Заголовок h1 должен отвечать двум требованиям:
- быть единственным на странице;
- в него должны быть вписаны ключевые слова.
Недостаточно тщательный подход к формулированию заголовков приводит к серьезным проблемам с индексацией и даже к наложению санкций со стороны поисковых систем. Тег h1 очень важен с точки зрения SEO-продвижения, ведь в нем содержатся сведения о тематике страницы.
Для более полного охвата аудитории в заголовок h1 помещается фокус-ключ, это помогает объяснить и поисковику, и пользователям, какую информацию они найдут на странице.
6. Подзаголовки страницы
Для разметки подзаголовков в коде применяются специальные теги h2…h6. В этих кодах содержится важная для поискового робота информация о том, что страницу можно включать в результат поиска по ключевому слову. Подзаголовки привлекают дополнительное внимание поисковиков и благотворно сказываются на продвижении страницы.
Чтобы проверить наличие заголовков h2…h6, заходим в код страницы и вводим в поиск <h2. Не обнаружили h2 – не критично, но если на странице вообще отсутствуют заголовки в диапазоне h2–h6, это повод срочно исправить ошибку и добавить ключевое слово.
Самыми распространенными являются следующие недочеты:
- Присутствие логотипа страницы в теге заголовка. Чаще всего это относится к некоторым шаблонам, включая предлагаемые наиболее популярными сервисами;
- Служебные элементы страницы («Корзина», «Авторизация», «Форма обратной связи» и т. д.) помечены тегами подзаголовков;
- В подзаголовках нет ключевых слов;
- В их оформлении присутствуют стили, которые необходимо вынести в файлы .css.;
- Пример кода со стилями:<h2 class=»section-header» style=»margin: 2rem 0 10rem; text-align: center;»>Преимущества работы с нами</h2>
- Пример чистого кода:<h2 class=»section-header»>Преимущества работы с нами</h2>
А еще лучше:<h2>Преимущества работы с нами</h2>
Все перечисленные проблемы в равной степени имеют отношение и к тегу заголовка h1.
Инструменты разработчиков для поиска ошибок в работе сайта
Сложилась определенная последовательность действий, направленных на исправление обнаруженных в ходе тестирования веб-ресурса недочетов. Найденные ошибки в работе сайта, информация от пользователей, запросы на улучшения становятся предметом продолжительных переписок между сторонами или обсуждаются на личных встречах.
Все это серьезно замедляет работу, ведь каждый отчет должен быть изучен, зафиксирован и задокументирован, по каждому необходимо принять решение, обозначить меры по исправлению и поставить задачу перед разработчиком.
С точки зрения повышения эффективности оптимальным способом является моментальное получение обратной связи от клиента и оперативное реагирование прямо в процессе доработки веб-ресурса.
К счастью, сегодня отпала необходимость выполнять массу ненужных действий, чтобы сообщить о найденной ошибки. Не надо вручную делать скриншоты и сохранять данные. Заказчики, тестировщики и пользователи благодаря встроенным интерфейсам могут отправлять автоматически сгенерированные отчеты, высказывать замечания по дизайну и предлагать изменения прямо из браузера. Экономится время, которое раньше тратилось на длительные совещания и согласования каждой правки.
Еще одно преимущество современных инструментов состоит в том, что у всех участников работы над проектом есть одновременный доступ к новому сайту. Это упрощает и ускоряет процесс исправления ошибок, особенно если осуществлена интеграция с сервисами Basecamp, Trello или GitHub.
Поговорим более подробно о самых популярных инструментах.
- Usersnap
- BugHerd
- Redline
Создатели Usersnap называют свой сервис «отчетом об ошибках для всех работающих над веб-проектами». Приступить к работе над своим ресурсом можно в несколько кликов, достаточно вставить скопированный сниппет на JavaScript или добавить расширение для браузера Chrome или Firefox.
На вашей странице появится кнопка «Feedback», клик по которой открывает доступ к панели с множеством инструментов, предназначенными для оставления комментариев в виде изображений и текстов.
Отдельно стоит упомянуть такой полезный инструмент Usersnap, как Console Recorder. Он позволяет зафиксировать и сохранить ошибки и другие сведения, представляющие ценность для разработчика веб-ресурса.
Сервис интегрируется с Asana, Basecamp, GitHub.
Ежемесячная плата варьируется в зависимости от набора функций от $19 до $99. Чтобы объединить возможности Usersnap с другими сервисами, придется внести еще минимум $49 в месяц.
Пользователи, испытавшие возможности этого сервиса, по достоинству оценили старания разработчиков, которые довели процесс направления сообщений об ошибках в работе сайта до совершенства. BugHerd тоже можно инсталлировать в качестве сниппета на JavaScript или подключить расширение для браузера.
Мастер установки сделает процесс простым и понятным, никаких проблем у новых пользователей не возникает.
Интерфейс сервиса располагается в боковой панели браузера. Чаще других используется кнопка «+». С ее помощью можно оставить комментарий к любому элементу HTML на странице.
Чтобы облегчить визуализацию статуса задачи, в арсенале сервиса предусмотрены цветные маркеры.
Прямо в процессе изучения проекта веб-ресурса можно определить, кто отвечает за исправление ошибок.
Отправка отчета об ошибке автоматически инициирует создание новой карточки, доступной из интерфейса администратора сервиса.
Создателями BugHerd предусмотрена возможность его интеграции с Basecamp, GitHub, Campfire и еще некоторыми инструментами для управления проектами, за исключением Trello.
Чтобы оценить преимущества использования BugHerd в процессе работы над веб-сайтом, потребуется внести ежемесячную плату в размере $29, если число пользователей не превышает пяти. Максимальная сумма $180 разрешает одновременное участие в проекте 50 членов команды.
Возможности этого сервиса представлены двумя полезными инструментами – комментирование и оставление меток.
Схема работы проста: обнаружив ошибку в работе сайта, заказчик или тестировщик отправляет сообщение. Вторая сторона общения (исполнитель, разработчик) получает уведомление, в котором содержится ссылка на страницу со скриншотом и описанием выявленных недочетов.
Существенным минусом Redline можно считать доступ к сообщениям, открытый для всех желающих.
Можно объединить возможности сервиса с функционалом Basecamp, Trello, Jira, GitHub.
Использование Redline обойдется минимум в $19 ежемесячно, причем даже самый недорогой тариф включает поддержку по SSL и неограниченное число проектов. Подписчики плана Enterprise могут применять такие функции, как API, настройки безопасности и подсветка элементов.
Современные инструменты для обратной связи значительно упростили процедуру направления сообщений о найденных ошибках. Теперь не приходится делать подробное описание багов и пожеланий по их устранению. Обнаруженный недочет помечается маркером на странице и сопровождается кратким комментарием.
Каждый из описанных сервисов имеет свои преимущества.
У Usersnap максимально понятный интерфейс, предусмотрена возможность интеграции с двумя десятками сторонних сервисов. Кроме того, есть функция предоставления дополнительной информации о сессии работы.
В BugHerd реализован собственный аккуратный стиль организации сообщений об ошибках, «Канбан». Кроме того, отдельной похвалы заслуживает сервис управления сообщениями об ошибках.
Redline удобен для фрилансеров, поскольку больше нацелен на однопользовательскую работу с проектом. Командную деятельность на базе этого сервиса организовать можно путем интеграции с другим инструментом управления.
От появления ошибок в работе сайта не застрахован даже опытный веб-мастер. Главное, уметь своевременно обнаруживать допущенные промахи и оперативно принимать меры по их устранению.
Современные сервисы серьезно облегчают процесс выявления недочетов и позволяют наладить взаимодействие в ходе создания и совершенствования веб-ресурса. Отсутствие ошибок в его работе – признак заботы о пользователях, а для поисковых роботов – повод лучше ранжировать сайт, продвигая его в топ выдачи.
Сайты на WordPress не отличаются высокой стабильностью. И вебмастер просто обязан разбираться в технических нюансах. Критические ошибки, после которых невозможно даже на сайт зайти, периодически случаются.
Например, после очередной попытки установки/ обновления плагина может появиться такое сообщение:

После чего зайти на сайт или админ панель невозможно. Что делать?
📌 Знай свои учетные данные
Первое, нужно быть уверенным, что у тебя есть все учетные данные (логины и пароли) от всех сервисов. Электронная почта, хостинг, домен, сам WordPress. Сам адрес электронной почты на сайте должен быть актуальным, а у тебя должен быть доступ к почтовому ящику.
Записывать логины и пароли, делать эти записи «видимыми» с нескольких устройств, дело не безопасное. Но потерять учетные данные или доступ к почте может серьезно осложнить любую проблему.
🔨 Обратись в техподдержку
Самый простой и безопасный способ решения технических проблем — обратиться в техподдержку хостинга, на котором размещен твой сайт. Это гарантия, как минимум, не усугубить возникшую проблему. И на хорошем хостинге техники должны быстро отвечать на запросы.
Важно! Техподдержка не должна просить твои учетные данные. А вот потребовать от тебя быть залогиненым на хостинге, само собой разумеющееся. Плюс общаться с тобой могут по указанной почте.
💾 Бэкап
Это очень серьезный инструмент в арсенале вебмастера. На хорошем хостинге автоматически выполняется сохранение рабочих копий файлов сайта. Примерно выглядит это так:

Резервные копии сохраняются каждый день. И что-то делать для этого не нужно. А если после очередного «эксперимента» твой WordPress перестанет работать, достаточно выбрать нужное сохранение и активировать его.
Главное, нужно быть внимательным:
- 1️⃣Во-первых, необходимо выбрать нужный бэкап по дате. Если ты, например, воспользуешься резервной копией полугодичной давности, то потеряешь все данные и изменения, что были сделаны за этот период. И не факт, что можно будет что-то восстановить.
- 2️⃣Во-вторых, нужно правильно выбрать, что именно ты собираешься восстанавливать. Это актуально, если на одной учетной записи у тебя сразу несколько сайтов. На скрине выше, в записях система прям спрашивает «что восстановить». Если выбрать «весь аканту», то действие затронет всё на хостинге. Если тебе это не требуется, выбери нужную учётку.
Также, как правило, есть возможность создавать резервные копии вручную. Это может быть полезным перед «экспериментами» с WordPress.
💡 Отключение плагинов
После того как твой сайт перестает работать, как правило, WordPress автоматически присылает на почту отчет об ошибке. Если там сказано, что причина в каком-либо плагине, можно попробовать его отключить. Но как сделать это, если невозможно даже зайти в админку?
Все просто. Заходим на хостинге в файлы своего WordPress. И заходим в каталог «wp-contents» (как правило, он должен находиться в корне). Находим папку с плагинами «plugins» и переименовываем ее. Например, в «plugins.hold».
Это действие должно отключить все плагины. Возможно, системе нужно дать время обновить данные. Немного подождем. Если причина критической ошибке была в плагине, после описанной выше манипуляции можно будет войти в админку WordPress. И отключить/ удалить проблемное дополнение, об ошибке которого был прислан отчет на почту.
После не забудь вернуть прежнее наименование папки. Кстати, именно так, как плавило, техподдержка и отключает «взбесившиеся» плагины.
————————-
Вам также может быть интересно:
👉Красивый дизайн страниц с помощью CSS
👉Недопустимый тип значения «@context»
А что думаешь ты? Поделись своим мнением в комментариях!
Поделиться в соц сетях
- Общие сведения о кодах
- Возможные ошибки при первичном размещении сайта
- Ошибка — показывается список файлов вместо первой страницы
- 403 «Доступ запрещен»
- 404 «Файл не найден»
- 500 «Internal Server Error»
Общие сведения о кодах
Коды ошибок бывают положительными и отрицательными или успешными и неуспешными. Есть четыре типа кодов:
- 2xx — запрос выполнен успешно — сервер успешно отправил клиенту запрашиваемый документ
- 3xx — запрос успешно перенаправлен — тоже положительный код. Он говорит о том, что запрос клиента был перенаправлен. Используется при работе с кэширующими серверами, а также в алгоритме, когда браузер клиента проверяет актуальность документа на сервере (дату создания, размер и так далее)
- 4xx — ошибка — документ не был отправлен клиенту, так как произошла критическая ошибка. Например, запрошенный документ не найден на сервере, доступ к документу запрещен и так далее
- 5xx — ошибка сервера — критическая ошибка на сервере. Например, на сервере не смог нормально отработать скрипт пользователя
Возможные ошибки при первичном размещении сайта
Вы разместили сайт на хостинге компании .masterhost, загрузили файлы и получили ошибку 403 при попытке открыть сайт через браузер. Эта ошибка возникает в случае, если вы неправильно назвали индексный файл, который должен показываться при обращении к каталогу. Индексный файл может иметь названия index.html, index.htm, index.php, index.php3, index.phtml, index.shtml, default.htm или default.html. Также возможно, что в названии индексного файла присутствуют заглавные (большие) буквы. В UNIX-системах регистр букв в названиях файлов имеет значение (!).
Ошибка — показывается список файлов вместо первой страницы
Вы загрузили файлы на сервер, но вместо первой страницы видите список загруженных на сервер файлов. Вероятная причина ошибки в том, что вы загрузили файлы в каталог с разрешенным листингом и при этом у вас отсутствует индексный файл. Напомним, что размещать файлы нужно в каталоге www, который находится в каталоге с названием вашего домена. Читайте об этом подробнее здесь.
Ошибка 403 «Доступ запрещен» — устраняем причины
Данная ошибка возникает тогда, когда сервер не смог выполнить запрос по причине запрещенного доступа к файлу. Наиболее часто это возникает в трех случаях:
- В каталоге нет индексного файла (index.html, например) и при этом запрещен просмотр списка файлов в данном каталоге⚹ или на всем виртуальном сервере. Можно попробовать создать файл с именем index.html и посмотреть не исчезнет ли ошибка.
- Выставлены такие «права» доступа на файл, что веб-сервер Apache не смог прочитать файл на диске сервера. Попробуйте изменить права доступа на 644, например.
- Пользователь попытался обратиться к скрипту (в каталоге cgi-bin), на который выставлены неправильные права — нет права на чтение+исполнение (r+x) конкретного скрипта. Измените права на 755.
⚹По умолчанию просмотр списка файлов в каталоге запрещен. Для того, чтобы разрешить вывод списка файлов необходимо создать файл .htaccess, в котором прописать директиву Options +Indexes в виде отдельной строки.
Обработка ошибки 404 «Файл не найден»
Ошибка 404 (Файл не найден) возникает тогда, когда пользователь запрашивает у веб-сервера документ, которого нет на диске. То есть, когда пользователь запрашивает несуществующий файл. Это наиболее «популярная» из всех ошибок. Вы можете наблюдать возникновение таких ошибок в файле error_log и учитывать это — отслеживать какие документы на сервере «не найдены» и корректировать неправильные ссылки из своих html-документов. Также ссылки на несуществующие документы могут вести с других сайтов.
Для удобства посетителей сайта можно обрабатывать ошибки 404 заменяя стандартные ответы веб-сервера на свои страницы с нужным описанием причины возникновения ошибки и советами что делать в этом случае. Также полезно разместить на такой странице карту вашего сайта или ссылку на поисковую систему.
Как обрабатывать ошибку 404. Создайте в каталоге www файл .htaccess и поместите в него следующую инструкцию для веб-сервера Apache:
ErrorDocument 404 /not-found.html
Затем создайте файл not-found.html в который поместите описание возникшей ошибки и советы о том, что делать в этом случае посетителю вашего сайта. Теперь пользователь, который наберет в своем браузере адрес несуществующей страницы, будет автоматически перенаправлен сервером на файл not-found.html.
С помощью директивы ErrorDocument можно обрабатывать не только ошибку 404, но и практически все другие ошибки. Например, можно обработать так и ошибку 403, которая упоминается в этом документе выше. О файле .htaccess и его практическом использовании можно почитать тут.
Внимание: особенность браузеров MS Internet Explorer версий 5.xx и 6.xx состоит в том, что если ваш файл ошибок будет иметь размер менее 512 байт, то браузер покажет пользователю не ваш файл, а свое собственное сообщение об ошибке 404. Самым простым решением в данной ситуации является заполнение файла ошибок пробелами так, чтобы его размер превысил 512 байт. Подробнее об этом вы можете прочитать на сайте компании Microsoft.
Ошибка 500 «Internal Server Error»
Ошибка 500 «Internal Server Error» возникает в случае невозможности запуска скрипта, который вы разместили на сервере, в случае ошибок в скрипте, а также в случае, когда размещена неправильная инструкция в файле .htaccess. Этот список причин возникновения ошибки 500 не конечный, есть еще масса причин, по которым может возникнуть ошибка 500. Однако упомянутые три случая встречаются наиболее часто.
Рассмотрим сначала случай, когда вы поместили некорректную инструкцию в файл .htaccess. Если вы ошиблись в написании названия нужной директивы или параметров к ней, в файле error.log вы найдете примерно такую ошибку:
[Wed Apr 14 17:01:38 2004] [alert] [client 217.16.16.16]
/home/uXXXXX/aaa.ru/www/.htaccess:Invalid command 'DrectoryIndex',
perhaps mis-spelled or defined bya module not included in the server
configuration
Веб-сервер укажет вам, какую конкретно директиву он посчитал ошибочной — ее нужно будет исправить. В данном случае веб-сервер сообщил, что директивы DrectoryIndex он не знает. И действительно — нет директивы DrectoryIndex, есть DirectoryIndex. Имеет место опечатка.
Если ошибка 500 возникает при обращении к скрипту на языке Perl, размещенному в каталоге cgi-bin, нужно проверить права доступа на этот скрипт. Права должны быть 755 (rwxrx-rx). Если это не так, нужно изменить права на 755 командой chmod 755 script.pl в unix shell или воспользоваться для этого FTP. Нужно отдельно отметить — права на скрипты должны быть установлены строго в 755.
Пожалуйста, проверьте правильный ли режим передачи файлов по FTP вы использовали при загрузке скрипта на наш сервер. Все скрипты, равно как и любые другие текстовые файлы, должны передаваться по FTP в текстовом (ASCII) режиме. Если же был использован двоичный (Binary) режим передачи файлов, скрипты наверняка работать не будут.
Если после проверки корректности установленных прав на файл скрипта ошибка не исчезла, нужно изучить последние записи в файле error.log — в него веб-сервер помещает все сообщения об ошибках. Так вы найдете строчку вида
[Fri Apr 9 15:05:31 2004] [error][client 217.16.16.16] Premature end of
script headers: /home/uXXXX/aaa.ru/cgi-bin/script.pl
Первое, что нужно сделать при получении такой ошибки, это проверить правильно ли скрипт выдает HTTP-заголовки. Каждый скрипт должен сначала печатать строку с указанием соответствующего Content-type и только потом непосредственно то, что увидит пользователь (например, HTML-код). Пример строки для выдачи заголовка обычного HTML-документа:
print "Content-type: text/html; charset=windows-1251nn";
Если и после выдачи правильных заголовков ошибка 500 не исчезла, нужно проверить корректность работы скрипта в целом. Для этого нужно получить доступ в unix shell и далее выполнить команду проверки синтаксиса:
> perl -cw script.pl
script.pl syntax OK
Если скрипт написан с ошибками, их нужно исправить, руководствуясь соответствующей диагностикой, а также проверить синтаксис скрипта снова.