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

Анализ HTML кода

Задача: проверить код сайта на ошибки и валидность

Цель: определить нужны ли правки в коде сайта для исправления ошибок

Как делать:

1. Переходим на страницу сервиса https://validator.w3.org/.
2. Вбиваем сайт.
3. Листаем отчет вниз.
4. Смотрим количество ошибок и замечаний.
5. Даем в отчет информацию по кол-ву ошибок и ссылку на результат проверки.

Анализ верстки сайта

Задача: проверить верстку сайта

Цель: найти ошибки верстки сайта

Как делать:

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

Зайти в Я.Метрику Отчеты => Стандартные отчеты => Технологии => Разрешение дисплея.

Период данных=> Год

Фильтрация:

Посетители: больше 5

Отказы больше 15 (Опционально)

Отказы: от большего значения к меньшему

Группировки:

Технологии => Браузер

Технологии => Тип устройств

Поведение => Страница выхода

1. Скачиваем таблицу в формате xlxs с данными для удобной сортировки и тестирования.
2. Форматируем данные в эксель как таблицу для удобства работы.
3. Выделяем всю область таблицы.
4. На главной панели выбираем “Форматировать таблицу как”.
5. Выбираем цвет таблицы.
6. Не меняя настроек нажимаем ОК.

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

Методы тестирования:

Для оперы, гугл хрома и мобильных устройств

Режим разработчика в гугл хроме.

1. Нажимаем ctrl+shift+i.
2. Нажимаем ctrl+shift+M.
3. Тестируем собранный список разрешений, страниц, устройств.

Для Мозиллы

1. Нажимаем f12.
2. Нажимаем ctrl+shift+M.
3. Тестируем собранный список разрешений с браузером мозилла.

Самостоятельно тестируем верстку сайта на основных браузерах и разрешениях пытаясь найти ошибки верстки.

Тестируем браузеры: Гугл хром, Мозилла, Эдж. (Опера использует тот же движок, что и гугл хром поэтому проверять там не нужно).

Популярные разрешения брать из Я.Метрики

Тестировать основные типы страниц сайта (Главная, категория, контакты, карточка товара, страница услуги)

Отчеты — Стандартные отчеты — Технологии — Разрешение дисплея

Мобильная адаптивность сайта

Задача: проверить наличие и удобство мобильной пригодности сайта

Цель: найти ошибки мобильной версии сайта и способа ее реализации

Как делать:

1. Посмотреть долю мобильных посетителей. (Я.метрика-сводка, низ страницы, период «Год»).
2. Посмотреть показатель отказов по устройствам. (Отчеты-Стандартные отчеты-Технологии-Устройства. Период «Год» Вид: «Колонки» Диаграмма: «Показатель отказов»).

1. Протестировать сайт в сервисе гугла https://www.google.com/webmasters/tools/mobile-friendly/?hl=ru.
   

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

(Отчеты — Стандартные отчеты — Технологии — Устройства. Период «Год» Вид: «Колонки» Диаграмма: «Показатель отказов»

Протестировать сайт в сервисе
https://webmaster.yandex.ru/site/tools/mobile-friendly/

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

Эти проверки выполнять если мобильная версия сайта есть.

Проверяем верстку страниц по смартфонам и планшетам на косяки из файла из раздела “Проверка верстки сайта”, пунктов 3-4.

Режим разработчика в гугл хроме.

1. Нажимаем ctrl+shift+i.
2. Нажимаем ctrl+shift+M.
3. Тестируем собранный список разрешений, страниц, устройств.

1. Не забываем указать тип устройства “Mobile”. Если типа устройства нет.

Делать только если есть мобильная версия сайта.
Протестировать основные типы страниц на самых популярных 5 мобильных разрешениях.

Находим самые популярные мобильные разрешения.
Заходим в Я.Метрика — Отчеты — Стандартные отчеты — Технологии - Устройства.

Период: «Год»

Группировка:

Фильтр: Посетители по уменьшению.

Смотрим и тестируем 5 самых популярных мобильных разрешений.

Режим разработчика в гугл хроме.

1. Нажимаем ctrl+shift+i.
2. Нажимаем ctrl+shift+M.
3. Тестируем собранный список разрешений, страниц, устройств.

1. Не забываем указать тип устройства “Mobile”. Если типа устройства нет.

Анализ попадания сайта под фильтры поисковых систем

Как делать:

1. Проверяем сайт на наличие аффилиатов.
   Ищем в гугле и яндексе по номеру телефонов, названию компании, адресу и другим контактным данным, которые могут быть указаны на сайте аффилиате.
   При проверке текстов на уникальность, также можно найти сайты аффилиаты.
2. Я не рекомендую сразу делать данный пункт аудита полностью т.к не все санкции и фильтры показываются в вебмастерах. Поэтому для начала смотрим только санкции в вебмастерах. А остальная информация по возможным санкциям, которые не показываются в вебмастерах на сайте будет появляться по мере выполнения комплексного аудита.
3. Смотрим информацию по санкциям в вебмастерах. Я.вебмастер-Диагностика-Безопасность и нарушения. Гугл серч консоль-Поисковой трафик-Меры принятые вручную
4. Внимательно делаем не только технический, но и полный комплексный СЕО аудит и смотрим на ошибки и проблемы на сайте. Понимая какие вещи могут привести к санкциям на сайте, к падению позиций и посещаемости. Для этого стоит знать алгоритмы и санкции ПС. Если есть подозрения или жалобы клиента надо копать как можно глубже и использовать различные сервисы и методы. Например, https://seolib.ru/tools/pessimization-checker/

Проверка зеркала сайта

Задача: проверить главное зеркало сайта

Цель: найти ошибки в настройке главного зеркала сайта

Как делать:

1. Попробовать открыть сайт с www и без. Смотреть по плагину redirect path на какой версии стоит редирект и какой. Должен стоять 301 редирект с одного из зеркал сайта.
2. Проверяем настройки зеркал сайта в вебмастере Яндекса и Гугла.
3. Проверить директиву host в файле robots.txt в разделе Яндекса.

Для этого скачиваем файл роботс.тхт себе. Чтобы начать проверять и приводить в валидный вид.

Данная директива должна быть только для правил Яндекса
Должно быть указано главное зеркало сайта
Правило должно соответствовать правилам https://yandex.ru/support/webmaster/controlling-robot/robots-txt.html#host

1. На сервисе http://xseo.in/glue проверить сайт.
   
   Необходимо настроить 301 редирект на главное зеркало сайта по версии поисковых систем (какое зеркало в индексе)
   

Анализ настроек файла robots.txt

Как делать:

1. Проверяем наличие файла роботс.тхт по адресу site.ru/robots.txt. Если файла нет, рекомендуем создать правильно настроенный файл robots.txt для настройки индексирования. Если файл есть, то переходим к след пункту.
2. Тестируем запреты в файле роботс.тхт. Для этого запускаем сканирование лягушкой (программа screaming seo frog) со следующими настройками:

Configuration-robots.txt

Configuration-Spider

И смотрим результат сканирования в соответствующем разделе:

1. При обнаружении правил, которые запрещают индексирование нужных в индексе страниц - разбираемся зачем они были созданы и какие еще файлы/страницы они закрывают. Только удостоверившись, что удаление правила не сделает хуже и не откроет лишних страниц/файлов для индекса убираем правило из файла. Для этого рекомендуем производить тестирование сканируя сайт с кастомным файлом роботс.тхт в лягушке.
   Для этого переходим Configuration-Robots-Custom и вставляем новый файл роботс.тхт и повторяем сканирование сайта, анализируя какие страницы теперь закрыты/открыты
2. Проверяем:доступность всех нужных в индексе страницдоступность всех технических файлов и отсутствие запретов в файле. Необходимо, чтобы файлы цсс, изображений, явяскрипт были доступны для роботов ПСмы используем 3 правила для Яндекса, гугла и остальных ПС. Это не ошибка, но мы всегда приводим к виду 3 директив.наличие карты сайта.

   наличие директивы Host у Яндекса. При этом протокол указывается только при использовании https. Главное зеркало должно быть указано в соответствии с проверкой в соответствующем разделе аудита.

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

1. Добавляем новые правила в соответствии с проверкой индексации/мусорных/дублей страниц
2. Тестируем новый файл роботс.тхт в лягушке на случай ошибок.
   Для этого переходим Configuration-Robots-Custom и вставляем новый файл роботс.тхт и повторяем сканирование сайта, анализируя какие страницы теперь закрыты/открыты.
3. Тестируем файл роботс.тхт в сервисе яндекса https://webmaster.yandex.ru/tools/robotstxt/

Анализ индексации сайта

Задача: проверить индексацию

Цель: найти ошибки в настройке индексирования

Как делать:

1. Зайти в Я вебмастер. Посмотреть информацию по кол-ву загруженных страниц и страниц в поиске.

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

1. Заходим в гугл серч консоль. Смотрим сколько страниц проиндексировано гуглом. Отмечаем себе есть ли разница в индексировании гугла и яндекса и на что это может теоретически указывать.

1. Смотрим список исключенных страниц в вебмастере Яндекса. Для предварительного вывода по типам мусорных и ненужных в индексе страниц. Я.вебмастер- Страницы в поиске - Исключенные
2. Скачиваем список страниц просканированных Яндексом.Я.Вебмастер-Статистика обхода-Все страницы.
   Удаляем дубли
   Оставляем только страницы с ответом сервера 200ок

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

Страницы пагинации (если есть на сайте)

Здесь мы придерживаемся мнения, что необходимо проставлять только атрибуты rel="next" и rel="prev". И не используем каноникалы как рекомендует яндекс, потому что это противоречит Гуглу. Обращаю внимание, что только рекомендует! Т.к использование атрибутов rel="next" и rel="prev" соответствует рекомендациям Гугла и не противоречит правилам Яндекса. Поэтому мы используем данный метод.

Метод, когда создается страница “Показать все” мы не используем т.к данная страница будет слишком объемной и долго загружаться.

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

1. Проверить наличие тегов rel prev next. На первой странице должен быть только атрибут next, на последней только prev.
   Смотреть атрибуты в лягушке в разделе Directtives
2. Проверить отсутствие других тегов и настроек, закрывающих от индексации страницы пагинации. Не должно быть: каноникалов,закрытия в роботс.тхт, мета тега noindex
3. Проверить отсутствие дубля при переходе на основную страницу пагинации с других. Для этого находясь на 2ой или любой другой странице пагинации нажимаем на страницу 1.
4. Текст должен быть только на первой странице пагинации.
5. Проверка мета тегов на страницах пагинации. Мета теги не должны дублировать друг друга. 
   

Страницы сортировки, фильтрации (Если есть на сайте)

Как делать:

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

Фильтрация товаров по характеристикам:

Чаще всего это боковой блок с набором характеристик с чекбоксами и ползунками.

Сортировка по характеристикам:

Это сортировка по цене, названию, и тд

Различное представление:

Это отображение списком, карточками, по 10, 20 и тд товаров на странице.

1. Определить, как формируются страницы данного типа. Используется ли AJAX или же каждая страница имеет уникальный урл и соответственно может сканироваться роботом.
2. Проверить доступность таких страниц для индексирования. Данные страницы уже могут быть закрыты от индексирования и проблемы нет.
   В инструменте “Проверка статуса урл”
   Я.Вебмастер-индексация-проверка статуса урл
3. Если подобные страницы не нужны в поиске, а в 99% случаев они там не нужны, то формируем правила для файла robots.txt, чтобы закрыть от индексации подобные страницы. Подробно о формировании правил и тестировании robots.txt в соответствующем пункте.

Страницы результатов поиска (если поиск есть на сайте)

Как делать

Проверить наличие поиска на сайте

Проверить метод реализации результатов поиска. Для этого тестируем работу поиска и смотрим на урл
Если используется AJAX и урл после использования поиска. При анализе поиска на сайте обнаружено что используется технология AJAX. Т.е при взаимодействии с функцией поиска пользователь остается на текущей странице. Множества не нужных в индексе страниц не генерируется. Проблем не обнаружено.

Если AJAX не используется - переходим сразу к след пункту.

Проверить доступность таких страниц для индексирования. Данные страницы уже могут быть закрыты от индексирования и проблемы нет.
В инструменте “Проверка статуса урл”
Я.Вебмастер-индексация-проверка статуса урл

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

Если подобные страницы доступны для индексации
Переходим сразу к след пункту инструкции.

• Формируем правила для файла robots.txt, чтобы закрыть от индексации подобные страницы. Подробно о формировании правил и тестировании robots.txt в соответствующем пункте.

Анализ индексации изображений

Как делать:

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

Проверяем индексацию изображений с сайта в Гугле и Яндексе в поиске по картинкам оператором site:

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

Для этого берем урлы изображений и проверяем в сервисе яндекса https://webmaster.yandex.ru/tools/robotstxt/

Смотрим раздел изображений в лягушке и проверяем статус. Status и status code должны быть 200 ок, а не blocked by robots.txt
Если изображения доступны для индексации.

Изображения на сайте доступны для индексации. Проблем не обнаружено.

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

Пример трафика другого сайта с изображений

Мы убрали правило запрещающее индексацию изображений из robots.txt – пошел трафик из гугла!

Страницы с рекламными метками

Как делать:

1. Ищем в таблице просканированных страниц роботом Яндекса страницы с рекламными метками. Ищем по маскам utm и gclid.
2. Проверяем не закрыты ли они уже для индексации. Смотрим есть ли на данных страницах тег canonical. Смотрим закрыты ли данные страницы в robots.txt для Яндекса. (Страницы с рекламными метками закрывать от индексации в роботс.тхт советует только Яндекс. Гугл советует ставить только тег canonical. Поэтому мы используем такой метод.)

Если страницы с рекламными метками есть и не закрыты от индексации правильными методами.
В индекс попадают страницы с рекламными метками. Рекомендуем использовать тег canonical на данных страницах и закрыть от индексации данные страницы в robots.txt для Яндекса правилами
Disallow: *utm_*

Disallow: *gclid*

Cтраницы комментариев, отзывов, характеристик

Как делать:

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

1. Просматриваем проект в лягушке и файле просканированных страниц Яндексом. У данных страниц должен быть общий признак формирования урл, например, “?replytocom=”
2. Проверяем доступность данных страниц для индексации, рекомендуем настроить запрет их индексации.

Версия для печати

Как делать:

1. Проверяем на страницах сайта кнопки версии для печати.
2. Смотрим в результатах парсинга лягушки и просканированных яндексом страниц через поиск “print”
3. Проверяем доступность данных страниц для индексации, рекомендуем настроить запрет их индексации.

Другие мусорные страницы

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

1. Смотрим проект лягушки и просканированные яндексом страницы
2. При нахождении подозрительных URL, производим их анализ на предмет дублирования контента или мусорности
3. Стараемся определить причину как такие страницы образуются и попадают в индекс.
4. Находим оптимальный метод избавления от индексации подобных страниц на сайте.
5. Продолжаем смотреть проект лягушки и файл эксель просканированных яндексом страниц до тех пор, пока все мусорные страницы не будут найдены.
6. В итоге должен получится список нужных страниц на сайте, которые должны быть проиндексированы поисковыми системами! С данным списком страниц переходим к следующей проверке.

Проверка индексации важных страниц сайта

Как делать:

1. У нас должен быть список важных и нужных в индексе страниц после предыдущих шагов аудита. Или же составить такой список не составит труда.
2. Загружаем список в сервис Раш Аналитикс проверка индексации.

В настройках указываем проверку в Яндексе и Гугле

Смотрим на результаты отчета и проверяем страницы, которые не проиндексированы.

Проверяем весь список не проиндексированных страниц сканированием в лягушке на наличие правил, запрещающих индексацию. Это: роботс.тхт, noindex, nofollow, canonical, а также заголовки X-Robots-Tag (смотреть в ответе сервера).

Для Яндекса проверяем страницы в вебмастере. Где в отчете будет сказано почему страница не попала в поиск.
Вебмастер — Индексирование → Проверить статус URL.

Анализ XML карты сайта (sitemap)

1. Проверяем наличие карты сайта. Она должна быть указана в файле роботс.тхт. Если нет карты сайта, рекомендуем создать ее и регулярно обновлять при создании новых страниц на сайте. Если есть, переходим к след пункту
2. Смотрим информацию в вебмастерах по карте сайта. На случай ошибок и замечаний. В google search consolе показывает сразу и 404 страницы и закрытые от индексации, что упрощает поиск проблем и проверку.

1. В лягушке включаем режим работу по списку.

1. Загружаем по урл карты сайта карту сайта в лягушку. Если карта сайта разбита на несколько, то сканировать нужно все.

1. Нажимаем ОК. Ждем окончания сканирования.
2. Смотрим результаты сканирования.

1. 404 страницы. Видно сразу по ответу сервера.
2. Запрещенные в robots.txt. Видно сразу по параметру blocked by robots.txt.
3. Мусорные страницы, дубли. Ищем по найденным типам страниц из соответствующих разделов в аудите.

Проверка битых ссылок

1. Запускаем бесплатную программу XENU, которую можно скачать в интернете
2. Указываем следующие настройки

1. Указываем 1-2 потока. Иначе можно получить бан или положить сайт. В отчете только битые ссылки.
2. Запускаем сканирование проекта

1. Ждем окончания сканирования.
2. Жмем ДА для открытия отчета.

1. Возвращаемся к окну программы. Сортируем данные по Status, чтобы сначала были битые ссылки.

Проверка сайта на наличие вирусов

1. Проверяем сайт на вирусы на сайте https://www.virustotal.com/ru/.

1. Смотрим информацию в Я. Вебмастер и гугл серч консоль.Я.вебамастер — Диагностика— Безопасность и нарушенияГугл серч консоль — Проблемы безопасности

Анализ корректности ответа несуществующих страниц

• Берем любые урл, которых 100% нет на сайте. 2-3 урл.
• Открываем их. Смотрим ответ сервера по плагину redirect path.
• В отчет: если несуществующие страницы дают ответ 404 — все в порядке.

Наличие ответа сервера 304 если страница не изменилась

• Берем несколько страниц и тестируем на сайте https://last-modified.com/ru/.
• Если заголовок не найден - даем инфу в отчет, что необходимо сделать, чтобы был. Рекомендуем настроить на сайте кеширующие заголовки, если страница не изменилась. Т.е ответ 304.

Анализ оптимизации изображений

• Смотрим раздел изображений в лягушке.
• 
• Сортируем по Size. От большего к меньшему.

• Смотрим изображения на факт, что их можно сжать без потери качества. Размер указан в байтах! Для удобства можно выгрузить отчет и перевести байты в килобайты разделив на 8. На данном этапе важно найти слишком тяжелые изображения на сайте.
• Когда найдены такие изображения ищем страницы на которых данные изображения размещены. Для этого нажимаем на урл изображения в лягушке и переходим в нижнее информационное окно, в раздел inlinks. Там указаны страницы на которых данное изображение размещено или стоит ссылка на него.

• Проверяем данную страницу в сервисе https://developers.google.com/speed/pagespeed/insights/. Смотрим, чтобы была рекомендация сжать изображения более чем на 10% или больше чем 30-50кб.

Анализ использования Flash

1. При аудите сайта приходится просматривать огромное количество страниц сайта. Есть шанс заметить элемент на флеше.
2. В лягушке настраиваем поиск кастомных данных.Configuration-Custom-Search В первом поле вставляем .swf. Жмем ок.

1. Смотрим результаты парсинга сайта. В разделе Custom смотрим страницы на которых были найдены файлы с разрешением .swf. Если ничего не найдено, значит флеша на сайте нет.

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

• php;
• html;
• index;
• урл со слешем и без, но проверять надо не главную страницу, а любую другую;
• урлы с множеством слешей на конце;
• урлы с рандомными символами после слеша;
• урлы со знаком вопроса на конце и рандомными символами после;
• доступность http и https версий одновременно.

Редиректы

1. Смотрим информацию в лягушке по ответам сервера 3хх

1. Удаляем из отчета информацию по исходящим ссылкам на другие сайты.
2. Проверяем корректность установленных редиректов.
3. При временном перенаправлении необходимо использовать 302 редирект.
4. При постоянном перенаправлении необходимо использовать 301 редирект.
5. Проверяем, чтобы не было редиректов из меню, футера, подвала и других элементов, которые располагаются на всех страницах сайта. Смотря в лягушке кол-во входящих ссылок. При большом кол-ве входящих ссылок с других страниц большая вероятность того, что ссылка стоит в меню сайта.

Подводим итоги технического аудита сайта