Ошибка при запуске сайта

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

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

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

Типы ошибок

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

Коды ошибок бывают положительными и отрицательными или успешными и не успешными.

Всего существует 4 типа кодов (хх — сочетание любых цифр):

• 2xx — запрос выполнен успешно;
• 3xx — запрос успешно перенаправлен (тоже положительный код);
• 4xx — ошибка — документ не был отправлен пользователю, так как произошла критическая ошибка. Класс кодов 4xx предназначен для указания ошибок со стороны клиента;
• 5xx — ошибка сервера — критическая ошибка на сервере. Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера.

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

Ошибка 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».

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

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

Диагностика сетевых устройств

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

Пользователям Windows доступна диагностика сети с помощью встроенных средств Windows. К сожалению, встроенные средствами Windows вы не сможете проверить правильность настроек DNS, правильность распределения и назначения ip-адресов внутри подсети и т.д. Но вы сможете проверить правильность установки драйвера сетевой платы, проверить

Для того, чтобы запустить средство устранения неполадок подключения к Интернету, откройте «Панель управления» -> «Центр управления сетями и общим доступом». Нажимаем по ссылке «Устранение неполадок». В открывшемся окне выбираем необходимый нам инструмент.

Если стандартными средствами устранить ошибку не удалось, а ошибка как вы думаете связана с настройками сети, либо с настройками сетевой карты мы рекомендуем начать с полного сброса настроек. Начните с настроек своей сетевой карты. Установите ip, маски, шлюза, DNS в положение автоматического определения настроек. Сбросьте настройки роутера. И заново, внимательно, постепенно настраивайте каждое устройство. Начните с роутера.

Сайт не загружается

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

Очищаем содержимое кэш службы DNS

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

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

Откройте командную строку, набрав “cmd” в строке поиска и введите следующую команду:

ipconfig /flushdns

Отключаем экспериментальный QUIC протокол от Google

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

Такое решение пригодиться вам, если вы для серфинга в интернете используете браузер Chrome. Запустите браузер и в строке адреса введите:

chrome://flags/

и найдите строку “Экспериментальный протокол QUIC”. Выберете “Отключить”

DNS Prefetching

DNS Prefetching позволяет делать предзагрузку контента в фоновом режиме. Используется в основном для отображения динамического контента. Технология позволяет уменьшить время загрузки сайта в среднем на 0,2 секунды.

Отключим DNS Prefetching в браузере Chrome

Наберите в строке адреса браузера команду:

chrome://settings/

Внизу страницы нажимаем «Показать дополнительные параметры». Прокручиваем страницу вниз до заголовка меню «Личные данные» и находим пункт меню «Использовать подсказки для ускорения загрузки страниц». Убираем галочку.

Отключим DNS Prefetching в браузере Firefox

По аналогии с Chrome наберем в строке адреса команду:

about:config

Соглашаемся с риском лишиться гарантии. В отрывшемся расширенном меню настроек браузера находим строчку

network.dns.disablePrefetch

Дабы ускорить поиск строки воспользуйтесь поиском. Для этого нажмите сочетание клавиш Ctrl + F и в открывшейся строке поиска введите “disablePrefetch”

Изменяем значение переменной на “true”

Ping и Traceroute

Логичней данный пункт поставить вторым, после проверки целостности кабелей. Ведь как правило легче запустить команду проверки ответа сервера сайта, чем сначала проверять все настройки сетевых подключений. Да легче. Но мы все-таки поставили его последним. Объясним почему.

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

С помощью команды ping выполняется проверка целостности и качество соединений в сетях TCP/IP, проверка возможности доступа и разрешения имен.

Traceroute – это служебная программа Windows, предназначенная для определения маршрутов следования данных в сетях TCP/IP.

Для запуска команды ping откройте командную строку и наберите:

ping <имя веб-узла>

Для запуска команды traceroute в командной строке наберите

tracert <имя веб-узла>

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

Резервные копии сайта

Вроде банальная вещь, однако до 90% текущих сайтов не имеют актуальной версии резервной копии. В каких случаях может понадобится резервная копия?

• Сайт взломали и начали рассылать спам
• Сайт взломали и перенаправляют на другой сайт
• Сами накосячили и сайт перестал работать
• Попробовали обновить старый сайт и тут началось )
• Какие-то проблемы с подрядчиками и сайт сломали

Последствия:

• Новые клиенты не поступают
• Сайт заблокировали
• Сайт резко потерял позиции

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

*в какой-то момент что-то пошло не так

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

* результат расставания с администратором

Какие рекомендации, чтобы избежать подобной ситуации?

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

Права на сайт

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

* в середине февраля фирма разделилась и один из учредителей забрал домен сайта себе и отключил магазин. Видно резко снижение количества переходов из поисковых систем. Магазин лишился до трети заказов через интернет.

*трафик только вернулся спустя полгода

Чётко контролируйте на кого оформлены права владения доменом, хостингом, лицензии сайта.

Покупка ссылок

Минусинск — алгоритм направленный на борьбу со ссылочным спамом

Ко дню запуска алгоритма 15 мая 2015г. 37% сайтов из рассылки значительно сократили количество используемых SEO-ссылок. Анализ показал, что, как и ожидалось, никаких катастрофически негативных последствий для ранжирования этих сайтов снятие ссылок не повлекло. Из оставшихся 63% сайтов 15 мая алгоритм выбрал первых «победителей». Ими стали 488 сайтов. Позиции данных сайтов были понижены в среднем на 20 пунктов.

Ниже представлены данные Метрики для сайта, который отказался более, чем от 70% входящих SEO-ссылок; и для сайта, который от ссылок не отказался и попал в первую итерацию Минусинска.

Как проверить обратные ссылки на существующем сайте?

• Яндекс
  вебмастер
• Google
  search console
• Мегаиндекс

Изучение спроса

Очень полезно перед выбором ниши изучить спрос. Интернет даёт очень широкие возможности для этого. Согласитесь заранее знать спрос в нише, поможет принять правильные решения.
Проверяется в сервисе

вебстат

. Данные показывают спрос за предыдущий месяц. Сумарный спрос в нише надо умножать на 1.3 (трафик с яндекс и гугл)

Тамже можно определить сезонность спроса, нажав историю запросов:

Авторские права

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

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

Формы обратной связи

Недавно было очень популярно везде пихать формы обратной связи. Однако, не все задумаются зачем они нужны. Если вы не можете ответить в течении 30 секунд каждому клиенту, или автоматически сохранить контакт, не нужно их устанавливать. Не дождавшись ответа сразу, клиент уйдёт к конкуренту!

* пример оперативного ответа от разработчика виджета

Копии сайтов (аффилиаты)

Аффилиаты (от англ. affiliate, аффилиат) — группа сайтов в одной тематике, чаще всего принадлежащие одной компании и практически не отличающиеся друг от друга как информацией, так и пользой для посетителя.

Аффилиат-фильтр — это реакция поисковых систем, в частности Яндекса, на появление большого числа (2 и более) аффилированных ресурсов, единственная цель которых — заполонить поисковую выдачу.

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

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

Сайтам, не нарушающим требования поисковых систем, санкции не страшны.

Анализ статистики

Бесценно знать сколько человек пришло на сайт, какие товары они смотрели. Из какого города она пришли. С какого сайта зашли.
Эти и многие другие данные, можно почерпнуть из счётчиков аналитики. Маркетологи и рекламщики скажут спасибо за бесценные данные. Ни один канал, кроме интернет, не сможет дать столько данных:

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

Бесплатные счётчики:

https://metrika.yandex.ru

https://www.google.ru/analytics/

Бизнес-аналитика:

http://roistat.com/ru/

Телефония

Проверяйте правильность заполнение телефона на сайта, а также его доступность. Был случай, когда в офисе использовалась новомодная атс, к которой подключались аналоговые номера. Вроде всё красиво, однако Исходящие звонки менеджеров происходили по номеру, который был указан на сайте. В итоге из-за настройки и старых линий половина клиентов просто недозванивалась!

Про цены

Тут всё просто. Ваша цена должны быть в рынке.

И цена ниже и за самовывоз есть в городе, выбор очевиден?

Изменение адресов страниц

URL — Uniform Resource Locator (адрес страницы, полная аналогия с почтовым адресом)

Если адрес поменялся робот не найдёт страницу и удалит её из поиска

Поисковым системам требуются время на обход и индексацию страниц.

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

Изменение url равносильно перезду. Почту доставляют на старый адрес и не факт, что она вернётся к Вам!

Favicon

Favicon — небольшая картинка (значок сайта), которая показывается рядом с сайтом в результатах поиска Яндекса, рядом с адресом сайта в адресной строке браузера и рядом с названием сайта в «Избранном» или в «Закладках» вместо стандартной, общей для всех картинки.

Делается за 5 минут, устанавливается на сайт тоже, если всё так просто, почему её нет на сайте?

Накрутки трафика

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

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

Как это выглядело в истории посещений:

* видно что подавляющее количество посещений идёт с одного ресурса. Складывается полное ощущение, что заходят люди.

Спустя месяц, после накрутки пришло данное письмо:

Поскольку, ни одного нового клиента получено не было, данное предложение было проигнорировано и отписано в соответствующие инстанции.
Будьте внимательны!

Желаем Вам избежать подобный ошибок с сайтом и исправить задолго до их появления.

Вы удивитесь, но проблема может быть в самом сайте 

Для начала убедитесь, что проблема именно с вашей стороны. Возможно, он не открывается из-за вашего устройства, роутера или провайдера. В таком случае какие-то действия нужно предпринять вам. Как минимум, перезагрузить роутер. 

А возможно, проблема — на сервере самого ресурса. Вам не стоит менять настройки и разбираться в устройствах, потому что его работа зависит не от вас. Откройте сайт isitdownrightnow.com и введите адрес нужного вам сайта. Вам отобразится состояние сервера в виде квадратика. Зеленый — сервер в порядке, и сайт исправно работает. Красный — сервер упал, и домен не загружается не по вашей вине.

Отключите антивирус 

Антивирусное программное обеспечение может определять веб-сайт как потенциально опасный и блокировать его загрузку. Программа «Лаборатории Касперского» делает это по ряду причин: 

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

Поменяйте DNS-сервер 

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

Интернет-провайдер выдает DNS автоматически. Вы же можете поменять их на статические. Это можно сделать с компьютера, смартфона, планшета или Wi-Fi-роутера. 

Как это делается на macOS: «Системные настройки» —> «Сеть» —> Нажмите в списке слева на активное соединение (с зелёным кружком) —> «Дополнительно» —> «DNS» —> нажмите кнопку добавления (+) внизу списка DNS-серверов. 

Нажмите «ОК» и перезагрузите компьютер. 

Подпись: Добавьте новые DNS-серверы. Так это выглядит на macOS. 

Как это делается на Windows 7, 8, 8.1 и 10: «Win»+R —> в появившемся маленьком окошке в строке «Открыть» пропишите команду: ncpa.cpl и нажмите кнопку «ОК» —> в окне «Сетевые подключения» нажмите правой кнопкой по значку активного подключения правой кнопкой мыши —> «Свойства» —> «Компоненты, используемые этим подключением» —> выделите пункт «Протокол Интернета версии 4 (TCP/IPv4)» («IP версии 4 (TCP/IPv4)») —> «Использовать следующие адреса DNS-серверов». В поле «Предпочитаемый DNS-сервер» введите 8.8.8.8, а в поле «Альтернативный DNS-сервер» введите 8.8.4.4 —> «ОК».

Далее в перечне «Компоненты, используемые этим подключением» выберите пункт «Протокол Интернета версии 6 (TCP/IPv6)» («IP версии 6 (TCP/IPv6)») —> отметьте пункт «Использовать следующие адреса DNS-серверов». 

В поле «Предпочитаемый DNS-сервер» введите 2001:4860:4860::8888, а в поле «Альтернативный DNS-сервер» введите 2001:4860:4860::8844 —> «ОК».

Перезагрузите компьютер.

Проверьте сетевые настройки 

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

В Chrome пройдите по «Меню» —> «Настройки» —> «Дополнительные» —> в разделе «Система» нажмите «Изменить настройки прокси-сервера». Вам откроются настройки сети компьютера. Отключите прокси-сервер. 

В Firefox пройдите по «Меню» —> «Настройки» —> «Дополнительные» —> «Сеть» —> «Настроить» и выберите «Без прокси» или «Использовать системные настройки прокси».

В Safari пройдите по «Safari» —> «Настройки» —> «Дополнительные» —> «Изменить настройки» и уберите флажки у всех опций, связанных с прокси-сервером.

Возможно, сайт запрещен на территории страны 

В ноябре 2016 года Роскомнадзор заблокировал доступ к социальной сети для поиска работы LinkedIn на территории России. Сайт внесли в реестр нарушителей закона о персональных данных — он отказался хранить информацию о россиянах на российских серверах.

В этом случае сайт не загружается на устройствах с российским IP-адресом. Доступ к нему перекрывают провайдеры и операторы по требованию законодательства. По данным на 2017 год, по этой же причине в России за 5 лет заблокировали 275 тысяч сайтов. 

Это тоже интересно:

Во время запроса информации с удаленного веб-сервера может возникнуть ошибка. Тогда веб-сервер посылает в ответ код ошибки HTTP. Например 404 — Not Found (ресурс не найден).

Коды состояния HTTP состоят из трех цифр от 100 и до 510. Они делятся на следующие группы:

1. Информационные (100-105).
2. Успешные (200-226).
3. Перенаправление (300-307).
4. Ошибка клиента (400-499).
5. Ошибка сервера (500-510).

Чтобы получить сведения об ошибке, введите её код в поле поиска по странице. Для этого нажмите сочетание клавиш CTRL + F и укажите номер.

100

Continue
Cервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.

101

Switching Protocols
Сервер предлагает перейти на более подходящий для указанного ресурса протокол; список предлагаемых протоколов сервер обязательно указывает в поле заголовкаUpdate. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола. Появился в HTTP/1.1.

102

Processing
Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.

200

ОК
Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.

201

Created
В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется[источник не указан 336 дней] ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ с кодом 202. Появился в HTTP/1.0.

202

Accepted
Запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.

203

Non-Authoritative Information
Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.

204

No Content
Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.

205

Reset Content
Сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.

206

Partial Content
Сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1. (подробнее…)

207

Multi-Status
Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.

226

IM Used
Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

300

Multiple Choices
По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.

301

Moved Permanently
Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.

302

Found, Moved Temporarily
Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, приуправляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.

303

See Other
Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.

304

Not Modified
Сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.

305

Use Proxy
Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.

306

(зарезервировано)
использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).

307

Temporary Redirect
Запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

400

Bad Request
Сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.

401

Unauthorized
Для доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Клиент может повторить запрос, включив в заголовок сообщения поле Authorization с требуемыми для аутентификации данными.

402

Payment Required
Предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговыхкомпаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

403

Forbidden
Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.

404

Not Found
Самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.

405

Method Not Allowed
Указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented). Появился в HTTP/1.1.

406

Not Acceptable
Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.

407

Proxy Authentication Required
Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.

408

Request Timeout
Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потеря связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.

409

Conflict
Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.Появился в HTTP/1.1.

410

Gone
Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.

411

Length Required
Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.

412

Precondition Failed
Возвращается, если ни одно из условных полей заголовка[неизвестный термин] запроса не было выполнено. Появился в HTTP/1.1.

413

Request Entity Too Large
Возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.

414

Request-URL Too Long
Сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST. Появился в HTTP/1.1.

415

Unsupported Media Type
По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.

416

Requested Range Not Satisfiabl
В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges[источник не указан 336 дней]. Введено в RFC 2616 (обновление HTTP/1.1).

417

Expectation Failed
По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).

422

Unprocessable Entity
Сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV.

423

Locked
Целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.

424

Failed Dependency
Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.

425

Unordered Collection —
Посылается, если клиент послал запрос, обозначив положение в неотсортированной коллекции или используя порядок следования элементов, отличный от серверного[уточнить]. Введено в черновике по WebDAV Advanced Collections Protocol[14].

426

Upgrade Required
Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено вRFC 2817 для возможности перехода к TLS посредством HTTP.

449

Retry With
Возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.

456

Unrecoverable Error
Возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных[источник не указан 336 дней]. Введено корпорацией Microsoftдля WebDAV.

500

Internal Server Error
Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в HTTP/1.0.

501

Not Implemented
Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.

502

Bad Gateway
Сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера. Появился в HTTP/1.0.

503

Service Unavailable
Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов. Появился в HTTP/1.0.

504

Gateway Timeout
Сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.

505

HTTP Version Not Supported
Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. Появился в HTTP/1.1.

506

Variant Also Negotiates
В результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

507

Insufficient Storage
Не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.

509

Bandwidth Limit Exceeded
Используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.

510

Not Extended
На сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

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

Для поиска и устранения сбоев чаще всего используют автоматизированные средства. Это могут быть встроенные инструменты 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, задействуются возможности сервиса 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 удобен для фрилансеров, поскольку больше нацелен на однопользовательскую работу с проектом. Командную деятельность на базе этого сервиса организовать можно путем интеграции с другим инструментом управления.

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

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