Интернет продвижение

компаний в сфере услуг

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

На сайте может оказаться критическое число ошибок и проблем, которые в сумме сведут на нет перспективы продвижения сайта в том виде, как он есть. Довольно часто бывает ситуация, когда нужно изначально вообще сменить CMS (движок) сайта на более современный, функциональный и подходящий для SEO оптимизации, чтобы не лечить слишком проблемного «пациента».

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

  1. Что нужно проверить по техническим настройкам сайта
  2. Как выполнять технические проверки
  3. Какие выводы делать на основе результатов анализа веб-сайта

Проверка наличия сайта в Яндекс Вебмастер и Гугл Вебмастер

Как делать:

  1. Проверяем наличие сайта по доступам, которые выдал заказчик.
  2. Если сайт не подключен к счетчикам и системам для вебмастеров - подключаем.

Рекомендуем статьи по теме

Как подключить панель Google Вебмастер

Как подключить и настроить Яндекс Вебмастер

Подключение и настройка Яндекс Метрики

Подключение Google Analitics

Смотрим на ошибки в системах, заносим себе в записки по аудиту.

В Яндекс вебмастер – раздел Диагностика сайта

yandex-webmaster

в Гугл вебмастере – вот эти пункты осматриваем

google-webmaster

Анализ cms сайта

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

Как делать: Зайти в админку по доступам клиента и посмотреть какую цмс они используют. Зачастую достаточно перейти по адресу site.ru/admin или site.ru/administrator и по оформлению авторизации в админку понятно что там за цмс.

Использовать сервис определения цмс https://2ip.ru/cms/

  • В отчет: Если клиентом используется wordpress, bitrix, joomla, другая популярная цмс то в отчет пишем: Используется “цмс название” удобная для работ над продвижением сайта. Все необходимые настройки доступны и легко расширяются плагинами и расширениями.

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

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

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

Анализ хостинга сайта

Задача:

  1. Определить какой хостинг использует клиент.
  2. Проверить наличие необходимых доступов.
  3. Проверить качество хостинга, нет ли отрицательного влияния.
  4. Хватает ли хостинга для потребностей клиента (с учетом будущего роста трафика и нагрузки).Цель: определить подходит ли клиенту его хостинг с учетом текущих и будущих потребностей. Хватает ли его мощности. Как часто происходят отказы хостинга. Нет ли отрицательного влияния на продвижение (медленная работа, частые отключения, “плохие” соседи, общий или выделенный айпи, и тд). Есть ли все необходимые доступы к базам данных и фтп для проведения работ.Определяем какой хостинг использует клиент. Как делать:

Если клиент предоставил доступы к хостингу - переходим на сайт хостинга и смотрим его название.

Если клиент не сказал какой хостинг использует и не предоставил доступы -
переходим на сайт http://www.whois-service.ru/ (или любой другой хуиз сервис)
вводим сайт клиента и смотрим строчки “nserver:”

hosting

Здесь будет указан хостинг сайта.

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

Проверить качество хостинга, нет ли отрицательного влияния.

Как делать:

Спросить клиента о качестве хостинга, доволен ли он, не жаловались ли на него работники.

Посмотреть отзывы на хостинг и качество поддержки в интернете.

Например на этих сайтах:
https://hosting-ninja.ru/
http://hosting101.ru/
Проверить какие сайты разрешает размещать хостинг. Не должно быть черных и серых сайтов строго! Такое соседство может дорого стоить в случае бана такого “соседа” по айпи адресу.
Посмотреть соседей по хостингу через поиск bing делая запрос вида ip:31.31.196.206 указывая айпи адрес сайта клиента. Не должно быть черных и серых сайтов строго!

  • Зайти в Яндекс Метрику => Стандартные отчеты => Мониторинг => Результаты проверки.
  • Выбрать период “Год”.
  • Посмотреть “Аптайм”.
  • Посмотреть “Типы ошибок”.
  • Если аптайм сервера менее 97-98%, то это является основанием обсудить смену хостинг провайдера!

Протестировать сайт клиента на нагрузку в сервисе http://loaddy.com/
но необходимо учитывать, что тестирование идет с очень далеких серверов и время загрузки из-за этого увеличивается.

Нам необходимо смотреть отношение кол-во посетителей/скорость загрузки и определить не ляжет ли сайт.

  • Смотрим в Я.метрике отчет по нагрузке на сайт. Делаем выводы по-поводу нагрузки на сайт, хватает ли хостинга для потребностей клиента.

Отчеты — Стандартные отчеты — Мониторинг — Нагрузка на сайт

Соотносим всю информацию произведенных проверок и делаем выводы хватает ли хостинга, есть ли негативное влияние и тд.

Анализ домена

Задача: Проверить возраст домена, кому принадлежал до клиента, след от старых санкций или ссылок.

Цель: проверить нет ли негативных последствий от домена для проекта

Рекомендуем статью по теме Как выбрать домен для SEO

Как делать:

Для определения возраста домена

  1. Перейти на сайт хуиз. http://www.whois-service.ru/ (или любой другой аналог).
  2. Вбить адрес проверяемого сайта.
  3. Посчитать возраст домена с момента его первой регистрации.
  4. Перейти по адресу веб архива http://web.archive.org/.
  5. Вбить адрес сайта.
  6. Посмотреть все сайты за период существования домена по данным вебархива.
  7. Сделать выводы: возраст домена, кто использовал домен и какие сайты размещались или же все время домен использовал только клиент.

Если сайт использовал не только клиент и размещались другие сайты:

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

Как проверить: http://www.tehpodderzka.ru/2015/11/check-manual-actions.html

Анализ протокола https/https

Как делать:

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

Анализ скорости загрузки страниц сайта

Задача: Проверить скорость загрузки страниц анализируемого сайта

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

Как делать:

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

Все отобранные страницы проверяем в сервисе https://tools.pingdom.com

Если скорость загрузки разных типов страниц сильно отличается, то проверяем их на 3 и 4 шагах.

Если примерно одинакова, то проверяем только главную страницу на 3 и 4 шагах. Что именно перегружает страницу смотрим в пункте “Content size by content type”.

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

Проверяем страницы в сервисе https://webo.in/

В отчет даем информацию по каждой проверяемой странице:

Скорость загрузки главной страницы вашего сайта из различных регионов России по данным сервиса https://webo.in/ равна:

poteri-sayta

skorost-zagruzki-sayta-po-regionam
Проверяем страницы в сервисе https://developers.google.com/speed/pagespeed/insights/

Помечаем в заметках аудита страницы у которых есть рекомендация «Оптимизируйте изображения» с возможностью уменьшить объем от 10% и выше или больше чем 30-50кб. Для раздела проверки «Оптимизация изображений на сайте».

Наиболее часто встречающиеся рекомендации сервиса

  1. Оптимизируйте изображения. Правильный формат и сжатие изображений позволяет сократить их объем.
  2. Используйте кэш браузера. Если указывать в заголовках HTTP дату или срок действия статических ресурсов, браузер будет загружать уже полученные ранее ресурсы с локального диска, а не из Интернета.
  3. Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы. Все содержание верхней части страницы отображается только после загрузки указанных далее ресурсов. Попробуйте отложить загрузку этих ресурсов, загружать их асинхронно или встроить их самые важные компоненты непосредственно в код HTML.
  4. Сократите время ответа сервера.
  5. Сократите HTML. Сжатие HTML-кода (в том числе встроенного кода JavaScript или CSS) позволяет сократить объем данных, чтобы ускорить загрузку и обработку.
  6. Сократите CSS. Сжатие кода CSS позволяет сократить объем данных, чтобы ускорить загрузку и обработку.
  7. Включите сжатие. Сжатие ресурсов с помощью функций gzip или deflate позволяет сократить объем данных, передаваемых по сети.
  8. Сократите JavaScript. Сжатие кода JavaScript позволяет сократить объем данных, чтобы ускорить загрузку, обработку и выполнение.
  9. Не используйте переадресацию с целевой страницы.
  10. Оптимизируйте загрузку видимого контента.

Выполнение рекомендаций данных выше позволит значительно улучшить скорость загрузки сайта. Мы рекомендуем, чтобы скорость загрузки сайта не превышала 2-3 секунд.

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

На сайте может оказаться критическое число ошибок и проблем, которые в сумме сведут на нет перспективы продвижения сайта в том виде, как он есть. Довольно часто бывает ситуация, когда нужно изначально вообще сменить CMS (движок) сайта на более современный, функциональный и подходящий для SEO оптимизации, чтобы не лечить слишком проблемного «пациента».

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

  1. Что нужно проверить по техническим настройкам сайта
  2. Как выполнять технические проверки
  3. Какие выводы делать на основе результатов анализа веб-сайта

Анализ HTML кода

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

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

Как делать:

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

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

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

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

Как делать:

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

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

otchet-razreshenie-displeya

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

period-god

Фильтрация:

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

filtr-posetiteli

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

filtr-otkazy

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

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

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

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

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

stranica-vyhoda

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

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

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

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

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

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

chrom-razresheniya

Для Мозиллы

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

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

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

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

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

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

otchet-razreshenie-displeya

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

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

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

Как делать:

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

audit-mobilnosti

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

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

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

audit-mobilnosti-2

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

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

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

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

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

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

razresheniya-2

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

mobilnaya-versiya

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

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

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

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

gruppirovki

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

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

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

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

chrom-razresheniya

  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-robots

Configuration-Spider

configuration-spider

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

rezultaty-skanirovaniya

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

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

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

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

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

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

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

Как делать:

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

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

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

google-search-console

  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
Если изображения доступны для индексации.

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

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

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

analiz-trafika

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

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

Как делать:

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

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

Disallow: *gclid*

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

Как делать:

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

stranicy-kommentariev

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

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

Как делать:

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

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

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

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

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

Как делать:

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

rush-analytics

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

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

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

proverka

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

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

Как делать:

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

Я.вебмастер-индексирование-файлы sitemap

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

sitemap

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

lyagushka-rezhim

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

zagruzit-saytmap

url-sayta

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

Ищем:

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

Находим в карте сайта найденные ошибки и делаем скриншот для отчета.
Пример:

stranica-404

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

Как делать:

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

xenu

xenu-2

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

xenu-3

xenu-4

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

xenu-5

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

xenu-6

Битые ссылки мешают пользователю пользоваться сайтом и ухудшают ранжирование. Рекомендуем исправить битые ссылки.

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

Как делать:

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

proverka-na-virusy

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

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

Как делать:

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

Если несуществующие страницы дают ответ сервера 200ок (Успешно) — так быть не должно и нужно вмешательство программиста.

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

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

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

Размер изображений

Как делать:

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

screaming-frog-2

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

screaming-frog-3

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

optimizaciya-izobrajeniy

Если изображения можно сжать более чем на 10% или больше чем 30-50кб, то рекомендуем провести их оптимизацию.

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

Как делать:

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

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

screaming-frog-4

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

screaming-frog-5

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

Поиск дублей на сайте

Как делать:

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

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

poisk-dubley

screaming-frog-6

Частные случаи, которые надо проверить:

Добавляем эти окончания к урлам проверяемого сайта

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

Также проверяем:

Иерархию товара, когда один и тот же товар доступен в разных разделах и категориях.

Пример:

http://mysite.com/catalog/dir/tovar.php

http://mysite.com/catalog/tovar.php

http://mysite.com/tovar.php

http://mysite.com/dir/tovar.php


Рекомендуем избавиться от дублей на сайте. Т.к дубли ухудшают ранжирование сайта и индексирование.

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

google-search-console-2

Я.вебмастер — Инструменты — Удалить урл

Редиректы

Как делать:

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

redirekty

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

vhodyashie-ssylki

Если есть проблемы с редиректами
При временном перенаправлении необходимо использовать 302 редирект
При постоянном перенаправлении необходимо использовать 301 редирект

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

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

Напомним, что продвижение сайта включает в себя самые различные аспекты, такие как работа с семантическим ядром, структурой разделов сайта, внутренней СЕО оптимизацией, юзабилити, ссылками.

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

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

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

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

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