Технический SEO-аудит крупного сайта

Для анализа сопоставлялись данные Screaming Frog, Яндекс Вебмастера, Google Search Console, XML Sitemap и фактическая структура URL.

Уже на первом этапе обнаружилось главное расхождение:

Источник	Количество URL
HTML-URL, найденные при краулинге	8 291
Действующие 200 + Indexable	7 133
URL в XML Sitemap	49 175
URL в поиске Яндекса	55 694
URL, известных Google	58 735
Проиндексировано Google	13 680

При этом в найденные краулером 8 291 HTML-URL входили не только действующие страницы, но также 1 074 URL с 404 и 84 URL с 301/302. Поэтому ориентироваться на реальную индексируемую структуру корректнее по 7 133 URL со статусом 200 + Indexable.

Яндекс показывал примерно в 6,7 раза больше URL в поиске, чем Screaming Frog обнаружил HTML-URL при внутреннем краулинге.

Главная проблема — раздувание массива URL

Самым важным результатом аудита стало не количество отдельных 404 или длинных Title, а несоответствие между:

• внутренней структурой сайта;
• XML Sitemap;
• ранее обнаруженными поисковиками URL;
• текущим поисковым индексом.

Яндекс держал в поиске около 55,7 тыс. URL.

Google знал примерно 58,7 тыс. URL, но индексировал только около 13,7 тыс.

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

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

Среди таких URL могли находиться:

• товарные модификации;
• старые адреса;
• страницы-сироты;
• файлы;
• страницы, обнаруженные через sitemap;
• URL из внешних ссылок;
• адреса предыдущих версий структуры.

Задача состояла в том, чтобы разделить этот массив на полезные самостоятельные страницы и технические или дублирующиеся URL.

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

Отдельно проверила XML Sitemap.

В карте находилось 49 175 URL, хотя действующих индексируемых HTML-страниц во внутреннем крауле было 7 133.

Получается:

49 175 / 7 133 ≈ 6,9

Причём 48 309 URL, или 98,2% sitemap, относились к /product/.

При этом в обычной внутренней структуре было найдено только 5 996 индексируемых товарных страниц /product/.

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

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

Сам факт существования SKU или технической модификации в базе ещё не означает, что для неё обязательно нужна отдельная индексируемая страница.

Для отбора товарных URL в белый список были определены критерии:

• код ответа 200;
• возможность индексации;
• самостоятельный SKU;
• отличающиеся характеристики;
• цена или коммерческий статус;
• наличие внутренней HTML-ссылки;
• самостоятельная ценность страницы.

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

Яндекс знал больше товарных URL, чем было в текущем sitemap

Отдельное сравнение показало:

То есть Яндекс учитывал ещё 5 265 товарных URL сверх текущей товарной sitemap:

53 574 − 48 309 = 5 265

Аудит связывал этот разрыв с возможным влиянием старых sitemap, товарных фидов, внешних ссылок и ранее существовавших URL.

Поисковые системы могут продолжать учитывать URL, обнаруженные ранее, даже если их уже нет в текущей sitemap или внутренней перелинковке.

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

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

Более тысячи URL с 404 в крауле

Из 8 291 HTML-URL:

Особенно большая проблема обнаружилась в технических файлах:

• /downloads/ — 556 URL с 404;
• /uploads/ — 478 URL с 404.

Всего это 1 034 несуществующих файловых URL.

На них вели как минимум 1 444 уникальные внутренние ссылки.

При проверке внутренней перелинковки в итоговой таблице аудита было выявлено уже 23 756 внутренних ссылок, ведущих на URL с ответами 3xx и 4xx.

Для исправления была предложена не массовая установка редиректов, а обработка URL по ситуации:

• Есть полный актуальный аналог → прямой 301.
• Файл или страница должны существовать → восстановить.
• Аналога нет → оставить 404/410 и удалить внутренние ссылки.
• Внутренняя ссылка ведёт через редирект → заменить href сразу на конечный URL с 200.

В поиске находились служебные и тестовые URL

В выгрузке Яндекса обнаружились адреса, которые не должны были участвовать в обычном поиске:

• 3 URL восстановления пароля;
• mail_test.php;
• google_feed_generator.php;
• /test-video/;
• /test-otzyvov/;
• страницы фильтрации;
• пагинация;
• технические файлы /uploads/.

Одного запрета в robots.txt для таких страниц недостаточно.

В зависимости от назначения URL было предложено:

• удалить страницу;
• закрыть её авторизацией;
• вернуть 404 или 410;
• убрать внутренние ссылки;
• исключить адрес из sitemap;
• прекратить его дальнейшую генерацию.

Обнаружились дубли главной страницы

Отдельно проверила варианты главной.

Код 200 возвращали:

• /index.php
• /index.html
• /index.htm
• /?
• адрес без завершающего /

и URL с несколькими последовательными слешами.

Всего в аудите проверили 15 вариантов главной, и они оставались доступными.

Для них было подготовлено ТЗ на приведение всех вариантов к одному основному URL с помощью прямых 301-редиректов.

Canonical отсутствовал у всех URL в выгрузке

Поле canonical в Screaming Frog было пустым у всех 8 291 HTML-URL.

В том числе:

Это не означает, что всем 8 291 URL нужно было автоматически поставить self-canonical: среди найденных адресов присутствовали 404 и редиректы.

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

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

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

378 страниц прайс-листа дублировали каталог

В разделе:

/podderzhka/prays-list/

было обнаружено 378 индексируемых страниц, которые повторяли Title и H1 соответствующих страниц /catalog/.

Например:

/catalog/kip/.../cl200/

и

/podderzhka/prays-list/kip/.../cl200/

У таких страниц совпадали поисковый интент, Title и H1, а canonical отсутствовал.

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

В качестве основного варианта было предложено использовать /catalog/.

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

SEO-фильтры индексировались бессистемно

Screaming Frog не нашёл во внутреннем крауле страниц вида:

/filter/.../apply/

но в выгрузке Яндекса обнаружились 25 фильтров со статусом SEARCHABLE.

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

Для фильтров была разработана отдельная логика.

Утверждённые SEO-фильтры

Оставлять:

• 200;
• index, follow;
• отдельные H1;
• Title;
• Description;
• self-canonical;
• HTML-ссылку из категории;
• включение в sitemap.

Обычные пользовательские фильтры

Использовать:

• noindex, follow;
• исключение из sitemap;
• отсутствие SEO-перелинковки.

Фильтр без товаров должен возвращать 404, а дублирующиеся адреса — приводиться к одному URL через 301.

Это направление позже можно выделить уже в отдельный кейс о проектировании SEO-фильтрации.

Robots.txt конфликтовал с общей стратегией индексации

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

Например:

Disallow: */?*

закрывал от обхода все URL с параметрами.

При этом некоторые параметрические адреса должны были оставаться доступными поисковому роботу, чтобы он мог увидеть 301, noindex или canonical.

Одновременно правило:

Allow: */?PAGEN*

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

?PAGEN_1=2&action=ADD2BASKET&id=

Такие сочетания уже встречались в отчётах индексации.

Также /catalog-1C/ был закрыт в robots.txt, но одновременно присутствовал в sitemap.

То есть разные технические механизмы сайта отправляли поисковым системам несогласованные сигналы.

Пагинация доходила до глубины 27

В крауле обнаружили 54 URL с PAGEN_, преимущественно в разделе «Видео».

Страницы имели одинаковый Title «Видео», а глубина обхода доходила до 27.

Для пагинации было предложено:

• выбрать единую стратегию индексации;
• убрать пагинационные URL из sitemap;
• не генерировать вариант первой страницы;
• не смешивать пагинацию с action, id, сортировками и другими параметрами;
• сократить чрезмерную глубину цепочки.

Проверили Title, Description и H1

Отдельно проанализировали шаблонную on-page оптимизацию.

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

Пороги 80 символов для Title и 200 для Description не являются лимитами поисковых систем. В аудите они использовались как контрольные значения для массового поиска перегруженных шаблонов.

При ручной проверке стало видно, что длину метатегов массово увеличивали повторяющиеся коммерческие фразы:

• «купить по выгодной цене»;
• «доставка по России»;
• «консультации»;
• «в наличии и под заказ»;
• «характеристики, отзывы, фото».

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

В sitemap находились служебные и устаревшие URL

В sitemap-pages.xml присутствовали:

• google_feed_generator.php
• google_merchant_feed.php
• mail_test.php
• news/index_back.php
• /catalog-1C/
• и другие технические адреса.

Также в sitemap новостей было 131 URL, тогда как внутренний краул обнаружил только 56 индексируемых страниц /news/.

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

Среди них могли находиться действующие страницы-сироты.

Поэтому каждый URL требовал проверки:

• 200 + indexable → оставить;
• 3xx → заменить конечным URL;
• 404/410 → удалить;
• noindex → убрать из sitemap;
• действующая страница-сирота → восстановить внутреннюю ссылку.

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

Обнаружились дубли URL в документах и полезных материалах

В /documents/ встречались пары вида:

/documents/tekhnicheskie-usloviya/

и

/documents/tekhnicheskie-usloviya/tekhnicheskie-usloviya/.

Для таких вариантов требовалось определить основной URL, оставить его в sitemap, а дубль перенаправить на основной.

Похожая проблема обнаружилась в полезных материалах.

Не менее 33 URL содержали повторяющийся slug:

/{slug}/

и

/{slug}/{slug}/.

Для них рекомендовалось оставить короткий адрес, настроить прямой 301 с двойного URL и исправить сам механизм формирования ссылок.

Проверили микроразметку

На проверенных шаблонах в доступном HTML не обнаружились полноценные:

• Organization;
• BreadcrumbList;
• корректная товарная Product;
• JSON-LD для основных сущностей.

При этом для разных типов страниц требовалась разная Schema.org-разметка.

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

Поэтому рекомендации были разделены для:

• главной;
• разделов каталога;
• подкатегорий;
• карточек товаров;
• хлебных крошек.

Проверили HTML-шаблон, семантику и доступность

Проверка HTML и общего шаблона выявила повторяющиеся проблемы:

• одинаковые id у разных элементов;
• неправильную вложенность ul/li;
• незакрытые ul и div;
• кликабельные div вместо подходящих интерактивных элементов;
• CSS <style> внутри контента;
• устаревший <font>;
• запрет масштабирования через viewport;
• устаревшие атрибуты;
• нарушение структуры отдельных компонентов.

Большая часть этих проблем повторялась на разных типах страниц, поэтому исправлять их вручную на отдельных URL было бессмысленно.

Нужно было менять общий шаблон.

Что получилось по итогам аудита

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

Проблемы были разделены по приоритетам:

• критические;
• важные;
• рекомендации.

Для разных типов URL определили дальнейшую стратегию:

• 200
• 301
  
• 404/410
  
• noindex
  
• canonical
  
• удаление из sitemap
  
• включение в белый список
  
• прекращение генерации

Отдельные ТЗ были сформированы для:

• очистки индекса;
• canonical;
• sitemap;
• robots.txt;
• дублей каталога и прайс-листа;
• SEO-фильтров;
• Title, Description и H1;
• микроразметки;
• хлебных крошек;
• HTML-шаблона.

После каждого этапа исправлений предусмотрен повторный контроль через Screaming Frog, sitemap в List Mode, HTML-проверку, Schema Validator, Rich Results Test, Google Search Console и Яндекс Вебмастер.

Итог

Технический аудит owen-chel.ru показал, насколько сильно на крупном сайте могут расходиться:

реальная внутренняя структура, XML Sitemap и массив URL, уже известных поисковым системам.

На момент анализа:

• 7 133 URL были действующими 200 + Indexable;
• 49 175 URL находились в XML Sitemap;
• 55 694 URL показывал Яндекс;
• 58 735 URL были известны Google;
• 13 680 URL Google индексировал.

Кроме этого, аудит выявил:

• 1 074 URL с 404;
• 23 756 внутренних ссылок на 3xx и 4xx;
• 378 индексируемых дублей прайс-листа;
• отсутствие canonical во всей выгрузке;
• 821 URL в группах дублирующихся Title;
• 1 339 URL в группах дублирующихся Description;
• 826 URL с дублирующим H1;
• 65 страниц без H1;
• технические URL в поиске и sitemap;
• проблемы robots.txt;
• бессистемную индексацию фильтров;
• проблемы пагинации;
• дубли в структуре документов и полезных материалов.

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

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

КОНСУЛЬТАЦИЯ

Нужен аудит сайта?

Пришлите адрес ресурса.

Ваш сайт Факс

Ваше имя

Телефон, e-mail или Telegram

Кратко опишите задачу

Обсудить

Согласен(на) с политикой обработки персональных данных