Что это и как ее исправить

Список самых распространенных ошибок сайта

Эти ошибки могут препятствовать росту позиций и продаж. Рассмотрим виды и типы ошибок, причины их появления, что с ними делать, как их найти самостоятельно, а также их влияние на продвижение в Яндексе / Google и продажи.

Введение

Меня зовут Толстенко Александр, и я специалист по продвижению сайтов в Яндексе / Google с 2009 года. Я предлагаю бесплатные и платные консультации.

Ошибки серверов

Классы состояний HTTP

При открытии URL ваш браузер отправляет HTTP-запрос на сервер, который отвечает определенным кодом состояния HTTP (трехзначное число) и параметрами.

Коды состояний HTTP классифицируются следующим образом:

• 1** – информационные;
• 2** – успешное завершение запроса;
• 3** – перенаправление;
• 4** – ошибка на стороне клиента;
• 5** – ошибка на стороне сервера.

Распространенные ошибки 4xx

1. 404 Not Found – Страница не найдена (битые ссылки)

Эта ошибка означает, что запрашиваемый документ больше не существует по данному URL. Причины включают вмешательство программиста или случайное удаление ресурсов.

2. 403 Forbidden – Доступ к ресурсу запрещен

Эта ошибка означает, что доступ к документу запрещен. Чтобы страница индексировалась, необходимо предоставить доступ.

3. 410 Gone – Ресурс недоступен

Эта ошибка указывает на то, что документ был удален навсегда.

Распространенные ошибки 3xx

1. 301 Moved Permanently – Ресурс перемещен навсегда (301 редирект)

## Ошибка 301: Постоянное перемещение

Ошибка 301 означает, что документ был перемещен навсегда и теперь находится по новому URL. Пользователи, пытающиеся зайти на старую страницу, будут автоматически перенаправлены на новый URL. Поисковые роботы проиндексируют новую страницу, если она доступна для индексации.

Старая страница с URL будет заменена в результатах поиска новым URL, и теперь все показатели старой страницы будут переданы новой странице. Если на сайте будет много 301 редиректов, скорость обхода страниц и скорость учета изменений на старых страницах сильно снизится.

## Ошибка 302: Временное перемещение

Ошибка 302 означает, что запрошенный ресурс временно находится по другому адресу. В результатах поиска будет отображаться старый URL, и при переходе на него будет сделан 302 редирект на новый адрес на сайте. Необходимо настроить 301 редирект с старого на новый URL, чтобы передать метрики старой страницы на новую.

## Ошибка 304: Страница не изменена

Ошибка 304 указывает, что содержимое страницы не изменилось с момента последнего обращения робота. Этот HTTP код ответа помогает ускорить индексацию новых страниц и быстро учитывать изменения на старых. Настройка заголовка Last-modified позволяет поисковому боту  определить дату последнего изменения документа без распаршивания HTML разметки.

## Коды ошибок сервера

### Internal Server Error

Ошибка 500 означает, что сервер столкнулся с непредвиденными условиями, не позволяющим выполнить запрос. Это внутренняя ошибка сервера, выходящая за рамки остальных ошибок.

### Gateway Timeout

Ошибка 504 указывает на то, что прокси-сервер не дождался ответа от вышестоящего сервера и завершил запрос.

## Важность кодов ответа сервера

Описанные серверные ошибки значительно влияют на эффективность продвижения сайта в поисковых системах. Они являются базой, с которой должно начинаться SEO продвижение, поскольку от них зависит эффективность дальнейшего продвижения. Код ответа сервера указывает поисковым машинам, что делать с документом: индексировать его или исключить из поисковой выдачи. Большое количество ошибок 4хх и 3хх может замедлить процесс учета изменений на сайте, что критично для крупных проектов.

Важность проведения технического аудита

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

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

Что делать, если сайт выдает ошибку

Если при открытии сайта, выдается 3хх или 4хх код ответа сервера – желательно не затягивать с их исправлением (если это не массовая техническая проблема, после внесения правок).

Если 5хх – бить тревогу, т.к. робот очень быстро начнет удалять страницы, дающие трафик из результатов поиска.

За один день можно лишиться большей части трафика, который потом можно и не восстановить.

Другие ошибки веб сайта

Помимо серверных проблем, встречаются и другие. Они также сильно влияют на эффективность продвижения в Яндекс и Google.

Ошибки html верстки

Один не закрытый тег или неверно поставленная кавычка в head, может затруднить распознавание информации на странице сайта для робота, хотя в браузере все будет выглядеть нормально.

Проверить ошибки верстки можно через сервис validator.w3.org или любой другой валидатор.

Данные сервисы покажут конкретные проблемные места в верстке, которые нужно будет устранить.

Некорректная работа мобильной версии сайта

Частая проблема, когда на ПК сайт работает отлично, а проверяешь его с мобильного телефона, часть функционала не доступна (скрыта), отображается некорректно или мобильная версия и вовсе отсутствует.

Проблемы скорости загрузки сайта

Медленная загрузка сайта напрямую к техническим ошибкам не относится, хотя по рекомендациям поисковых систем, скорость загрузки ресурса должна быть не более 3-5 секунд, а в 2021 году Google включил метрику в факторы ранжирования.

На сколько это важный фактор ранжирования, спорный вопрос (рекомендую смотреть на средние значения конкурентов в ТОП 10, должно быть не хуже, чем у них), а вот с точки зрения повышения количества заказов, даже очень весомый фактор.

Проверить скорость загрузки ресурса можно в сервисе Google PageSpeed Insights (рекомендуется добиться зеленой зоны).

Ошибки Java Script

Считается, что если сайт работает, значит проблем нет. Это не так, часто забывают про ошибки JS, которые могут блокировать важную работу функционала и отключить возможность отправки заказов/заявок через сайт.

Увидеть и исправить все ошибки JavaScript можно, например через сервис Track.js.

Неправильно прописаны правила сканирования в robots.txt

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

Неправильно настроенный или отсутствующий тег canonical на дублирующих страницах

Ошибки на сайте, которые могут негативно повлиять на SEO

Чаще всего, тег не верно настраивают для страниц пагинации в интернет магазинах. Иногда встречаются магазины, у которых один и тот же товар, находится в разных категориях по разным url (полные дубли страниц), что мешающие СЕО-продвижению. Данную болезнь, частенько встречал у сайтов на 1с Битрикс.

Отсутствие или неправильное написание метатегов на страницах

h1, title, description – самые важные метатеги. Имея определенную структуру на сайте и сделав базовую оптимизацию с помощью применения масок этих тегов, можно увеличить видимости по продвигаемым ключевым запросам (пример: базовой оптимизации сайта и ее результаты).

Страницы дубли (каннибалы)

Ошибка сертификата ssl (HTTPS – защищенное соединение)

Поисковые системы учитывают безопасность соединения при упорядочивании результатов выдачи. Если сайт использует незащищенную версию протокола (HTTP) — это будет минусом для посетителей (увидят уведомление на экране браузера) и негативно отразится на позициях в результатах выдачи. Периодически бывает так, что на страницах появляется mixed content или просто отваливается HTTPS протокол по техническим причинам.

И другие web ошибки, которые мешающие продвижению

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

Как можно проверить сайт на ошибки самостоятельно

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

🛑 Найти и исправить все ошибки можно проведя детальный технический аудит. Ознакомиться с ошибками проекта одного из клиентов, данными рекомендациями и увидеть результаты после исправления, можно в статье технический аудита сайта.

Как проверить сайт на ошибки онлайн

Сейчас, существует много онлайн сервисов проверки. Какой-то конкретный, рекомендовать не буду, особенно платный. Яндекс.Вебмастер + Google Search Console покажут практически все недостатки. Если их дополнить еще данными из Screaming Frog, разобрать все типы ошибок и написать рекомендации по исправлению – получится профессиональный SEO аудит. Если, все же есть необходимость проверить сайт на ошибки в онлайн сервисе, погуглите. Их щас на любой вкус и цвет.

Что делать с найденными ошибками сайта

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

🛑 Если, оптимизацией никогда не занимались, если хватит опыта исправить существующие ошибки или заказать технический аудит с рекомендациями по исправлению у специалистов.Прежде чем заказать, рекомендую спросить посмотреть примеры сделанных аудитов. Если они будут +/- как этот пример аудита – не рекомендую заказывать. Конкретные рекомендации не получите, вопросов будет еще больше, чем ответов.

Что получит бизнес в результате исправления

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

Наличие большого количества техошибок, говорит роботу, что сайт “не качественный”, а не качественные проекты никогда не будут лидерами ниши (если вы, конечно, никакой ни будь М.Видео, которому роботы много чего прощают).

Поэтому, рекомендуется исправлять технические проблемы на старте, в первые 2-3 месяца, периодически следить за появлением новых, параллельно продолжать работы по оптимизации текущих и новых страниц проекта. В будущем, это позволит кратно увеличить посещаемость, заказы и продажи.

На этом все, спасибо за внимание.

✌ Нужна консультация?

👉 Пишите в личные сообщения кодовое слово: «ОшибкиСайтаVc»

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "REST API Best Practices" автора Krishna Srinivasan.

REST становится общим подходом для представления сервисов окружающему миру. Причина его популярности заключается в его простоте, легкости использования, доступе через HTTP и другие. Существует неправильное представление о том, что все данные, доступные через сеть, считаются REST, но это не так. В этой статье я собираюсь объяснить вам некоторые best practices, которые вы должны всегда помнить при реализации собственного REST приложения. Я бы хотел услышать ваш опыт в REST приложениях, поэтому если вы знаете best practies, которые не упомянуты в этой статье, пожалуйста, поделитесь с нами в комментариях.

Disclamer: все best practies основаны на моем личном опыте. Если вы имеете другое мнение, не стесняйтесь отправлять его мне на email, и мы обсудим его.

Здесь представлен список best practices, которые будут обсуждаться в этой статье:

1. Конечные точки в URL – имя существительное, не глагол 2. Множественное число 3. Документация 4. Версия вашего приложения 5. Пагинация 6. Использование SSL 7. HTTP методы 8. Эффективное использование кодов ответов HTTP

Конечные точки в URL – имя существительное, не глагол

Одна из самых распространённых ошибок, которую делают разработчики REST приложений, — использование глаголов при именовании конечных точек. Однако, это не лучшая практика. Вы должны всегда использовать существительные вместо глаголов.

Мы имеем заказ на разработку REST веб сервисов, которые предоставляют информацию об Индийских фермерах. Сервис также должен реализовывать функционал, предоставляющий такую информацию как доход фермера, названия культур, адреса ферм и другую информацию, относящуюся к каждому фермеру. Каждый фермер имеет уникальный id.

Таким же образом должны быть реализованы сервисы, предоставляющие информацию о культурах и какой фермер владеет ими.

Имеем единственную конечную точку, которая отвечает за все действия. В примере ниже представлена только одна конечная точка /farmers для всех операций таких как добавление, обновление, удаление. Базовые реализации имеют различные HTTP методы, которые правильно маршрутизируются для разных операций.

• /farmers • /crops

Постарайтесь избегать использования глаголов. Рекомендуется представлять операции внутри таких форматах как JSON, XML, RAML или использовать HTTP методы. Не используйте представленные ниже обозначения:

• /getFarmers • /updateFarmers • /deleteFarmers • /getCrops • /updateCrops • /deleteCrops

Множественное число

Используйте множественное число для названия своих REST сервисов. Это еще одна горячая тема для обсуждений среди REST дизайнеров – выбор между единственными или множественными формами существительных для обозначения сервисов.

Best Practice:Не рекомендуется:Примечание:

Хотя я упоминаю, что использование множественного числа является best practice, по какой-то причине, если вы придерживаетесь единственного числа, то придерживайтесь этого во всех своих сервисах. Не смешивайте использование множественного и единственного чисел. Поэтому я и не говорю здесь про bad practice, а просто говорю, что это не рекомендуется. Пожалуйста, решайте сами, что лучше подходит для вашего приложения.

Документация

Документирование программного обеспечения является общей практикой для всех разработчиков. Этой практики стоит придерживаться и при реализации REST приложений. Если писать полезную документацию, то она поможет другим разработчикам понять ваш код. Наиболее распространенным способом документирования REST приложений – это документация с перечисленными в ней конечными точками, и описывающая список операций для каждой из них. Есть множество инструментов, которые позволяют сделать это автоматически.

Ниже представлены приложения, которые помогают документировать REST сервисы:

• DRF Docs • Swagger • Apiary

Пожалуйста, поделитесь своим опытом документирования ваших приложений в комментариях.

Версия вашего приложения

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

Существует два общих способа для управления версиями REST приложений:

1. URI версии. 2. Мультимедиа версии.

Простой пример как выглядит URI версия: host/v2/farmers host/v1/farmers

Ниже приведены основные недостатки способа создания версий с использованием URI:

Мультимедийный способ управления версиями: Этот подход отправляет информацию о версии в заголовке каждого запроса. Когда мы изменим тип и язык мультимедиа URI, мы перейдем к рассмотрению контента на основе заголовка. Этот способ является наиболее предпочтительным вариантом для управления версиями REST приложений.

Пример информации в заголовке:

GET /account/5555 HTTP/1.1 Accept: application/vnd.farmers.v1+json

HTTP/1.1 200 OK Content-Type: application/vnd.farmers.v1+json

В мультимедийном подходе управления версиями клиент имеет возможность выбрать, какую версию запрашивать с сервера. Этот способ выглядит предпочтительней, чем подход с URI, но сложность возникает при кэшировании запросов с различными версиями, которые передаются через заголовок. Говоря простыми словами, когда клиент кэширует на основе URI, это просто, но, кэширование с ключом в качестве мультимедийного типа добавляет сложности.

Пагинация

Отправка большого объема данных через HTTP не очень хорошая идея. Безусловно, возникнут проблемы с производительностью, поскольку сериализация больших объектов JSON станет дорогостоящей. Best practice является разбиение результатов на части, а не отправка всех записей сразу. Предоставьте возможность разбивать результаты на странице с помощью предыдущих или следующих ссылок.

Если вы используете пагинацию в вашем приложении, одним из хороших способов указать ссылку на пагинацию является использование опции Link HTTP заголовка. Следующая ссылка будет полезной для вас.

Использование SSL

SSL должен быть! Вы всегда должны применять SSL для своего REST приложения. Доступ к вашему приложения будет осуществляется из любой точки мира, и нет никакой гарантии, что к нему будет обеспечен безопасный доступ. С ростом числа инцидентов с киберпреступностью мы обязательно должны обеспечить безопасность своему приложению.

Стандартные протоколы проверки аутентификации облегчают работу по защите вашего приложения. Не используйте базовый механизм аутентификации. Используйте Oauth1.Oa или Oaurh2 для лучшей безопасности ваших сервисов. Я бы рекомендовал Oauth2 лично из-за его новейших функций.

HTTP методы

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

Ниже представлены две характеристики, которые должны быть определены перед использованием HTTP метода:

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

REST HTTP методы

Ниже приведен краткий обзор каждого метода и рекомендации по их использованию:

Эффективное использование кодов ответов HTTP

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

Резюме

Надеюсь, эта статья будет полезна для понимания того, как создать свой REST API. Здесь представлены best practices, собранные на основе моего опыта и обсуждения с друзьями, которые работали над приложениями веб-служб REST.

Если вы много работали над дизайном REST API, и, если вы чувствуете, что эта статья не имеет для вас никакого смысла, я рад услышать ваши отзывы. Я хотел бы продолжить обновление этого обсуждения с помощью более проверенных методов разработки лучшего API для вашего приложения.

Хорошего прочтения. Спасибо за посещение моего блога.

При загрузке сайта пользователь может столкнуться с ошибкой 403: «Доступ запрещен». Рассмотрим, что она означает, почему появляется и как простыми способами ее можно устранить.

О чем говорит ошибка 403

Причины запрета доступа — ошибки 403

Как исправить ошибку 403 администратору

Исправление ошибки сервера 403 Forbidden — что делать пользователю?

Ошибка сервера 403: внешние факторы

О чем говорит ошибка 403

Ошибка 403 (403 Forbidden) в окне браузера означает следующее: веб-сервер, на котором работает сайт, определил, что посетителю запрещен доступ к веб-ресурсу (сайту, странице, каталогу, файлу) по URL, указанному в адресной строке.

Не следует путать ошибку 403 с 404-й, которая говорит, что URL неверный (ведет к несуществующему ресурсу).

В данном случае нет доступа к каталогу /thm — ошибка 403

А если ошибиться в одной букве (указать несуществующий каталог) — появится ошибка 404

Причины запрета доступа — ошибки 403

Причины запрета доступа к ресурсу могут быть следующими.

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

Технические факторы на стороне разных лиц:

Исправление ошибки 403 в случаях, когда это является проблемой, зависит от того, на чьей стороне (администратора, пользователя, провайдера) возник фактор, обусловивший ее появление.

Как исправить ошибку 403 администратору

Первым делом рассмотрим ситуации, когда администратор установил, сам того не желая, неверные параметры.

Некорректный файл индекса сайта

Типичная причина ошибки 403 — некорректное установление индексного файла. Этот файл (чаще всего веб-страница или скрипт) должен загружаться браузером из корневого (или иного) каталога по умолчанию при вводе URL. Индекс обычно не показывается пользователю (он нужен только браузеру).

На сайте promopult.ru индексный файл — index.php. Он загрузится, даже если в URL будет указано только доменное имя — браузер найдет индекс.

Браузер при обработке URL сначала пробует найти индекс по типовым именам файлов: index.html, index.htm, index.php. Если не находит и альтернативный индекс не настроен корректно, то веб-сервер отображает ошибку 403.

Что делать для исправления ошибки 403: проверить, правильно ли прописан индексный файл на веб-сервере.

Проверка индексного файла

Индексный файл фиксируется в конфигурационном файле сайта или каталога, например:

Может оказаться, что конфигурационного файла нет в принципе. Тогда его нужно будет создать (и вписать индексные строки) средствами CMS.

Некорректное месторасположение файлов сайта

Бывает, что индексный файл, вроде бы правильно отраженный в конфигурационных настройках, фактически отсутствует по адресу «прописки»: его нет в корневом или нижестоящих каталогах. Браузер не находит индекс, сервер выдает ошибку 403.

Частая причина этому в том, что веб-ресурсы (в том числе индексный файл) администратор размещает в каталоге с привычным для себя типовым именем (например, public_html). В то время как хостинг-провайдер использует для каталога другое имя (например, site или www). Браузер направляется сервером в «хостинговый» каталог для поиска индексного файла, а он пуст.

Необходимо всегда проверять фактическую доступность индексного файла по адресу, прописанному в конфигураторе. И размещать индекс в нужном каталоге.

Указаны некорректные права на файл или папку

Следующая возможная проблема — некорректные права на веб-ресурс. В отношении файла или каталога администратор может разрешить или запретить (в том или ином сочетании) чтение, запуск или редактирование:

Как исправить ошибку 403: настроить (изменить) права доступа к файлу или каталогу.

Настройка прав доступа

Права доступа прописываются с помощью команд операционной системы, на которой работает веб-сервер. Большинство базируется на Unix-подобных ОС, в которых предусмотрена общая системная команда для установления (изменения) прав доступа к файлам и каталогам — chmod. Она устанавливает права с помощью стандартизованного кода.

В числе распространенных кодов:

Часто бывает, что по ошибке устанавливаются права с кодом 700 вместо 755 — и тогда веб-сервер отказывает пользователям в доступе к файлу или каталогу и выдает ошибку 403. В данном случае администратору нужно подправить настройку chmod через консоль управления серверной ОС (команда sudo chmod 755 «имя файла»).

Отмеченный выше файл .htaccess используется в том числе и для установления прав доступа к веб-ресурсам. В нем могут содержаться строки («операторы») deny, allow (соответственно, запрещающие и разрешающие доступ к файлу или папке). И если те или иные параметры отражены в этих строках ошибочно, то при попытке доступа к ресурсу по URL выскочит ошибка 403.

Например, администратор хочет запретить доступ к файлу jinglesong.mp3, но по ошибке прописывает в .htaccess строки с неверным именем:

Доступ к сайтам ограничен для пользователей из определенного местоположения

deny from 192.168.1.0 (перепутал две последние цифры местами)

В результате пользователи с «легального» IP 192.168.1.0 получают ошибку 403. Чтобы исправить ошибку, вновь нужно открыть .htaccess и прописать корректный запрет:

deny from 192.168.0.1

Таковы основные причины ошибки 403, обусловленные непосредственно действиями администратора. Но есть технические факторы, прямо не зависящие от корректности настроек на веб-сервере. В их числе — сбои в работе плагинов.

Ошибку вызывает плагин

Плагины — программные дополнения к CMS (системе управления содержимым сайта), могут быть настроены на автоматическую блокировку доступа к ресурсам для «нежелательных» пользователей (например, с подозрительно высокой активностью). Если плагин устаревший или составляющие его скрипты повреждены, то такая блокировка может возникать по ошибке, без объективных оснований.

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

Отключение плагинов WordPress

В WordPress, одной из популярных CMS, все плагины можно отключить простым переименованием каталога plugins в разделе wp-content. Если после деактивации плагинов ошибка 403 исчезла, это значит, что проблема была в одном из них.

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

Рассмотрим теперь факторы, возникающие уже на стороне пользователя, и то, что ему делать для ликвидации ошибки 403.

Исправление ошибки сервера 403 Forbidden — что делать пользователю?

Можно придерживаться такого алгоритма:

1. Зайти на проблемный ресурс с другого компьютера (смартфона, планшета). Если получится, то ошибка, вероятно, обусловлена настройками браузера на исходном устройстве.

Эти данные используются для идентификации пользователя, которая может быть обязательной для получения доступа на сайт. Если она происходит некорректно, то сайт, не обнаруживший разрешения на доступ, будет выдавать ошибку 403.

2. Зайти на сайт через VPN, прокси-сервер. Если получится, то вы поймете, что сервер блокирует пользователя по IP (скорее всего, в той же привязке к местоположению). Придется и дальше работать через прокси или ждать, пока блокировку по IP для региона снимут.

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

Ошибка сервера 403

Ошибка 403 может возникать из-за причин, не обусловленных действиями администратора либо пользователей. Рассмотрим примеры таких ситуаций.

Не успел обновиться кэш DNS-серверов

Что делать: подождать 1–2 дня, пока кэш обновится автоматически. Либо очистить кэш на сервере вручную и настроить адресацию домена на правильный IP средствами CMS.

Приостановлено обслуживание сайта на конкретном хостинге

Бывает, что хостинг-провайдер реагирует на задолженность по оплате хостинга активацией настройки, выбрасывающей ошибку 403 при попытке открытия «сайта-должника». Она дезактивируется после оплаты. Если этого не произошло автоматически, нужно обратиться в службу поддержки хостинга.

Иные причины 403 ошибки

Прочие возможные причины ошибки 403:

Что делать: проверить настройки брандмауэра, отключить его, если он продолжит сбоить.

Что делать: если «перегруз» обусловлен стабильным трафиком, стоит разместить веб-ресурсы на более производительных серверах, а затем увеличить лимит или, по возможности, отключить его.

Что делать: определить часы минимальной посещаемости сайта и сконцентрировать проведение «отключений» в этот период.

Автор статьи: Ольга Бутовичева — SEO-оптимизатор компании SEO.RU

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

Покупатель, который ранее добавил пару обуви в закладки или перешел по ссылке из соцсетей, теперь попадет на несуществующую страницу. Вместо того чтобы искать товар снова, покупатель, скорее всего, закроет сайт.

Такие ссылки, ведущие в никуда, называются «битыми». Их необходимо своевременно находить и исправлять, чтобы не создавать проблем для посетителей сайта и не навредить поисковому продвижению.

В статье разбираем:

Что такое битая ссылка

(broken links) — это ссылка на страницу, которая больше не существует или была перемещена. Она может вызвать различные ошибки, в зависимости от конкретной причины проблемы со ссылкой.

Основные ошибки, связанные с битыми ссылками:

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

Откуда берутся битые ссылки

Обычно всего ссылки ломаются не специально, а по невнимательности при обновлении сайта. Вот самые частые причины:

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

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

Сторонние ресурсы могут содержать ссылки на устаревшие или удаленные страницы вашего сайта. Это может произойти, если вы удалили или переместили страницы, а внешние сайты не обновили ссылки. Поэтому устаревшие внешние ссылки — это следствие изменений на вашем сайте.

Сюда относятся различные опечатки при формировании ссылок — лишние или недостающие символы в URL, буквы в неверном регистре и т.д. Из-за этого ссылка ведет не туда, куда задумывалось.

Допустим, на сайте в статье должна быть ссылка на страницу контактов с адресом www.site.ru/contacts. Но вместо contacts кто-то ошибочно написал сontacs (с буквой «с» вместо "t"). Получился нерабочий URL www.site.ru/contacs, который выдаст ошибку 404.

Такие опечатки часто случаются при ручном написании или копировании ссылок.

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

Допустим, на сайте была страница по адресу www.site.ru/page.php, на которую вели ссылки с других страниц. Затем эту страницу решили перенести на новый URL www.site.ru/category/page.html. Чтобы запросы по старому адресу перенаправлялись на новый, настроили редирект в .htaccess:

Redirect 301 /page.php https://www.site.ru/category/newpage.html

Но допустили опечатку — указали newpage вместо page. Теперь редирект ведет на несуществующую страницу и выдает ошибку 404. В итоге из-за неверной настройки редиректа ссылки на страницу page.php стали битыми.

Когда вы меняете структуру сайта или систему управления сайтом (CMS), местоположение многих страниц на сайте меняется. Поэтому может сломаться множество внутренних ссылок.

Например, в некоторых CMS страницы статей могут находиться в подпапке /article/, а в других — в подпапке /content/. Поэтому при переезде могут возникнуть проблемы (при условии, что не настроили постраничные редиректы).

Чтобы по-прежнему можно было попасть на нужные страницы, нужно либо исправить старые ссылки (заменить в них слово «article» на «content»), либо настроить редиректы, чтобы сайт автоматически отправлял вас в новую папку, когда вы кликаете на старую ссылку.

Иногда на сайте размещаются ссылки не на страницы, а на различные загружаемые файлы — PDF, DOC, изображения, видео. Если такой файл удаляется или перемещается, ссылка на него перестает работать.

Ошибки в HTML, CSS или JavaScript коде сайта также могут привести к неработающим ссылкам. Например, опечатка в пути к CSS файлу сломает отображение элементов, на которые ведут ссылки

Например, в шаблоне сайта на WordPress ссылка на стилевой файл CSS указана с опечаткой:

Вместо style.css написано stile.css. Из-за такой ошибки стили на сайте не загружаются и могут отображаться некорректно, что делает их неработоспособными.

Читайте по теме: Внутренняя оптимизация сайта: инструкция по применению

Какой вред сайту наносят неработающие ссылки

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

Есть распространенное мнение, что большое количество битых ссылок и ошибок 404 истощает краулинговый бюджет (выделяемые поисковиком ресурсы на сканирование и индексацию страниц сайта), и ПС пропускает важные страницы.

Но эксперт Google Джон Мюллер опроверг это: стандартные ошибки 404 не влияют на скорость индексации других страниц сайта. Поисковик повторно проверяет такие URL, чтобы убедиться, что они действительно недоступны, но не в ущерб сканированию рабочих страниц.

Исключение — 404 SOFT, когда веб-сервер отвечает кодом 200 вместо 404. В этом случае ошибочная страница воспринимается как рабочая, поисковик тратит ресурсы на ее сканирование, что негативно влияет на общий краулинговый бюджет сайта.

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

Представители Яндекса влияние 404 ссылок на ранжирование сайта официально не комментировали. Однако Яндекс рекомендует использовать коды ответа 429 и 5xx, так как они сообщают роботу, что о трудностях в работе сервера. Это может замедленть индексирование сайта. Подробнее об этом — в Справке.

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

Как найти битые ссылки на сайте

Обнаружить проблемные ссылки на сайте можно как вручную, так и автоматизированно — с помощью сервисов.

Ручная проверка

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

Работает так: вручную переходите по ссылкам на сайте и проверяете их работоспособность. Можно проверять поочередно все страницы сайта или выборочно — наиболее важные разделы.

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

Google Search Console и Яндекс Вебмастер

GSC и Вебмастер предоставляют частичную информацию о битых ссылках на сайте на основе данных последних сканирований поисковыми роботами.

Где это смотреть:

Здесь отображаются URL, которые выдали ошибки при последнем сканировании Googlebot. Можно увидеть код ошибки для каждой страницы. Чаще всего это 404 ошибка для битых ссылок.

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

Инструменты для проверки ссылок

Существуют специальные сервисы, которые позволяют проанализировать все страницы сайта на наличие неработающих ссылок. Вот самые популярные:

Бесплатная программа для Windows. Она скачивает стартовую страницу сайта и рекурсивно обходит все внутренние ссылки для проверки. Выдает отчет в виде HTML-файла.

Похожий инструмент от компании Screaming Frog. Есть бесплатная версия с ограничением в 500 URL. Платная версия снимает лимиты.

Бесплатный англоязычный онлайн-сервис. Сканирует до 3000 страниц на наличие 404 ссылок. Если нужно проверить больше страниц — есть платная версия.

Сервис анализирует как внутренние, так и внешние/исходящие URL-адреса.

Чтобы запустить проверку сайта, нужно ввести URL-адрес в строку и нажать «Find broken links».

После анализа сервис соберет отчет по битым ссылкам в таблицу:

Инструмент для многих SEO-задач. В том числе в нем можно проверить наличие неработающих входящих и исходящих ссылок. Сканер Ahrefs является вторым по активности после Google.

Вот такой отчет по ссылкам сервис выдает в результате аудита:

Сервис платный — от 99$ в месяц. В России открывается только через VPN.

Плагин для сайтов на CMS WordPress. Автоматически сканирует ссылки на сайте в режиме реального времени. Проверяет сайты любого размера и типа, ограничений в объемах нет. Уведомляет, если находит ссылки с 404 ошибкой.

Бесплатное расширение для Chrome, которое поможет быстро проверить ссылки на конкретной странице.

Чтобы проверить битые ссылки, нужно установить плагин в браузере, зайти на страницу, где нужно отсканировать ссылки и нажать на иконку расширения (в верхнем меню браузера).

Все неработающие ссылки будут подсвечены на странице красным цветом, корректные — зеленым. Также расширение выдаст общее количество битых ссылок на анализируемой странице.

Главное преимущество таких программ — автоматизация процесса и скорость. Они могут за несколько минут проверить тысячи страниц.

Читайте по теме: 16 расширений браузера для маркетолога и SEO-специалиста