Сайт показывает ошибку 404 Not Found, хотя нужная страница раньше открывалась? Разбираем причины, способы проверки и пошаговое исправление ошибки. От простых действий в браузере до восстановления страниц, настройки CMS, сервера и редиректов без лишних потерь для SEO.
Открываете ссылку, а вместо нужного материала видите сообщение «Ошибка 404», «404 Not Found» или «Страница не найдена»? Это означает, что сервер не смог найти запрошенную страницу или другой ресурс по указанному адресу. Причина может быть простой - опечатка в ссылке, - а может скрываться в настройках сайта, работе системы управления контентом или конфигурации веб-сервера.
Если вы обычный посетитель, часто достаточно проверить адрес страницы или найти её через поиск. Если вы владелец сайта, потребуется определить, почему сервер возвращает код 404, восстановить нужный адрес или настроить правильное перенаправление.
В этом руководстве разберём, что означает ошибка 404, почему она возникает, как самостоятельно найти и исправить проблему на WordPress, OpenCart, других CMS и самописных сайтах, а также что делать, если несуществующие страницы обнаружили поисковые системы.
Ошибка 404 Not Found - это стандартный код состояния HTTP, который сообщает, что сервер не нашёл запрошенный ресурс по указанному URL. Таким ресурсом может быть страница сайта, изображение, PDF-документ, файл для скачивания или адрес API.
Например, пользователь переходит по ссылке https://example.com/catalog/old-product/, но страница товара была удалена или перенесена. Если сервер не находит ресурс по этому адресу и не настроено подходящее перенаправление, он может вернуть ответ 404 Not Found.
При этом сам сайт может продолжать нормально работать: главная страница, другие товары и разделы каталога остаются доступными.
В разговорной речи её часто называют серверной ошибкой 404, поскольку соответствующий ответ возвращает веб-сервер. Но технически код 404 относится к группе 4xx - ошибок при обработке клиентского запроса, а не к группе 5xx, обозначающей проблемы на стороне сервера.
Это не значит, что виноват посетитель. Причиной могут быть неверные настройки CMS, неправильная маршрутизация запросов, удалённые файлы или сбой после переноса сайта.
| Код | Что означает |
|---|---|
| 200 OK | Запрос успешно обработан. |
| 301 Moved Permanently | Ресурс постоянно перенесён на другой адрес. |
| 403 Forbidden | Сервер отказывает в доступе к запрошенному ресурсу. |
| 404 Not Found | Сервер не нашёл ресурс по запрошенному адресу. |
| 410 Gone | Ресурс больше недоступен; его отсутствие считается постоянным. |
| 500 Internal Server Error | Сервер столкнулся с внутренней ошибкой при обработке запроса. |
Важно различать эти состояния. Например, если сайт не открывается из-за проблем с DNS или подключения к интернету, браузер может вообще не получить HTTP-ответ. Это не то же самое, что код 404.
Чтобы правильно устранить проблему, сначала необходимо выяснить, почему нужный ресурс перестал открываться.
Самая простая причина - в URL допущена опечатка, пропущена часть адреса, указан лишний символ или неправильно скопирована ссылка.
Например, вместо /catalog/ пользователь открыл /catlaog/. Если такого адреса нет и сайт не умеет автоматически исправлять подобные ошибки, сервер вернёт 404.
Владелец сайта мог удалить статью, товар, категорию или документ. Иногда материал остаётся на сайте, но получает новый адрес после изменения заголовка, структуры каталога или настроек постоянных ссылок.
Если старый URL продолжает встречаться во внутренних ссылках, закладках пользователей или поисковой выдаче, посетители будут попадать на страницу ошибки.
CMS преобразует удобные человеку адреса в запросы к базе данных. Если правила такой обработки отсутствуют, устарели или конфликтуют между собой, существующие страницы могут начать возвращать 404.
Характерный пример: главная страница WordPress работает, а статьи и рубрики не открываются. Подобная ситуация возможна после переноса сайта, изменения настроек URL или конфигурации веб-сервера.
Неправильный корневой каталог сайта, отсутствующие правила маршрутизации, конфликты в конфигурации Nginx или Apache могут привести к тому, что запрос не попадёт в нужный обработчик.
Особенно внимательно следует проверять настройки после переезда на другой хостинг, смены Apache на Nginx или изменения расположения сайта в файловой системе.
Если сервер не находит изображение, документ, CSS-файл или скрипт, он также может вернуть 404.
На Linux-серверах регистр букв в именах файлов обычно имеет значение: Image.jpg и image.jpg могут быть разными файлами. Также следует проверять расширения и точное расположение ресурсов.
Плагин может изменять маршруты, создавать собственные страницы или перехватывать запросы. Если после обновления или удаления расширения его адреса перестали обрабатываться, посетители увидят 404.
Аналогичные проблемы могут возникнуть после изменений в шаблоне, пользовательских обработчиках URL и правилах перенаправления.
При миграции между CMS, изменении доменного имени или обновлении структуры каталога часть старых адресов может перестать существовать. Если для них не подготовлена карта соответствия URL и не настроены редиректы, прежние ссылки будут вести на ошибку.
Иногда страница уже восстановлена, но кеширующий плагин, CDN или промежуточный прокси продолжает отдавать ранее сохранённый ответ 404. В этом случае необходимо проверить ответ непосредственно на сервере и настройки кеширования.
Если вы просто пытаетесь открыть страницу, а доступа к управлению сайтом у вас нет, начните с нескольких простых действий.
Посмотрите на URL в адресной строке браузера. Убедитесь, что в нём нет опечаток, лишних символов, пробелов или неправильно скопированных частей ссылки. Если адрес вводился вручную, попробуйте перейти на сайт через его главное меню.
Не удаляйте произвольно параметры из ссылок на оплату, личный кабинет и другие персональные страницы: они могут быть необходимы для работы сервиса.
Перейдите на главную страницу того же домена. Если она открывается, попробуйте найти нужный раздел через меню, каталог или внутренний поиск.
Если страница отсутствует и в навигации, возможно, её удалили или перенесли.
Введите название нужного материала в Яндекс или Google, добавив к запросу адрес сайта. Например: site:example.com настройка WordPress.
Так можно обнаружить новый адрес статьи или другую страницу с нужной информацией. Учтите, что поисковая выдача обновляется не мгновенно и может содержать уже удалённые материалы.
Откройте другую страницу того же сайта и попробуйте повторить переход. Если ошибка возникает только по одному адресу, вероятнее всего, проблема связана именно с ним.
Если разные страницы ведут себя нестабильно, можно дополнительно проверить работу сайта в другом браузере или сети. Это поможет выявить влияние локального кеша, расширений браузера и сетевых ограничений, хотя сама ошибка 404 обычно связана с ответом сайта.
Если нужный материал невозможно найти, напишите администратору сайта и передайте точный URL проблемной страницы. Желательно указать, откуда вы перешли по ссылке и какое сообщение появилось.
Если ошибка возникла во время оплаты, оформления заказа или отправки формы, сначала проверьте, завершилось ли действие, чтобы случайно не отправить повторный платёж или заявку.
Важно: очистка кеша браузера, отключение VPN или переустановка браузера не способны восстановить действительно удалённую страницу. Эти действия могут помочь только в отдельных случаях, связанных с локальными или промежуточными настройками.
Если ваш сайт начал возвращать 404 для существующих страниц, не спешите массово изменять URL или добавлять перенаправления. Сначала установите источник проблемы.
Проверьте главную страницу, несколько статей или товаров, категории, изображения и случайный несуществующий URL, например /test-page-not-found-98765/.
Внешний вид страницы не всегда соответствует реальному HTTP-статусу. Сайт может показывать сообщение «404», но возвращать код 200, либо перенаправлять посетителя на отдельную страницу с ошибкой.
Проверить ответ можно непосредственно в браузере:
Если основной документ возвращает 200, а один из скриптов или изображений - 404, проблема связана не со всей страницей, а с конкретным ресурсом.
Для более точной диагностики можно использовать утилиту curl. В Windows 10/11, Linux и macOS она обычно доступна из командной строки или терминала.
Проверка заголовков ответа:
curl -I https://example.com/old-page/
В ответе найдите строку состояния, например HTTP/2 404, HTTP/2 200 или HTTP/2 301.
Некоторые сайты обрабатывают метод HEAD, который используется с параметром -I, иначе, чем обычный запрос GET. Если результаты отличаются от поведения в браузере, проверьте именно GET:
curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/old-page/
Чтобы увидеть последовательность перенаправлений, используйте:
curl -sS -L -o /dev/null -w "Итоговый код: %{http_code}; конечный URL: %{url_effective}\n" https://example.com/old-page/
В этих командах замените example.com/old-page/ на адрес проверяемой страницы. Последняя команда показывает итоговый статус после переходов, но не все промежуточные ответы. Для просмотра цепочки редиректов можно использовать curl -IL, учитывая особенность метода HEAD.
Откройте панель управления сайтом и найдите соответствующую запись, товар или категорию. Проверьте, опубликован ли материал, не находится ли он в корзине или черновиках и совпадает ли текущий URL с проблемным адресом.
Если страница существует, но имеет другой адрес, выясните причину изменения. Не стоит сразу переименовывать URL обратно: сначала оцените, какой адрес должен быть основным и есть ли на него внешние ссылки или поисковый трафик.
В панели хостинга найдите журналы доступа и ошибок, которые могут называться Access Log и Error Log. Проверьте запросы к проблемному URL, время появления ошибки и код ответа.
Если используется собственный сервер, журналы часто расположены в каталогах /var/log/nginx/ или /var/log/apache2/, но фактический путь зависит от конфигурации.
Обратите внимание, что запрос с кодом 404 может присутствовать только в журнале доступа. Отсутствие сообщения в Error Log само по себе не означает, что ошибка не возникала.
Если сообщение об ошибке оформлено в стандартном стиле Nginx или Apache, проверьте, доходит ли запрос до приложения. Если отображается фирменная страница ошибки вашей CMS, вероятно, запрос обработан приложением, но нужный маршрут или материал не найден.
Это ориентир, а не безусловный признак: сервер может показывать собственный шаблон ошибки, а CMS - отдавать страницу, похожую на стандартную серверную. Для окончательного вывода сопоставьте HTTP-заголовки, журналы и конфигурацию.
После диагностики выберите действие в зависимости от того, существует ли запрошенная страница и должна ли она оставаться доступной.
Если нужная страница раньше находилась по другому адресу, по возможности сохраните прежний URL. Когда сохранение невозможно или нецелесообразно, настройте перенаправление на её актуальный адрес.
Перед восстановлением базы данных целиком сделайте актуальную резервную копию: полная загрузка старого бэкапа может уничтожить заказы, заявки, новые публикации и другие изменения, появившиеся после его создания.
Не перенаправляйте все удалённые материалы на главную страницу. Редирект должен вести на ресурс, который действительно соответствует содержанию старого URL.
В этом случае исправлять сам ответ 404 не требуется. Удалите неработающие внутренние ссылки, исключите старый адрес из XML-карты сайта и убедитесь, что сервер возвращает правильный HTTP-статус.
Если ресурс заведомо удалён навсегда, можно использовать код 410 Gone. Для SEO не требуется обязательно заменять каждый ответ 404 на 410: оба кода подходят для отсутствующих страниц.
На WordPress одна из характерных ситуаций - главная страница открывается, а отдельные статьи, рубрики или товары WooCommerce возвращают ошибку 404. Причина может быть связана с настройками постоянных ссылок, правилами веб-сервера, состоянием публикаций или конфликтом расширений.
При сохранении WordPress обновляет внутренние правила маршрутизации. На Apache он также может обновить правила в файле .htaccess, если позволяют настройки и права доступа. На Nginx пересохранение ссылок не заменяет настройку серверной маршрутизации.
Не переключайте структуру постоянных ссылок на другую ради эксперимента на работающем сайте: это может изменить адреса опубликованных материалов и вызвать новые ошибки.
Сделайте резервную копию текущего файла .htaccess в корневом каталоге WordPress. Проверьте, существуют ли в нём правила маршрутизации CMS и не конфликтуют ли они с пользовательскими редиректами или настройками безопасности.
Если стандартные правила отсутствуют или повреждены, восстановите их по официальной документации WordPress для вашей конфигурации.
Не заменяйте весь файл стандартным образцом без проверки. В нём могут содержаться рабочие правила HTTPS, кеширования, защиты сайта и перенаправления старых URL. Для WordPress Multisite и установки в подкаталог используются другие правила.
Для товаров WooCommerce дополнительно проверьте наличие товара, его постоянную ссылку и настройки постоянных ссылок товаров. Если не открываются только карточки товаров или товарные категории, проверьте маршрутизацию соответствующих типов записей.
Если ошибка появилась после установки или обновления расширения, проверьте плагины SEO, редиректов, безопасности, кеширования и плагины, которые создают собственные адреса.
На тестовой копии сайта временно отключите подозрительное расширение, повторно проверьте проблемный URL и сравните результат. Если ошибка исчезла, изучите настройки плагина и его совместимость с текущей версией WordPress.
Если после обновления темы перестали открываться страницы пользовательского типа, проверьте код регистрации этого типа записей и правила его маршрутизации. Не удаляйте плагины с пользовательскими данными без резервной копии.
Если настройки WordPress корректны, но все внутренние страницы по-прежнему возвращают 404, проверьте конфигурацию Apache или Nginx. Для Apache важна корректная работа правил переадресации запросов, для Nginx - настройка передачи запросов WordPress.
Инструкции для серверов приведены в разделе «Настройки Nginx и Apache».
В OpenCart ошибка 404 может возникать после изменения SEO URL товара, переноса магазина, установки модуля, изменения структуры каталога или обновления движка.
При этом магазин может нормально открываться по одним адресам и возвращать 404 по другим. Поэтому важно проверить, связана ли проблема с самим товаром, его SEO-адресом или правилами обработки URL.
Если товар существует, но старый URL не работает, причина может быть связана с изменением SEO-адреса или отсутствием перенаправления.
В настройках магазина найдите параметр использования SEO URL. Его расположение и название могут отличаться в зависимости от версии OpenCart, локализации и установленных модификаций.
Проверьте SEO-адрес проблемного товара или категории, а также записи URL для нужного магазина и языка, если ваша версия OpenCart использует такие привязки.
Убедитесь, что SEO-адрес не конфликтует с адресами других материалов и корректно обрабатывается установленной версией движка.
Не меняйте массово SEO URL товаров, которые уже получают поисковый трафик. Сначала установите причину ошибки и проверьте старые адреса. При вынужденном изменении URL потребуется карта перенаправлений.
Если магазин работает на Apache, сравните действующий файл .htaccess с исходным файлом .htaccess.txt из дистрибутива именно вашей версии OpenCart. Убедитесь, что правила SEO URL включены и соответствуют расположению магазина.
Если OpenCart установлен в подкаталоге, проверьте базовый путь в правилах перенаправления. При работе на Nginx необходимо проверить серверную конфигурацию: сам по себе файл .htaccess этим сервером не обрабатывается.
Не переносите правила из другой версии OpenCart без сравнения. Между версиями и различными сборками могут отличаться обработчики и структура SEO-адресов.
Если ошибка появилась после установки или обновления модуля, проверьте его влияние на формирование и обработку URL.
В зависимости от версии OpenCart и установленного механизма модификаций может потребоваться обновить кеш модификаторов. Делайте это штатными средствами вашей версии после создания резервной копии и проверки совместимости расширений.
Если в магазине используются дополнительные SEO-модули, проверьте их собственные таблицы, правила формирования URL и перенаправления.
Если ошибка появилась после обновления OpenCart или переноса каталога на другую CMS, подготовьте список старых и новых адресов. Сохраняйте исходные URL там, где это возможно. Для изменённых адресов настройте индивидуальные постоянные редиректы на соответствующие товары и категории.
После исправления проверьте страницы товаров, категории, пагинацию, фильтры, изображения, меню и XML-карту сайта.
Ошибки 404 возникают не только на WordPress и OpenCart. Принцип диагностики для других систем схож: необходимо определить, существует ли ресурс, правильно ли сформирован его адрес и доходит ли запрос до обработчика сайта.
Проверьте публикацию материала, его псевдоним, категорию и соответствующий пункт меню. Если не работают человекопонятные адреса, проверьте настройки SEF URL и правила сервера. После исправления очистите кеш и протестируйте исходные ссылки.
Проверьте, существует ли материал, доступен ли он посетителям и правильно ли настроен его URL-алиас. Если ошибка затрагивает группу страниц после изменения модулей или маршрутов, проверьте маршрутизацию и очистите кеш средствами Drupal.
Проверьте публикацию ресурса, его URI и настройки дружественных URL. Если страница существует в дереве ресурсов, но не открывается, проверьте правила веб-сервера и работу маршрутизации MODX. После изменений очистите кеш сайта.
Проверьте доступность публикации, её адрес, настройки ЧПУ и правила маршрутизации. Если ошибки появились после переноса сайта или смены конфигурации сервера, сравните прежние и текущие правила обработки запросов.
В самописном проекте необходимо проверить обработчик маршрута, наличие записи в базе данных, корректность параметров запроса и правила маршрутизации сервера.
Если страница формируется JavaScript-приложением, дополнительно проверьте, какой HTTP-статус возвращается при прямом открытии URL и при обновлении страницы. Клиентская маршрутизация не должна превращать действительно отсутствующие страницы в успешные ответы 200 с сообщением «Не найдено».
Для API код 404 может означать, что не существует конкретного запрошенного объекта или обработчика маршрута. При диагностике проверьте HTTP-метод, версию API, путь запроса, идентификатор ресурса и документацию конкретного сервиса. Не следует автоматически заменять ответ 404 редиректом, если он предусмотрен логикой API.
Если существующие страницы возвращают 404 из-за конфигурации веб-сервера, исправление потребует доступа к настройкам хостинга или VPS.
Перед редактированием конфигурационных файлов сохраните их копии. На рабочем сайте проверяйте изменения на тестовом окружении. Если у вас нет доступа к настройкам сервера, передайте результаты диагностики технической поддержке хостинга.
.htaccess в каталоге сайта и правила, которые передают запросы CMS.mod_rewrite доступен и сервер разрешает применять нужные правила из .htaccess.DocumentRoot и расположение файлов сайта.Если после изменения .htaccess вместо 404 появился код 500, верните рабочую копию файла и изучите журнал ошибок Apache. Это может указывать на недопустимую директиву или другую проблему в конфигурации.
Nginx не использует правила из .htaccess. Маршрутизация запросов настраивается в конфигурации сервера.
Для обычной установки WordPress в корневом каталоге сайта внутри соответствующего блока server часто применяется следующий обработчик:
location / { try_files $uri $uri/ /index.php?$args; }
Он сначала проверяет наличие запрошенного файла или каталога, а если ресурс не найден, передаёт запрос основному PHP-обработчику WordPress.
Это не универсальное правило для всех CMS. У OpenCart, Drupal, самописных приложений и сайтов, установленных в подкаталоге, маршрутизация может отличаться. Также для работы PHP необходима отдельная корректная конфигурация PHP-FPM или другого обработчика.
Если ошибка возникла на Nginx, выполните проверку в следующем порядке:
root и соответствие каталога фактическому расположению сайта.location, который обрабатывает проблемный URL.nginx -t. Только после успешной проверки применяйте изменения штатным способом, например командой nginx -s reload, если она соответствует вашей конфигурации.Если на сайте одновременно используются Nginx и Apache, необходимо определить, какой сервер возвращает ошибку и на каком этапе обработки запроса она возникает.
Одна из страниц может работать нормально при прямом открытии, а другая - содержать неправильную ссылку на неё. Поэтому после исправления конкретной ошибки желательно проверить весь сайт.
В отчётах могут присутствовать исторические данные. Поэтому перед исправлением обязательно проверяйте текущий ответ сервера. Кроме того, Яндекс Вебмастер не гарантирует отображение абсолютно всех неработающих ссылок на сайте.
Не все найденные поисковой системой ответы 404 являются проблемой. Если URL действительно не существует и не должен существовать, правильный ответ 404 можно оставить без изменений.
Для систематической проверки сайта можно использовать программу-краулер, например Screaming Frog SEO Spider или аналогичный инструмент аудита.
Проверяйте не только HTML-страницы, но и изображения, PDF-файлы, скрипты и таблицы стилей. Отсутствующие статические ресурсы могут нарушать внешний вид сайта и работу его функций.
В журнале доступа можно обнаружить URL, запрошенные пользователями и поисковыми роботами, в том числе адреса, которые не встречаются во внутренних ссылках сайта.
Сгруппируйте запросы с кодом 404 по URL и количеству обращений. В первую очередь проверьте адреса, которые ранее существовали, получают реальные переходы или относятся к важным коммерческим страницам.
Отдельно учитывайте автоматические запросы к случайным адресам, старым файлам, административным интерфейсам и потенциально уязвимым путям. Если ресурс никогда не существовал, создавать для него страницу или перенаправление не требуется.
Откройте действующую XML-карту сайта и проверьте, не содержит ли она URL удалённых страниц, адреса с неправильными перенаправлениями или ссылки на материалы, которые должны быть доступны, но возвращают 404.
Карта сайта должна содержать актуальные адреса страниц, предназначенных для индексирования. После исправления обновите XML-карту и убедитесь, что она корректно формируется вашей CMS или SEO-модулем.
Наличие отдельных страниц с кодом 404 само по себе не означает, что сайт получил санкции поисковых систем. Такой код необходим для корректной обработки несуществующих ресурсов.
Проблемы возникают, когда по ошибке становятся недоступны существующие и полезные страницы: статьи, карточки товаров, категории и другие материалы, которые должны получать поисковый трафик.
Когда поисковый робот получает ответ 404, он узнаёт, что ресурс недоступен по данному адресу. Если страница была проиндексирована ранее, поисковая система может исключить этот URL из результатов поиска после повторной обработки.
Если по этому адресу находился товар или статья, приносившие посетителей, их недоступность может привести к потере соответствующего органического трафика. На коммерческом сайте пользователь также может не добраться до товара или оформления заказа.
Поэтому в первую очередь необходимо исправлять ошибки 404 на страницах, которые должны существовать, особенно если они раньше были проиндексированы и получали переходы.
Нет. Если страница удалена окончательно, не имеет подходящей замены и на неё не ведут ошибочные внутренние ссылки, оставлять ответ 404 допустимо.
Другая ситуация - существующая страница случайно отдаёт 404 из-за неправильной настройки CMS или сервера. Такую ошибку следует устранить, восстановив доступность материала по нужному адресу.
Soft 404, или «мягкая 404», - это ситуация, когда сайт показывает сообщение об отсутствии страницы, но возвращает успешный код HTTP 200. Поисковая система также может определить как Soft 404 страницу с отсутствующим или почти пустым основным содержимым.
Например, пользователь открывает несуществующий URL и видит сообщение «Страница не найдена», а сервер сообщает поисковому роботу, что запрос выполнен успешно.
Чтобы исправить такую проблему, настройте правильный ответ 404 для действительно отсутствующего ресурса. Если нужная страница существует, восстановите её содержимое и корректную загрузку важных ресурсов.
Не путайте Soft 404 с обычной страницей ошибки, у которой есть красивый дизайн, ссылки и форма поиска. Такой шаблон допустим, если сервер возвращает правильный HTTP-статус 404.
Обычно это не требуется. Для несуществующей страницы корректный HTTP-статус 404 или 410 уже сообщает поисковому роботу, что ресурс отсутствует.
Не заменяйте исправление случайно сломанной страницы запретом сканирования в robots.txt. Такой запрет может помешать роботу получить актуальный ответ сервера и обнаружить, что страница восстановлена или удалена.
Тег noindex также не восстанавливает отсутствующий материал и не заменяет корректную настройку HTTP-статуса.
Редирект 301 - это постоянное перенаправление посетителя и поискового робота со старого адреса на новый. Он нужен, когда материал переехал или старой странице найдена подходящая постоянная замена.
Например, статья раньше находилась по адресу https://example.com/old-guide/, а после изменения структуры сайта стала доступна по адресу https://example.com/new-guide/. В таком случае перенаправление позволяет посетителям, которые сохранили старую ссылку, попасть на актуальную статью.
Если сайт работает на Apache и поддерживает mod_rewrite, можно добавить правило для конкретного адреса. Например:
RewriteEngine On
RewriteRule ^old-page/?$ /new-page/ [R=301,L]
Правило следует разместить с учётом существующей конфигурации, до общих правил CMS, которые могут перехватить запрос. Показанный пример рассчитан на файл .htaccess в корневом каталоге сайта. Для установки в подкаталог путь и расположение правила нужно адаптировать.
Перед изменением файла сохраните его копию. После настройки проверьте, что старый адрес возвращает 301, а целевая страница - 200.
В конфигурации соответствующего сайта можно использовать правило:
location = /old-page/ { return 301 /new-page/; }
Оно перенаправляет запросы с конкретного старого URL на новый адрес в пределах того же сайта. При наличии других правил маршрутизации необходимо проверить их взаимодействие.
После изменения конфигурации выполните проверку nginx -t и примените изменения штатным способом.
Если страница удалена и подходящей замены нет, лучше оставить корректный ответ 404 или 410. Не стоит перенаправлять любой отсутствующий URL на главную страницу, случайную категорию или другой материал только ради устранения кода ошибки.
После настройки редиректа обновите внутренние ссылки на новый адрес. Это позволит избежать лишних переходов и сократить цепочки перенаправлений.
Даже при правильной работе сайта посетители могут переходить по ошибочным ссылкам или вводить несуществующие адреса. Поэтому полезно подготовить отдельную страницу ошибки 404, которая поможет им продолжить работу с сайтом.
Хорошая страница ошибки должна не только сообщать о проблеме, но и предлагать посетителю понятный следующий шаг.
Страница должна сохранять общий стиль сайта и корректно отображаться на мобильных устройствах.
Не используйте только изображение с крупным числом «404» без пояснений и навигации. Посетителю должно быть понятно, почему страница недоступна и как найти нужную информацию.
Если пользователь открыл несуществующий URL, сервер должен вернуть 404 Not Found, даже если показывается красивый HTML-шаблон с меню и полезными ссылками.
Не подменяйте ошибку перенаправлением на отдельный адрес вроде /404/, если в результате первоначальный запрос превращается в успешный ответ 200. Для отображения шаблона ошибки используйте механизмы CMS или внутреннюю обработку ошибок на сервере, сохраняющую правильный HTTP-статус.
На Apache для статической страницы ошибки можно использовать директиву:
ErrorDocument 404 /404.html
Файл 404.html должен находиться в соответствующем каталоге сайта и быть доступен серверу. Это пример для Apache; если CMS уже обрабатывает ошибки самостоятельно, дополнительная директива может не потребоваться.
Для WordPress обычно используется шаблон 404 темы, а в других CMS - собственный обработчик ошибок. После изменения обязательно проверьте реальный HTTP-статус случайного несуществующего адреса.
После внесения изменений важно проверить не только внешний вид страницы, но и всю последовательность обработки запроса.
Исправление HTTP-кода не гарантирует немедленного возвращения страницы в поисковую выдачу или восстановления прежних позиций. Поисковым системам необходимо повторно обработать URL, а результат зависит и от других факторов индексирования и ранжирования.
Сайт получил ваш запрос, но не нашёл страницу или файл по указанному адресу. Возможно, в ссылке ошибка, нужный материал удалён либо его адрес изменился.
Сначала проверьте URL, откройте главную страницу сайта и попробуйте найти нужный материал через меню или поиск. Если ошибка возникает на вашем собственном сайте, проверьте наличие страницы, её адрес, настройки CMS и ответ веб-сервера.
Обычно это связано с конкретным ресурсом: страница удалена, адрес изменён, в ссылке допущена ошибка или неправильно работает обработчик определённого маршрута. Начните с проверки наличия материала и его текущего URL.
Возможная причина - неправильная маршрутизация внутренних URL. На WordPress проверьте настройки постоянных ссылок и правила веб-сервера. На OpenCart - SEO-адреса, настройки ЧПУ и обработку запросов. Также проверьте, не возникла ли проблема после переноса или обновления сайта.
Да. Если файл удалён, перемещён или ссылка содержит неправильный путь, сервер может вернуть 404. Проверьте адрес скачивания, наличие файла и его расположение на сервере.
Возможно, запрошенный маршрут или конкретный объект не существует. Проверьте адрес, HTTP-метод, версию API, параметры запроса и идентификатор ресурса. У некоторых сервисов код 404 также используется для сокрытия существования ресурса, к которому нет доступа, поэтому учитывайте документацию соответствующего API.
Нет. Необходимо исправлять ошибочно недоступные страницы и неработающие внутренние ссылки. Если ресурс действительно удалён, корректный ответ 404 или 410 позволяет поисковой системе самостоятельно обработать его отсутствие. Исторические записи в отчётах могут сохраняться некоторое время.
Иногда очистка кеша или обновление страницы помогает, если браузер либо промежуточный сервер продолжает использовать устаревший ответ. Но если ресурс действительно отсутствует на сайте, очистка кеша его не восстановит.
Технически такое перенаправление возможно, но применять его ко всем отсутствующим адресам не следует. Пользователь не получает искомый материал, а поисковая система может расценить несоответствующее перенаправление как Soft 404. Постоянный редирект уместен, когда существует подходящая новая страница.
Точного срока нет. После восстановления страницы поисковой системе необходимо повторно её обойти и обработать. Можно проверить ответ сервера, обновить внутренние ссылки и XML-карту сайта, а затем воспользоваться инструментами проверки URL и переобхода. Возвращение в индекс и прежних позиций при этом не гарантируется.
Ошибка 404 означает, что сервер не нашёл запрошенный ресурс. Если адрес введён неверно или страница действительно удалена, такой ответ является нормальным. Если же ошибка возникает на существующей статье, товаре или другой важной странице, нужно установить причину и восстановить доступность материала.
Для владельца сайта правильный порядок действий следующий: проверить фактический HTTP-код, определить причину отсутствия страницы, исправить настройки CMS или сервера, восстановить нужный URL либо настроить подходящее перенаправление, а затем проверить внутренние ссылки и поисковую индексацию.
Если ошибка появилась после обновления CMS, переноса сайта, установки модуля или изменения конфигурации сервера, важно устранять именно её источник, а не скрывать проблему массовыми редиректами. Это поможет сохранить рабочие адреса, удобную навигацию и доступность важных страниц для пользователей и поисковых роботов.
Админка WordPress открывалась до 21 секунды, менеджеры испытывали проблемы с редактированием записей. Нашёл избыточную нагрузку WPML и Toolset, устранил ошибки совместимости PHP и исправил шаблон туров. Подробный разбор диагностики и решения.
Переработана структура каталога интернет-магазина на OcStore 1.5.6.4: карточки товаров получили постоянные URL и стабильные хлебные крошки, старые адреса перенаправляются через 301 Redirect, а отдельные товары теперь можно выводить в плитках категорий вместе с подкатегориями.
Пришлите ссылку на сайт и кратко опишите задачу — я посмотрю и предложу следующий шаг.