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

Диагностика проблем с «нестабильной доступностью» сайта

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

Итак, приступим.

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

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

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

Как найти причину?

1. Интернет — это огромное количество магистралей, ведущих от сервера к серверу, и бывают случаи, когда наш сервер работает и мы видим другие сайты, но вот путь пакетов от нас к нашему сайту оборван: сегментировалась сеть из-за сбоя роутинга или где-то произошел сбой в работе каналов провайдеров. Конечно же, в консоли команда traceroute (tracert в Windows) покажет, доступен ли сервер нашего сайта, через какие сервера идут пакеты и на каком месте они «стопорятся». Если же traceroute и ping не доходят до нашего сервера, но достигают сети хостера, то самое время звонить в техподдержку хостинга или сисадминам, так как, в этом случае, сложно будет что-то предпринять самостоятельно.

Traceroute и ping – несложные команды, в Википедии есть статьи на эту тему с вполне доступным описанием:
https://ru.wikipedia.org/wiki/Traceroute
https://ru.wikipedia.org/wiki/Ping

Если traceroute «залипает» где-то на магистральных каналах по дороге к сайту, то рекомендую обязательно проверить, как виден сервер / сайт с других серверов (компьютеров) мировой сети вне вашего провайдера. Они, с большой долей вероятности, используют другие магистрали и зачастую бывает видно, что traceroute через другие каналы успешно проходит к вашему серверу. Например,
http://network-tools.com/default.asp?prog=express&host=www.reg.ru

Если всё в порядке, то проблемы либо у вашего провайдера, либо у его провайдеров уровнем выше, но не возле вашего сервера и не на нём.
Теперь можно позвонить в техподдержку вашего локального провайдера и поинтересоваться: «какие там магистральные каналы лежат?»

2. Скорость и стабильность интернет-канала — это скорость и стабильность самого медленного и плохого канала связи на пути от вас к серверу. Определить, есть ли проблемы с потерями пакетов «по дороге», большие задержки пакетов между разными провайдерами или между вами и провайдером, можно с помощью утилиты mtr, а результаты утилиты особенно показательны при большом размере пакета и его возможной сегментации (например, 1500 байт).

Mtr – это что-то вроде совмещённых ping (опрос каждого сервера по пути следования пакетов) и traceroute (определение всего пути следования пакетов), но имейте в виду, что из-за постоянного потока пакетов утилита съедает достаточно много трафика.

Пример вызова:

mtr -s 1500 --report вашсайт.com

Запрос проверки к сайту yahoo.com:

HOST: xxx.reg.ru                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 31.31.xxx.xxx              0.0%    10   43.4  16.7   0.5 102.8  33.1
  2.|-- bdi-799.sr7.msk1.ip.di-ne  0.0%    10    1.5   1.5   1.5   1.7   0.1
  3.|-- vlan-793.br1.msk1.ip.di-n  0.0%    10    0.8   0.8   0.8   0.9   0.0
  4.|-- 31.28.19.100               0.0%    10    0.9   4.5   0.9  36.8  11.3
  5.|-- ae0-948-rt2.spb.cloud-ix. 90.0%    10   14.7  14.7  14.7  14.7   0.0
  6.|-- ae0-59-rt1.frk.cloud-ix.n 10.0%    10   37.7  37.8  37.7  38.3   0.2
...
 15.|-- po-15.bas2-7-prd.gq1.yaho 10.0%    10  204.7 207.0 204.5 211.1   2.8
 16.|-- ir1.fp.vip.gq1.yahoo.com  10.0%    10  204.7 227.4 204.7 281.4  32.1

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

Обычно, если имеется 30 – 50 % потерь больших пакетов, то проблемы с подключением уже становятся ощутимыми (страница «залипает», подтормаживает из-за недогруженных элементов), и чем выше процент, тем сложнее пробиться.

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

С подробной статьей по использованию mtr для диагностики проблем с каналом (на английском) можно ознакомиться здесь или на Википедии.
Некое подобие утилиты mtr в Windows NT — pathping.

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

3. Если перечисленные выше тесты проблем не выявили, то применяем основной наглядный и удобный инструмент – Chrome Developer Tools (Web Inspector в Safari, Firefox Develper Tools):
https://developers.google.com/chrome-developer-tools/
https://developer.apple.com/library/safari/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/Introduction/Introduction.html
https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor

При работе с Chrome Developer Tools (Menu -> Tools -> Developer Tools), во вкладке «Сеть» (Network), обновляем страницу нашего сайта и получаем отчёт о том, как грузятся все ресурсы на ней:

При успешной загрузке (пусть и медленной) страницы сайта будет видно: когда загрузится основной контент страницы и она начнёт формироваться для отображения, когда начнут работать на сайте все вложенные java-скрипты, завязанные на работу с элементами страницы и ожидающие полной догрузки основного кода и необходимых неопределённых дополнительных вложенных элементов. Этот момент на картинке выше: синяя вертикальная линия – это событие DOMContentLoaded, а красная вертикальная линия – срабатывание windows.onLoad event (когда скрипты уже отработали и сформировалась вся страница с элементами, догружается содержимое картинок).

С помощью этого информационного инструмента мы можем проверить, всё ли в порядке с загрузкой основного содержимого страницы и главного html-кода, то есть удостовериться, что наш сервер вполне «живой» и главный движок сайта не тормозит.
Это первый в списке элемент. Кликнув по нему, мы получим более детальное время ответа сервера:

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

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

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

Частая причина блокировок — это зависимость момента старта работы изменяющих / формируюших содержимое страницы (до привязки к событию DOMContentLoaded) скриптов от каких-либо внешних сервисов сбора статистики, рекламных движков или страниц обмена ссылками. Обычно это куски скрипта для вставки «ещё одного» внешнего скрипта:

<script>
document.write('<scr'+'ipt type="text/javascript"'+' src="http://jsc.dt00.net .... </script>

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

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

Вот и на скриншоте выше работа скриптов на странице началась с задержкой в 135 мс из-за загрузки рекламного скрипта с admobi.ru (admobi.js). Бывают случаи, когда сервер раздачи кода рекламы и статистики доступен, но отвечает медленно, а браузер, успешно с ним соединившись, может ждать отклика десятки секунд.

4. Как и с traceroute (п.1), информацию по загрузке страницы через Developer Tools (п.3) можно и нужно проверить «чужим взглядом на свой сервер» с помощью подобных внешних сервисов-анализаторов, например:
http://www.uptrends.com/aspx/free-html-site-page-load-check-tool.aspx

Как это выглядит:

и http://tools.pingdom.com/fpt/

Обратите внимание на финал таблицы первого сервиса с временными итогами. И на начало таблицы второго, с ранжированием «как ваш сайт доступен по скорости, в сравнении с другими сайтами сети», а также количеством запросов (элементов), объёмом и временем загрузки всей информации страницы.

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

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

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

• Проблема с работой плагинов, которых в современных браузерах сейчас тонны:
  • Отключите все и сравните;
  • Или наоборот, включите (ищите!) плагины adblock и ghostery.

• Первый контакт с сервером после перерыва.
  Инициация защищённой ssl-сессии для браузера обычно происходит медленней из-за первоначального обмена ключами и проверки сертификатов. Это происходит как раз при заходе на сайт после перерыва или очистки кэшей / ключей.
• Лаги с получением сертификатов или ключей при загрузке чужих (внешних) скриптов и элементов страницы, которые могут блокировать отображение: сборщики статистики, рекламные сети, баннерообменки.
• Все названные элементы из предыдущего пункта, если связь с нашим сервером хорошая, а вот с сервером, отдающим этот встраиваемый элемент — плохая или он перегружен.
  Как говорилось в одном из пунктов выше, пока не догрузится скрипт, может «залипать» рендер страницы, OnDom / OnLoad отрабатываются с задержкой. Часто бывает, что при просмотре других страниц этот элемент уже кэширован и всё в порядке. Тут можно попробовать исключить запросы на эти внешние сервера (опять же, видим тормоза в Developer Tools) путём внесения на локальном компьютере на время в hosts-файл по очереди:
  • сервер-сбора-статистики.ru 127.0.0.1;
  • рекламный-сервер.com 127.0.0.1;
  • и другие сервера, скрипты из которых вызываются на странице.

  Надо помнить, что если мы перенаправляем запросы вместо каких-то серверов в Интернете вовнутрь своей сети «прямо на свой ноутбук» (на localhost, 127.0.0.1), то мы можем получить секундную задержку, как в примере выше, где у нас на этот порт не отвечает по таймауту.

• Если страницу отдаёт не один, а несколько серверов по очереди при распределении нагрузки, то бывает, что мы через некоторое количество раз попадаем на какой-то «тугой» сервер, а потом снова на быстрые.
  Тут можно проверить, есть ли отдельное имя сервера из тех, на которые распределяется нагрузка, и поработать напрямую.
• Проблема с серверами отдачи статики, если она выдаётся другим сервером. Здесь зачастую последующие загрузки в порядке, так как вся статика идёт с ощутимым запасом времени устаревания (expired), вот и подтормозив однажды, далее страницы нормально загружаются. Четко это увидеть помогут Developer Tools с опциями очистки или отключения кэша.
• Если «тормоза» наблюдаются при редактировании страниц своего сайта, можно по очереди исключать элементы и блоки внешней рекламы и статистики со страницы и, обновляя, определять, в чем проблема.

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

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

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

Предупреждение: статья не претендует на академическую полноту, но точно поможет что-нибудь не упустить.

Всё посмотреть и прокликать

Сначала нужно проверить, что всё выглядит, как задумано заказчиком — сайт совпадает с макетом, кнопки работают и ссылки ведут, куда нужно.

Что проверять:

• Элементы страницы расположены как на макете на всех устройствах.
• Сайт одинаково выглядит и работает во всех нужных браузерах.
• Кнопки нажимаются и после этого что-то происходит, слайдеры крутятся, гамбургеры раскрываются.
• Все JavaScript-скрипты работают корректно.
• Отображается правильный контент.
• Отдаются нужные заголовки.
• Загружаются правильные шрифты.
• Фавиконка установлена.
• Текст отображается не кракозябрами (в 2020 такое редко, но бывает).
• Курсор интерактивный на интерактивных элементах и обычный на обычных.
• С локализацией всё в порядке (русская, английская версия).
• Страница не разъезжается, если включить блокировщик рекламы.

Иногда используют автоматические тесты, которые сравниваются отрендеренный результат кода аля интерфейс с рендер-версией приложения. Фактически, это сравнение скриншотов. Конечно, автотесты можно подготовить и для тестирования интерактивных элементов.

Инструменты:

• Реальные браузеры и устройства.
• Эмуляторы (BrowserStack, LambdaTest, Browsera, BrowserShots).

Ошибки JavaScript

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

Валидность кода

Нужно убедиться, что код удовлетворяет стандартам HTML/CSS, для этого есть специальные валидаторы. Узнайте, как проверить валидность HTML.

Веб-формы

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

Что проверять:

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

Неправильные ссылки

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

Локализация

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

Но недостаточно проверить перевод текстов в интерфейсе, ошибок и документации — есть ещё ряд нюансов. Например, нужно проверить представление дат и времени, поддерживает ли шрифт локальные символы, и есть ли режим RTL для стран, где текст читается справа налево.

Производительность сайта

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

Что проверять

• Как быстро браузер отобразит страницу?
• Сколько времени занимает доставка ответа от сервера к пользователю?
• Все ли ресурсы загружаются?

Иногда скорость загрузки зависит от контента, который используется на странице. Вот советы, как его оптимизировать.

• Использовать сжатие контента. Например, выбирать подходящие форматы графики и шрифтов.
• Включить серверное и клиентское кэширование
• Избавиться от неиспользуемых данных, которые подгружаются подзапросом. Например в приложении 10 библиотек JS, а используется только одна.
• Правильно настроить файлы Cookie
• Хранить статические данные на отдельном CDN-сервере.

Критерии качества

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

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

ТелеграмПодкастБесплатные учебники

Тесты

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

Макаке не нравится, как работает сайт

Проблемы с хостингом и сервером

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

Большая часть информации находится в панели управления хостингом.

Проверьте:

• используемую версию PHP: в августе 2022 года актуальная стабильная версия — 7.4, более старые могут содержать уязвимости;
• настройку файла конфигурации веб-сервера: ошибки влияют на безопасность на уровне сервера и могут повлечь за собой проблемы с кодировкой, ответом сервера, редиректами, HTTP-заголовками и прочим;
• режим работы PHP и других модулей: сбитая конфигурация будет задерживать ответ сервера;
• настройки сжатия и кэширования объектов.

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

Если у вас мало опыта в теме, советуем привлечь программиста для экономии времени и уменьшения ошибок.

Работа CMS, модулей и виджетов

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

Вебинар с конспектом по теме —
Как защитить сайт от взломов и атак

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

Наличие дубликатов сайта

У сайта не должно быть сайтов-дублей или копий отдельных страниц. Для оправданных дублей, например, страниц с одного и того же товара, есть rel canonical.

Проверьте доступ к другим версиям сайта и редиректы:

• сайт доступен по протоколу HTTPS, у него есть SSL-сертификат;
• настроен 301 редирект с версии сайта с www.site.com на основное зеркало без www — site.com (об этом подробнее в следующем пункте);
• настроен 301 редирект со страниц без слеша на конце на страницы со слешем — с https://pr-cy.ru/seo-guide/ на https://pr-cy.ru/seo-guide//;
• у дублей страниц, которые появляются оправданно, например, из-за параметров фильтрации в URL, прописан тег rel = «canonical».

Всем сессиям поискового бота присваивается идентификатор — параметр PHPSESSID. Когда бот посещает страницу, к URL добавляется этот параметр. В следующую сессию он будет новый, и если бот снова посетит страницу, у URL будет новый параметр. Все эти URL с разными параметрами как бы разные URL, хотя принадлежат одной странице. Это может навредить индексированию сайта. В адресе страниц не должно быть идентификаторов сессий.

Забейте в поисковик телефоны, указанные на вашем сайте, ИНН компании и другую регистрационную информацию. Это поможет быстро найти двойников: в выдаче с такой информацией должен быть ваш сайт и справочники.

Склейка доменов с www и без

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

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

Проблема решается указанием поисковикам основного зеркала и 301 редиректом на него. Проверьте, сделана ли склейка.

Как указать основное зеркало для Яндекса:

1. Откройте или создайте в корне вашего сайта файл robots.txt;
2. Добавьте строку Host: site.com, где site.com — основное зеркало вашего сайта.

Обработка информации ботом Яндекса займет около 2-3 недель. Ускорить учет новых указаний можно в Яндекс.Вебмастере.

Директива Host должна содержать указание на протокол HTTPS, если зеркало доступно только по защищенному каналу (Host: https://site.com).

В файле robots.txt необходимо использовать только Punycode для кириллических доменов

Как указать основное зеркало для Google:

1. Авторизуйтесь/зарегистрируйтесь в Google Search Console;
2. Добавьте ваш сайт, подтвердите права, если не сделали это ранее;
3. Нажмите на значок шестеренки и выберите «Настройки сайта»;
4. Укажите нужный вариант в разделе «Основной домен».

Google обрабатывает информацию от суток до двух недель.

Как настроить 301 редирект

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

1. Откройте/создайте в корне вашего сайта файл .htaccess.
2. Добавьте строки кода:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^www.(.*) [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

Подробнее о настройке:
Как настроить 301 редирект самостоятельно

Ошибки в разметке HTML и CSS

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

Ошибки могут появиться из-за установки сторонних плагинов, тем и других элементов. Самые распространенные ошибки в HTML и CSS:

• использовали не рекомендованный стандартом тег;
• в ссылки добавили лишние символы;
• не указали обязательный атрибут;
• не закрыли тег.

Для проверки HTML и CSS есть онлайн-сервисы HTML Validator и CSS Validator, они сканируют код и выдают подробный отчет на предмет ошибок. Отправить код для проверки можно по ссылке, можно загрузить из файла или скопировать и вставить в соответствующее поле.

Почитать по теме:
Проверка валидации кода: как найти ошибки в HTML и CSS

Корректность кодировки

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

Кодировка UTF-8 общепринята, она правильно отображает сайт и поддерживает кириллические символы.  Кодировка указана в строке, содержащей слово charset внутри тега head.

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

Для проверки используйте онлайн анализ сайта от PR-CY. Конкретные страницы со сбитой кодировкой вы найдете в модуле аудита внутренних страниц. Он покажет URL со всеми проблемами, вы сразу узнаете, что и где нужно исправить.

Почитать по теме:
Как настроить кодировку сайта самостоятельно

404 Not Found

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

Почему пользователи попадают на страницу, которая больше недоступна по старому URL:

• страница осталась в индексе поисковика и пользователь получил на нее ссылку в выдаче;
• на сайте остались внутренние ссылки на страницу;
• на нее ссылаются сторонние ресурсы;
• опечатка в адресной строке браузера.

Сервер должен отдавать пользователю страницу 404, если тот пытается перейти по некорректному URL. При этом таких пользователей не обязательно терять. Если сделать страницу в общем дизайне и разместить на ней ссылки на другие разделы сайта, он может перейти к ним. О том, как оформить страницу 404 — ниже.

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

Что сделать для оптимизации страниц 404

1. Сделайте так, чтобы пользователи не попадали на несуществующую страницу

Проверьте сайт на «битые» ссылки — внутренние и внешние. Для этого можно использовать панели вебмастеров Яндекс и Google, бесплатную программу Xenu’s Link Sleuth или плагин для WordPress Broken Link Checker, если используется соответствующая CMS.

Дальше определите, что делать с каждой из «битых» ссылок:

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

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

Чтобы страница удалилась из индекса, сервер при обращении к ней должен возвращать ошибку 404. Если страница существует, но не должна участвовать в поисковой выдаче, закройте ее от индексации правилами robots.txt или мета-тегом
noindex. При следующем обходе сайта роботом он выполнит запросы на удаление, страницы исчезнут из результатов поиска. 

Почитать по теме:
Чем вредят сайту битые ссылки? Способы их найти и исправить

2. Создайте оригинальную страницу 404 Not Found

Если пользователь попадет на несуществующую страницу, сервер покажет страницу 404 по умолчанию. В лучшем случае, это краткое пояснение, что пользователь не туда попал, и реклама вашего хостера, а может быть и просто «404 Not Found».

Скорее всего, пользователь покинет такую страницу. Оригинальная страница 404 поможет удержать его на сайте.

Какой сделать страницу 404:

• Оригинальная страница 404 должна соответствовать дизайну и идее вашего сайта. Пользователь должен понять, что попал именно на ваш сайт.
• Страница 404 не должна быть «тупиковой». Разместите на ней ссылки на основные разделы, поиск по сайту, ссылки на группы в соцсетях.
• Пользователь должен понять, почему он попал на несуществующую страницу. Добавьте небольшое текстовое пояснение, справочную информацию, живой чат с техподдержкой пользователей или форму обратной связи.

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

Чтобы указать серверу, куда перенаправлять пользователей, если возникает ошибка 404, используют директиву ErrorDocument в файле .htaccess в корневой папке сайта:

ErrorDocument 404 http://site.com/404.html

Где
http://site.com/404.html — адрес вашей оригинальной страницы 404.

Таким же способом с помощью файла .htaccess вы можете обрабатывать и другие ошибки сервера:

• 401 ошибка (ErrorDocument 401 http://site.com/page.html) — требуется авторизация;
• 403 ошибка (ErrorDocument 403 http://site.com/page.html) — доступ запрещен;
• 500 ошибка (ErrorDocument 500 http://site.com/page.html) — внутренняя ошибка сервера.

Работоспособность ссылок

Поисковик воспринимает ссылками объекты, заключенные в тег с атрибутом href. Все остальное — не ссылки в понимании поисковика, хоть на сайтах и встречаются ссылки, сделанные с помощью Javascript — с тегами div и span. Например, это встречается в каталоге в системе фильтров, которые применяет пользователь. Если в тегах фильтра нет ссылок с a href, поисковик их не увидит и страницы каталога могут не попасть в выдачу.

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

Javascript не стоит использовать для ссылок в меню, это затруднит индексацию. Вы можете проверить, как поисковый бот индексирует ссылки с помощью сервисов типа Screaming Frog или Xenu’s Link Sleuth. Проведите индексирование сайта два раза с включенным и отключенным JavaScript и сравните, есть ли разделы или страницы, недоступные из-за меню в JavaScript.

Еще проверьте, настроены ли ЧПУ — человеко-понятные URL или Friendly URL. Они произносимые, не содержат посторонних символов, поэтому выглядят естественнее, проще запоминаются и не ассоциируются со спамом.

Пример структуры: главная / категория / раздел / подраздел / товар (услуга, статья, другая страница).

Какими должны быть ЧПУ в SEO:

• естественная формулировка с произносимыми словами;
• транслитерация или перевод слова;
• могут упоминаться ключи, но без переспама;
• длина до примерно 70-90 символов;
• только прописные, без заглавных букв;
• дефис в качестве разделителя.

ЧПУ легко настраиваются в админке сайта на популярных CMS.

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

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

Мобилопригодность и кроссбраузерность

Быть удобным на мобильных — обязательное требование к сайтам от поисковиков. Google перешел на Mobile-first index, поэтому выстраивает выдачу, основываясь на мобильных версиях сайтов. Сайт должен корректно работать на всех устройствах, полностью помещаться в экран и не уступать десктопной версии по функциональности и оптимизированности.

Кроссбраузерность означает, что сайт корректно открывается во всех актуальных версиях браузеров.

О мобилопригодности сайта и отображении в браузерах нужно думать на стадии его разработки. Проверьте сайт:

• в robots.txt нет запрета для сканирования CSS и JavaScript и персонально для мобильного бота;
• макет умещается на смартфонах в область просмотра без горизонтальной прокрутки;
• кнопки работают корректно и достаточно крупные, чтобы попасть по ним пальцем;
• всплывающие объекты можно закрыть, крестик на видимой части экрана;
• элементы быстро загружаются;нет Flash-элементов, Java-апплетов и Silverlight-плагинов;
• текст достаточно крупный, чтобы читать с небольшого экрана;
• вся навигация помещается в экран;
• кнопка звонка или чата не мешает чтению контента;
• в компанию можно позвонить по клику на номер.

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

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

Фавикон

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

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

Поисковые системы не сразу начнут отображать фавикон, может потребоваться довольно много времени. Вы можете проверить, как они видят вашу иконку. Введите в поисковую строку https://favicon.yandex.net/favicon/site.com для Яндекса и еще https://www.google.com/s2/favicons?domain=site.com для Google, вместо site.com напишите ваш домен.

Скорость загрузки страниц

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

Оценить скорость загрузки можно с помощью нашего сервиса. Он анализирует этапы загрузки страницы в соответствии с набором показателей Core Web Vitals, в который входит:

• Время, за которое браузер отрисовывает самый крупный видимый объект в области просмотра.
• Отзывчивость браузера на первое действие пользователя на странице.
• Визуальная стабильность — оценка сдвигов макета во время загрузки страницы.

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

Интересное почитать:
Вообще всё о Core WebVitals и многое об ускорении сайта

Как увеличить скорость загрузки страницы:

1. Сократите размер кода CSS и JavaScript

Онлайн-сервисы для упрощения JavaScript и CSS удаляют из кода пробелы и комментарии, сокращая время его загрузки.

Советуем, к примеру, эти:

• Refresh-SF
• CSSResizer
• Minifycode
• Letteros

Больше инструментов и приемов оптимизации верхней части страницы.

Размещайте CSS-файлы в начале страницы, а JS-файлы — перед закрывающим тегом body. До момента отображения контента страницы браузер должен загрузить только стили, а скрипты — в последнюю очередь. Так пользователь быстрее увидит содержимое страницы. Если стили тоже перенести в низ страницы, то разметка после загрузки будет не стилизована, до момента загрузки стилей это будет выглядеть некрасиво.

2. Уменьшите объем загружаемых страниц

Используйте сжатие gzip, это сократит время передачи файлов браузеру.
В новых версиях Nginx gzip сжатие включено по умолчанию. Для включения сжатия gzip в Apache убедитесь, что подключен модуль mod_gzip. Далее добавьте в файл .htaccess следующие строки:

<ifmodule mod_gzip.c="">
     mod_gzip_on Yes
     mod_gzip_dechunk Yes
     mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
     mod_gzip_item_include mime ^application/x-javascript.*
     mod_gzip_item_include mime ^text/.*
     mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
     mod_gzip_item_exclude mime ^image/.* 
     mod_gzip_item_include handler ^cgi-script$
    </ifmodule>

Проверить работоспособность и степень сжатия gzip вашего сайта можно с помощью сервиса
GIDZipTest.

Подробности по теме:
Как уменьшить вес сайта — минификация кода, разное сжатие, кэширование

3. Включите кэш данных

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

Для веб-сервера на Nginx используется модуль expires в файле конфигурации:

location ~* .(js|css|png|jpg|jpeg|gif)$ {
    expires 86400s;
    log_not_found off;
    }

В строке
location ~* .(js|css|png|jpg|jpeg|gif)$ { перечисляются типы файлов, которые требуют кэширования. Допускается использование нескольких блоков для более гибкой настройки.

Строка
expires 86400s; указывает, сколько будет храниться кэш. Можно указывать значения:

• в секундах — s;
• часах — h;
• днях — d;
• месяцах — m;
• навсегда — max.

Либо можно указать дату в формате RFC 1123, когда кэшированный файл потеряет актуальность:

    expires Fri, 24 Nov 2017 01:01:01 GMT;

Строка
log_not_found off; отключает ведение лога сообщений с 404 ошибкой для указанных типов файлов. Это помогает снизить нагрузку на сервер.

Настройка кэширования на серверах Apache происходит в файле конфигурации или в файле .htaccess. Поддерживается как модуль expires, так и альтернативный способ Cache-Control.

Expires:

  <ifmodule mod_expires.c="">
     ExpiresActive On
     ExpiresDefault "access plus 2 month"
     ExpiresByType image/gif "access plus 4 months"
     ExpiresByType image/jpeg "access plus 4 months"
    </ifmodule>

Строка
ExpiresActive On включает кэширование.

Строка
ExpiresDefault «access plus 2 month» устанавливает срок кэширования по умолчанию в 2 месяца.

Строки
ExpiresByType image/gif «access plus 4 months» и ExpiresByType image/jpeg «access plus 4 months» задают срок кэширования 4 месяца для GIF- и JPEG-файлов.

Поддерживаются значения в:

• Годах — years, year
• Месяцах — months, month
• Неделях — weeks, week
• Днях — days, day
• Часах — hours, hour
• Минутах — minutes, minute
• Секундах — seconds

Cache-Control:

<ifmodule mod_headers.c="">
     <filesmatch ".(js|css)$"="">
     Header set Cache-Control "max-age=604800"
     </filesmatch>
     <filesmatch ".(ico|gif|jpg|jpeg|png)$"="">
     Header set Cache-Control "max-age=2628000"
     </filesmatch>
    <filesmatch ".(php|cgi)$"=""> 
    Header unset Cache-Control 
    </filesmatch>
    </ifmodule>

Этот код устанавливает время хранения JS- и CSS-файлов в кэше в 1 неделю, для файлов с расширением .ico, .gif, .jpg, .jpeg и .png — 1 месяц, а для .php и .cgi — запрещает кэширования.

Для Cache-Control время хранения файлов можно задать только в секундах. Самые популярные значения:

• Одна минута: max-age=60;
• Один час: max-age=3600;
• Один день: max-age=86400;
• Одна неделя: max-age=604800;
• Один месяц: max-age=2628000;
• Один год: max-age=31536000.

4. Оптимизируйте изображения

Оптимизируйте размер изображения под сайт. Не загружайте изображение на хостинг в разрешении 4000×3000, если отображаться оно будет в 800×600 без возможности увеличения по клику.

Бесплатные онлайн-сервисы для редактирования изображений:

• PicMonkey
• Pixlr
• BeFunky
• Больше сервисов для редактирования, цветокоррекции и скругления углов

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

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

Примеры с разной степенью сжатия JPEG:

JPEG Оригинал 95 Кб	JPEG Сжатие 27 Кб

Онлайн-сервисы для сжатия изображений:

• CompressJPEG;
• TinyPNG;
• Pngquant.

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

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

С осторожностью используйте изображения для оформления сайта. Везде, где это возможно, вместо изображений пользуйтесь CSS для создания фона.

5. Избавьтесь от лишних редиректов

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

Использование редиректа оправдано в случаях, если адреса страниц меняются по техническим причинам, для склейки доменов с www и без www и для перенаправления на мобильную версию сайта. 

Почитать по теме:
Как настроить 301 редирект самостоятельно

6. Уменьшите количество запросов к серверу

• Объедините все файлы JavaScript в один. 

Внимание! При обнаружении в JavaScript-файле ошибки браузер прекращает обработку этого файла. Поэтому, перед объединением всех файлов в один убедитесь в их полной работоспособности.

Чтобы обнаружить ошибки в JS, воспользуйтесь консолью веб-браузера. В Firefox и Chrome она есть по умолчанию.

В Firefox нажмите правой кнопкой в окне браузера, в контекстном меню выберите пункт «Исследовать элемент». Появится панель, в которой мы можем исследовать и отлаживать наш код. Рядом со вкладкой «Инспектор» есть вкладка «Консоль», она то нас и интересует. Переключитесь на нее, обновите страницу, и вы увидите все ошибки JavaScript. В Chrome консоль вызывается из контекстного меню или клавишей F12.

• Объедините мелкие графические элементы сайта в CSS-спрайты. 

Sprite Sheet — это одно большое изображение мелких графических элементов сайта, например иконок или кнопок. Благодаря CSS можно отображать каждый элемент отдельно.

Подробнее об использовании CSS-спрайтов читайте
здесь.

Это первая из трех статей о комплексном аудите сайта. В отдельных статьях рассмотрим SEO- и юзабилити-аудит. А если не хотите разбираться самостоятельно,
проверьте сайт в нашем сервисе. Он проведет полный аудит SEO, технички, ссылочного профиля, релевантности, трафика и остального, найдет ошибки на внутренних страницах и будет следить за позициями сайта.

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

Продолжение серии:

Самостоятельный аудит сайта: часть 2. SEO-аудит