Screaming Frog: полный технический аудит сайта
Screaming Frog SEO Spider — это не «программа, которая находит ошибки». Это настраиваемый краулер, который обходит сайт ровно так, как вы ему велели, и возвращает ровно те данные, которые вы попросили. Девять из десяти бесполезных аудитов рождаются на этапе настройки: специалист жмёт Start на дефолтных параметрах, получает 40 тысяч строк с параметрами фильтров, экспортирует вкладку «Page Titles» и присылает клиенту список из 900 «ошибок», половина которых ошибками не является. В этой статье — рабочая методика: как настроить краулер под конкретный сайт, что смотреть по каждой вкладке, какие пороги реально имеют значение, как подключить внешние источники данных, как обходить каталоги на сотни тысяч URL и как превратить выгрузку в приоритизированный список задач, который двигает SEO-продвижение, а не просто занимает место в отчёте.
Коротко
- Настройка занимает 10–20 минут и определяет 80% ценности аудита: без неё вы сканируете мусор и упускаете главное.
- Бесплатная версия ограничена 500 URL и не даёт настроек, интеграций и планировщика — для коммерческого аудита нужна лицензия.
- Ключевая развилка на старте — режим хранения: память (RAM) до ~100–150 тысяч URL, база на SSD — дальше и до миллионов.
- Одна ошибка в конфигурации robots.txt или включённом рендеринге JS меняет результат скана до неузнаваемости — проверяйте краулер на 200–500 URL перед полным проходом.
- Реальная ценность появляется на стыке скана с Search Console, системами аналитики и логами сервера: краулер показывает структуру, внешние источники — её ценность.
- Экспортируйте не вкладки, а Bulk Export и Reports: цепочки редиректов, входящие ссылки на битые URL и страницы-сироты лежат именно там.
- Приоритет ошибки определяется не типом, а сочетанием «масштаб × трафик × стоимость правки». Список из 900 равнозначных ошибок бесполезен.
Что Screaming Frog умеет и чего от него ждать не стоит
Frog — настольное приложение на Java, которое обходит сайт по ссылкам, как поисковый робот, и складывает всё найденное в таблицы: URL, коды ответа, метатеги, заголовки, canonical, hreflang, редиректы, изображения, ссылки, разметку, директивы индексации. Он не хранит историю, не рисует дашборды и ничего не решает за вас — он собирает факты. Всё остальное делает голова специалиста.
Важно сразу понять границы инструмента. Frog показывает сайт таким, каким его увидел бы робот при заданных вами настройках. Он не знает, какие страницы поисковик обходит на самом деле, с какой частотой и с какими кодами — это видно только в логах веб-сервера. Он не знает, что реально попало в индекс — это данные Яндекс.Вебмастера и Search Console. И он ничего не говорит о качестве контента и коммерческой ценности страницы. Поэтому полноценный SEO-аудит сайта — это всегда три источника: скан краулера, панели вебмастеров и логи. Frog отвечает на вопрос «как устроен сайт», логи — «как с ним обращается робот», панели — «что из этого дошло до индекса».
| Версия | Лимит | Что доступно | Для чего годится |
|---|---|---|---|
| Бесплатная | 500 URL за скан | Базовый обход, основные вкладки, экспорт | Лендинги, сайты-визитки, быстрая проверка гипотезы |
| Лицензия | Ограничен только железом | Все настройки, интеграции, JS-рендеринг, Custom Extraction, планировщик, сравнение сканов, база на диске | Любой коммерческий аудит, каталоги, регулярный мониторинг |
Практический вывод: если вы работаете с сайтами больше визитки, бесплатной версии не хватит буквально на первом же проекте — не потому что мало URL, а потому что без настроек скан не имеет смысла. Ровно то же касается конкурентов: обойти чужой каталог и снять структуру — стандартная часть анализа конкурентов, и там 500 URL заканчиваются на первой категории.
Настройка перед первым сканом: то, что определяет всё остальное
Дефолтные настройки Frog рассчитаны на «средний сайт в вакууме». Реальный проект всегда требует правки. Разберём по порядку то, что мы трогаем на каждом аудите.
Режим хранения и память
Configuration → System → Storage Mode. Два варианта: Memory Storage (всё в оперативной памяти, быстро) и Database Storage (данные пишутся на диск, медленнее, но объём почти не ограничен). Правило простое: до сотни тысяч URL хватит памяти, дальше — только база и обязательно на SSD, на HDD скан превратится в мучение. Одновременно в Configuration → System → Memory Allocation стоит выделить Java больше памяти, чем по умолчанию: разумный ориентир — не более половины оперативной памяти машины, иначе система начнёт свопиться и краулер встанет.
| Размер сайта | Режим хранения | Память для Java | Что ещё сделать |
|---|---|---|---|
| До 10 000 URL | Memory | 2–4 ГБ | Ничего, сканируйте как есть |
| 10 000 – 100 000 | Memory (при 16 ГБ ОЗУ) или Database | 4–8 ГБ | Отключить лишние проверки: изображения, CSS, JS-файлы |
| 100 000 – 500 000 | Database (SSD обязательно) | 8–16 ГБ | Сегментировать обход по разделам, исключить параметры |
| Свыше 500 000 | Database + сегментация | 16 ГБ и больше | Сканировать разделами, выборкой карточек, через List-режим |
Что вообще обходить
Configuration → Spider → Crawl. Здесь вы решаете, тратить ли ресурс на изображения, CSS, JavaScript, SWF, внешние ссылки, поддомены. На аудите структуры каталога изображения и скрипты чаще всего отключают — они раздувают скан втрое и мешают. Но если задача — оптимизация изображений и поиск пустых alt, наоборот, включают только их. Ключевой принцип: один скан — одна задача. Попытка «собрать всё сразу» на большом сайте заканчивается тем, что скан не доходит до конца.
Отдельно — чекбокс Crawl All Subdomains. По умолчанию Frog остаётся в пределах хоста. Если у проекта есть поддомены с контентом, их либо включают в обход, либо сканируют отдельно. Здесь же решается вопрос, который часто всплывает на аудите: правильно ли у клиента разнесён контент — тема разобрана в материале про поддомены и подпапки.
Лимиты
Configuration → Spider → Limits. Три важнейших ограничителя: максимальное число URL в скане, максимальная глубина обхода (Crawl Depth) и максимальное число параметров в строке запроса. Ограничение глубины — самый быстрый способ понять архитектуру: сканируйте с лимитом Depth = 3 и посмотрите, сколько коммерчески важных страниц вообще попало в выборку. Если карточки товаров начинаются с пятого уровня, у сайта проблема со структурой задолго до всех метатегов.
Скорость обхода
Configuration → Speed. По умолчанию Frog идёт в 5 потоков, до 5 URL в секунду. Для боевого сайта на скромном хостинге это может быть много: краулер способен уронить сервер или спровоцировать срабатывание защиты, и вы получите ложную картину из 429 и 503. Практика: на незнакомом сайте начинайте с 2 потоков и 1–2 URL в секунду, следите за колонкой Response Time. Выросло время ответа — снижайте темп. И обязательно предупреждайте администратора о планируемом скане: половина «загадочных» инцидентов на проектах — это чей-то краулер, запущенный в рабочее время.
Robots.txt, User-Agent и рендеринг
Configuration → robots.txt: краулер по умолчанию уважает robots.txt. Это правильный дефолт, но на аудите полезны оба прохода: с соблюдением директив (видим то же, что робот) и с игнорированием (видим, что спрятано за запретами — там регулярно обнаруживаются целые разделы, закрытые по ошибке ещё на этапе разработки). Режим «Ignore robots.txt but report status» — золотая середина.
Configuration → User-Agent: по умолчанию Frog представляется собой. Смена на Googlebot или YandexBot нужна в двух случаях — проверить клоакинг (отдаётся ли роботу другой контент) и обойти блокировку, если сервер режет неизвестные краулеры. Осторожно: некоторые сайты, наоборот, отдают роботам упрощённую версию, и скан под видом Googlebot покажет не то, что видит пользователь.
САМАЯ ДОРОГАЯ ОШИБКА НАСТРОЙКИ
Configuration → Spider → Rendering. Если сайт построен на React, Vue или Angular и контент подгружается скриптами, скан в режиме Text Only покажет пустые страницы без заголовков и ссылок — и вы сделаете вывод «у сайта катастрофа с метатегами», которой нет. Переключение в JavaScript Rendering решает вопрос, но замедляет обход в 5–10 раз и требует настройки таймаута рендера (по умолчанию 5 секунд, тяжёлым SPA нужно больше). Проверка занимает минуту: сравните на трёх URL число слов и ссылок в двух режимах. Расхождение в разы означает, что сканировать нужно с рендерингом. Подробно механика разобрана в статье про JavaScript-SEO.
Режимы работы: Spider, List, Compare
Frog умеет не только «обойти сайт от главной». Режим выбирается в верхнем меню Mode, и от него зависит вся логика работы.
Классический обход по ссылкам
Стартуете с любого URL, краулер идёт по внутренним ссылкам вглубь. Основной режим для аудита структуры, перелинковки и глубины вложенности.
Проверка готового списка URL
Загружаете список из файла, буфера обмена или sitemap.xml по ссылке. Незаменим для проверки посадочных после релиза, списка из выгрузки позиций или URL из Search Console.
Работа с метатегами офлайн
Загружаете таблицу с Title и Description и видите, как они обрежутся в выдаче по пиксельной ширине. Удобно для правки метатегов до выкладки на сайт.
Сравнение двух сканов
Сопоставляет сохранённые обходы: что появилось, что исчезло, где изменились коды и метатеги. Основной инструмент контроля после внедрения правок и при переезде.
Режим List отдельно хорош тем, что снимает главный недостаток обхода по ссылкам: краулер физически не увидит страницу, на которую не ведёт ни одна ссылка. Загрузите в List URL из sitemap.xml, из выгрузки Search Console и из системы съёма позиций — и пересечение этих списков со Spider-сканом даст вам страницы-сироты, о которых внутренняя навигация не знает.
Пошагово: как провести первый полноценный аудит
Разведочный скан на 300–500 URL
Ставите лимит и запускаете. Задача — не найти ошибки, а понять, как устроен сайт: работает ли рендеринг, не режет ли сервер краулер, есть ли параметрический мусор, какая реальная глубина. По итогам корректируете конфигурацию и только потом идёте в полный обход.
Настроить исключения и включения
Configuration → Exclude: регулярными выражениями отсекаете сортировки, UTM-метки, идентификаторы сессий, календари, страницы внутреннего поиска, корзину и личный кабинет. Configuration → Include — наоборот, ограничивает обход одним разделом. Это главный рычаг на больших сайтах.
Подключить интеграции до старта
API Search Console, системы аналитики и PageSpeed подключаются в Configuration → API Access и подтягивают данные прямо в таблицу скана. Подключать нужно до запуска: задним числом данные к завершённому обходу не присоединяются.
Запустить полный обход и сохранить проект
Скан крупного каталога идёт часами. Сохраняйте результат в файл проекта сразу по завершении — повторять обход ради забытого экспорта обидно и долго. В режиме Database Storage проект восстанавливается автоматически.
Пройти правую панель Overview сверху вниз
Frog сам группирует находки по разделам с числом затронутых URL. Это карта аудита: вы видите, где 3 проблемные страницы, а где 12 тысяч, и сразу понимаете, что системное, а что единичное.
Выгрузить Bulk Export и Reports
Самое ценное лежит не во вкладках, а в отдельных меню: цепочки редиректов (Redirect Chains), все входящие ссылки на битые URL (Inlinks to 4xx), страницы-сироты, конфликты canonical и hreflang. Выгружаете в CSV или XLSX.
Свести находки в один реестр с приоритетами
Каждая находка получает поля: тип, масштаб (сколько URL), влияние на трафик, сложность правки, ответственный, срок. Без этой сводки аудит остаётся набором вкладок, а не планом работ.
Повторить скан после внедрения и сравнить
Режим Compare показывает, что реально исправлено, а что «исправлено в отчёте разработчика». Через 3–4 недели после правок это единственный честный способ закрыть задачи.
Метатеги: что действительно считать ошибкой
Вкладки Page Titles, Meta Description и H1 — первое, куда все смотрят, и первое, где генерируют бессмысленные списки. Frog помечает как проблему всё, что выходит за его дефолтные пороги, но эти пороги — не закон природы, а настройка (Configuration → Spider → Preferences), и подходить к находкам нужно осмысленно.
| Находка во вкладке | Почему возникает | Насколько это важно | Что делать |
|---|---|---|---|
| Missing (Title / Description / H1) | Шаблон не заполняет поле, страница создана вручную | Критично для индексируемых посадочных, неважно для служебных | Заполнить или проверить, должна ли страница вообще быть в индексе |
| Duplicate | Один шаблон на группу страниц: пагинация, фильтры, города | Критично: прямой путь к каннибализации | Уникализировать шаблоном с переменными или убрать страницы из индекса |
| Over X Characters / Pixels | Длинный Title, обрезается в выдаче | Средне: обрезка бьёт по CTR, но не по ранжированию напрямую | Вынести ключевое в первые 50–55 символов, следить за пиксельной шириной |
| Below X Characters | Слишком короткий тег | Низкий приоритет сам по себе | Смотреть выборочно: короткий Title у главной категории — упущенная возможность |
| Multiple H1 | Вёрстка использует H1 в логотипе, слайдере, баннере | Средне: размывает смысловую структуру страницы | Оставить один H1, остальное перевести в H2/H3 или div |
| Same as H1 | Title скопирован из заголовка страницы | Средне: теряется возможность расширить охват | Развести: H1 — для пользователя, Title — под запрос и CTR |
Практическое правило приоритизации: сортируйте вкладку не по алфавиту, а по данным из подключённых интеграций. Дубль Title на странице с 4 000 показов в месяц и дубль на служебной странице без единого показа — это две задачи разного веса, и без внешних данных вы этого не увидите. Методику написания метатегов мы разбирали отдельно в статье про Title и Description, а логику структурирования заголовков — в материале про заголовки H1–H6.
Дубли, canonical и директивы индексации
Здесь Frog даёт три разных инструмента, которые часто путают.
Точные дубли определяются по хешу содержимого страницы: во вкладке Content фильтр Exact Duplicates показывает URL с полностью идентичным HTML. Это чаще всего технические копии: страница доступна со слешем и без, с index.php и без, с http и https, с параметрами и без. Такие вещи чинятся редиректами и настройками сервера, а не текстом.
Похожие страницы (Near Duplicates) считаются алгоритмом сходства с настраиваемым порогом — по умолчанию 90%. Этот отчёт требует включения Configuration → Content → Duplicates перед сканом и запуска постобработки Crawl Analysis после его завершения. Именно здесь вскрываются типовые беды каталогов: карточки товаров, отличающиеся одним параметром, и региональные страницы, размноженные автозаменой города.
Canonical живёт в отдельной вкладке и требует внимания к четырём сценариям: canonical отсутствует, canonical указывает на другой URL, canonical ссылается на неиндексируемую страницу, canonical образует цепочку или петлю. Последние два — самые вредные и самые незаметные. Как это работает и в каком порядке чинится, подробно разобрано в статье про canonical и дубли страниц.
ПРОВЕРЬТЕ ЭТО ПЕРВЫМ ДЕЛОМ
Вкладка Directives, фильтр Noindex. На каждом третьем аудите там обнаруживаются страницы, закрытые от индексации по недоразумению: остатки настроек тестового сервера, глобальный noindex на шаблоне раздела, мета-robots, добавленный плагином. Это находка, которая окупает весь аудит за один вечер: страница может быть идеально оптимизирована и вести на неё сотня внутренних ссылок — при noindex она не участвует в поиске вообще. Второй по частоте сюрприз — сочетание canonical на другую страницу вместе с noindex: поисковик получает противоречивые сигналы и решает по-своему.
Коды ответа, редиректы и битые ссылки
Вкладка Response Codes — вторая по практической отдаче после Directives. Разбирайте её не по общему числу, а по группам.
4xx. Frog покажет список битых URL, но сам по себе он бесполезен: чинить нужно не страницу, а ссылки на неё. Используйте Bulk Export → Response Codes → Client Error (4xx) Inlinks — выгрузка даст пары «битый URL → страница-источник» и текст анкора. Дальше решение принимается по источнику: битая внутренняя ссылка правится в вёрстке или контенте, битая внешняя — закрывается 301-редиректом на релевантную страницу, чтобы не терять ссылочный вес. Полная методика — в материале про битые ссылки и ошибки 404.
3xx. Единичный редирект нормален. Проблема — цепочки. Отчёт Reports → Redirects → Redirect Chains собирает всю цепочку в одну строку: исходный URL, каждое звено, финальный адрес и итоговый код. Цепочки длиннее одного звена появляются после каждого переезда и накапливаются годами. Каждое лишнее звено — это лишний запрос робота и потеря части передаваемого веса. Как правильно склеивать адреса, разобрано в статье про 301 редиректы.
Внутренние ссылки на редиректы. Отдельная и очень частая история: сайт переехал на https и слеш в конце, редиректы настроены корректно, но внутренние ссылки в меню и контенте по-прежнему ведут на старые адреса. Формально всё работает, фактически робот на каждой странице получает лишние переходы. Отчёт Redirect Chains с колонкой источника показывает это сразу.
5xx и таймауты. Если краулер получает серверные ошибки, сначала проверьте, не вы ли их вызвали своей скоростью обхода. Снизьте до 1 потока и повторите на выборке. Если 5xx воспроизводятся на низкой скорости — это реальная проблема сервера, и её нужно смотреть вместе с администратором и логами.
Внутренняя перелинковка и глубина
Самая недооценённая часть Frog — работа со связями. Три колонки, на которые стоит смотреть:
- Crawl Depth — число кликов от стартового URL. Постройте распределение (правая панель, Site Structure) и посмотрите, где лежит основная масса страниц. Если карточки на глубине 5–6, робот будет доходить до них редко, а вес до них не дойдёт почти совсем.
- Unique Inlinks — сколько уникальных страниц ссылается на данный URL. Коммерчески важная страница с двумя входящими ссылками — это ошибка проектирования, а не мелочь.
- Link Score — внутренний расчёт веса страницы по модели, близкой к PageRank. Считается только после запуска Crawl Analysis. Сортировка по этой колонке отвечает на неудобный вопрос: совпадают ли страницы, которым сайт передаёт больше всего веса, с теми, которые приносят деньги. Обычно нет.
Отдельно — отчёт Reports → Orphan Pages. Он появляется только если подключены интеграции или загружен sitemap: Frog сравнивает список URL, известных внешним источникам, со списком, найденным по ссылкам. Разница — страницы-сироты. Практические выводы и схемы исправления мы описали в статье про внутреннюю перелинковку сайта.
Интеграции: где скан превращается в аналитику
Configuration → API Access. Это то, что отделяет технический список URL от инструмента принятия решений: к каждой строке скана добавляются колонки с реальными данными.
| Источник | Что добавляет к скану | Какие вопросы закрывает |
|---|---|---|
| Google Search Console | Показы, клики, CTR, средняя позиция по URL | Какие из технических проблем сидят на страницах с трафиком; где высокие показы при низком CTR |
| Системы веб-аналитики | Сеансы, отказы, время на странице, конверсии | Есть ли смысл чинить страницу; какие разделы генерируют заявки |
| PageSpeed Insights API | LCP, CLS, INP, вес страницы, полевые данные | Массовая оценка Core Web Vitals по всем шаблонам сразу, а не по одной странице |
| Сервисы ссылочных метрик | Внешние ссылки и домены-доноры на URL | Какие битые страницы держат внешний вес и требуют 301 в первую очередь |
| Custom Extraction | Любые данные со страницы по XPath, CSS-селектору или регулярке | Цены, наличие товара, автор, дата, разметка, счётчики — всё, чего нет в стандартных вкладках |
PageSpeed API стоит отметить отдельно: он позволяет прогнать сотни URL и получить сводку по скорости в разрезе шаблонов. Это принципиально другой уровень разговора с разработкой, чем «вот один URL, у него плохой LCP». Общая методика ускорения — в статье про скорость загрузки сайта.
Custom Extraction — самый мощный и самый недоиспользуемый механизм. Типовые сценарии: собрать со всех карточек цену и статус наличия и найти товары с нулевой ценой; вытащить содержимое JSON-LD и проверить полноту микроразметки Schema.org; проверить, на всех ли страницах стоит код аналитики; собрать даты публикации статей блога, чтобы найти неактуальный контент; выгрузить количество отзывов в карточках. Рядом работает Custom Search — поиск произвольной строки в исходном коде: так за один скан находят забытые тестовые тексты, ссылки на разработчика, битые шорткоды и упоминания старого телефона по всему сайту.
Аудит больших сайтов: как не утонуть
Каталог на 300 тысяч URL нельзя просто «просканировать». Нужна стратегия.
Сегментация вместо тотального обхода
Обходите не сайт, а раздел. Configuration → Include с регуляркой на путь раздела даёт чистый скан одной ветки: категории отдельно, карточки отдельно, блог отдельно. Каждый скан быстрее, легче анализируется и даёт понятные выводы. К тому же проблемы на больших сайтах почти всегда шаблонные: если из 40 тысяч карточек проверить 3 тысячи, вы увидите те же самые ошибки шаблона, что и в полном обходе.
Отсечение параметрического мусора
Главный пожиратель ресурсов — комбинации фильтров. Configuration → URL Rewriting → Remove Parameters убирает указанные параметры из URL при обходе, схлопывая тысячи вариантов в один адрес. Альтернатива — Exclude по регулярке. Что именно резать, видно из разведочного скана: отсортируйте найденные URL и посмотрите на топ параметров. Это же упражнение — база для работы с фасетной навигацией и пагинацией, и напрямую связано с краулинговым бюджетом: то, что съедает ваш скан, ровно так же съедает обход робота.
Выборочный скан по списку
Для очень крупных проектов рабочая схема — режим List с осмысленной выборкой: все категории целиком плюс по 50–100 карточек из каждой категории плюс все URL с трафиком из Search Console плюс все посадочные из отчёта по позициям. Получается несколько тысяч URL вместо сотен тысяч, при этом покрыты все шаблоны и все страницы, которые реально приносят деньги. Похожий подход нужен и при аудите проектов, построенных методами programmatic SEO, где страниц может быть кратно больше, чем шаблонов.
Планировщик и командная строка
File → Scheduling позволяет ставить скан по расписанию с автоматическим экспортом в папку. Ночной еженедельный скан ключевых разделов с выгрузкой в общую папку — простой способ поймать регресс после релиза раньше, чем его заметит поисковик. Для более серьёзной автоматизации есть запуск из командной строки с заданной конфигурацией и списком экспортов — это уже почти конвейер, и логично сочетается с подходами из материала про автоматизацию SEO через API.
Экспорт и приоритизация: как превратить скан в план работ
Экспорт вкладки — это сырьё. План работ рождается только после приоритизации. Мы используем простую модель из трёх множителей: масштаб (сколько URL затронуто), влияние (есть ли на этих URL трафик и деньги), стоимость (часы разработки). Сначала делается то, где масштаб и влияние высокие, а стоимость низкая.
| Приоритет | Что относим | Почему сначала | Типовой срок |
|---|---|---|---|
| P0 — немедленно | Noindex на важных страницах, запрет в robots.txt, 5xx на посадочных, canonical на чужие URL, доступность сайта роботам | Страницы полностью выпадают из поиска; правка обычно занимает минуты | 1–3 дня |
| P1 — в текущий спринт | 404 на страницах с внешними ссылками и трафиком, цепочки редиректов, внутренние ссылки на редиректы, дубли Title у категорий | Прямая потеря веса и трафика, масштаб обычно велик | 1–2 недели |
| P2 — плановые работы | Шаблоны метатегов, глубина вложенности, перелинковка, near duplicates, hreflang, разметка | Требуют изменений в шаблонах и согласований, но дают устойчивый эффект | 3–6 недель |
| P3 — фоновые | Короткие Description, alt у декоративных изображений, единичные длинные Title, косметика | Влияние мало и локально; делается по остаточному принципу | По возможности |
Формат сдачи тоже имеет значение. Клиенту и разработчику нужны разные документы: разработчику — CSV со списком URL и конкретным действием по каждому, клиенту — сводка «что нашли, чем это грозит, что даст исправление». Присылать владельцу бизнеса выгрузку Frog на 12 тысяч строк — верный способ, чтобы её никто не открыл. Как выстроен нормальный процесс сдачи работ, видно в нашем портфолио, а состав и стоимость аудита — на странице цен на продвижение.
Типичные ошибки при работе с Frog
- Скан на дефолтах. Без исключений и лимитов краулер уходит в бесконечное пространство фильтров и календарей, а вы получаете отчёт про мусор.
- Забытый Crawl Analysis. Near Duplicates, Link Score, Orphan Pages и часть отчётов по sitemap не считаются автоматически — их нужно запустить отдельно после скана. Многие годами не знают, что эти данные вообще есть.
- Скан без рендеринга на JS-сайте. Приводит к ложным выводам о пустых страницах и отсутствующей перелинковке.
- Скан с рендерингом там, где он не нужен. Обратная крайность: обход замедляется на порядок без всякой пользы.
- Игнорирование мобильной версии. Скан только десктопным User-Agent пропускает проблемы адаптива и различия в контенте — а мобильная оптимизация давно определяет ранжирование.
- Вывод «ошибка» из окраски строки. Frog не знает вашего сайта. Дубль Title на служебных страницах или короткий Description на странице контактов — не проблема. Думать по-прежнему приходится самому.
- Отсутствие контрольного скана. Без сравнения до/после вы не знаете, внедрены правки или только заявлены. Compare делает это за две минуты.
- Скан в рабочее время на боевом сервере. В пиковые часы 5 потоков могут заметно ухудшить отклик сайта для живых пользователей.
Куда Frog не дотягивается
Полезно держать в голове границы. Краулер не покажет: фактическую частоту обхода роботом (логи), состав индекса (панели вебмастеров), позиции и видимость (системы съёма), спрос и семантику (Вордстат, Топвизор, Megaindex), поведение пользователей (Метрика). Он не оценит качество текста и коммерческие факторы. И он не заменит здравого смысла: список технических находок сам по себе не выводит сайт в ТОП — он убирает препятствия, чтобы работали структура, семантика и контент.
Правильное место Frog в процессе — фундамент. Сначала скан и устранение технических барьеров, затем внутренняя оптимизация по шаблонам, дальше контент и внешние сигналы. Если пропустить первый шаг, всё последующее работает вполсилы: вы наполняете страницы, которые робот не обходит, и оптимизируете метатеги там, где стоит noindex. Быстрая самопроверка по основным пунктам есть в нашем SEO чек-листе.
Частые вопросы
Для сайта-визитки или лендинга — да, 500 URL покроют весь объём. Но учитывайте, что в бесплатной версии недоступны настройки Configuration, интеграции с внешними данными, JavaScript-рендеринг, Custom Extraction, сохранение проектов и сравнение сканов. То есть вы получите список URL и метатегов, но не сможете ни отсечь мусор, ни присоединить трафик, ни проверить SPA. Для любого коммерческого аудита лицензия окупается на первом же проекте.
Зависит от скорости отклика сервера и настроек, а не от Frog. Ориентир для прикидки: на 3–5 URL в секунду за час обходится порядка 10–18 тысяч страниц. Каталог на 200 тысяч URL — это в среднем 12–20 часов при аккуратном темпе. С JavaScript-рендерингом умножайте на 5–10. Именно поэтому на больших проектах сканируют сегментами и по выборке, а не тотально: сутки ожидания ради данных, которые видны на 5% страниц, не окупаются.
Пять типовых причин. Первая — обход остановился на лимите URL или глубины в настройках. Вторая — раздел закрыт в robots.txt, а краулер по умолчанию его уважает. Третья — контент и ссылки подгружаются JavaScript, а рендеринг выключен. Четвёртая — на страницы просто не ведут внутренние ссылки, это сироты, и найти их можно только через режим List или интеграции. Пятая — сервер начал отдавать ошибки под нагрузкой и краулер получил 4xx/5xx вместо контента. Проверяйте в этом порядке.
Если стоит базовая HTTP-авторизация, Frog запросит логин и пароль при первом обращении. Если авторизация через форму, используется режим Forms Based Authentication во встроенном браузере. Если доступ по IP — попросите администратора добавить ваш адрес. Отдельный момент: на тестовом стенде почти всегда стоит глобальный noindex и запрет в robots.txt, поэтому сканируйте с игнорированием robots.txt, иначе получите пустой результат, а перед выкладкой в продакшн обязательно проверьте, что эти запреты сняты.
Frog работает локально: данные никуда не уходят, скан не ограничен тарифом, настройки гибкие до уровня регулярных выражений и XPath. Онлайн-сервисы удобнее для регулярного мониторинга с историей и отчётами для клиента, но почти всегда ограничены лимитами страниц и фиксированным набором проверок. На практике они дополняют друг друга: Frog — для глубокого разового разбора и нестандартных задач, облачные — для еженедельного контроля и графиков динамики.
Нет, если контент и ссылки присутствуют в исходном HTML. Проверяется за минуту: сравните на нескольких URL число слов и найденных ссылок в режимах Text Only и JavaScript. Совпадает — рендеринг не нужен, он только замедлит обход в разы. Расходится существенно — включайте обязательно, иначе аудит будет описывать несуществующие проблемы. Отдельно проверьте страницы с подгрузкой отзывов, характеристик и товаров по кнопке «Показать ещё»: там расхождение бывает даже на классических CMS.
Полный технический аудит — раз в квартал для среднего проекта. Контрольный скан ключевых разделов — раз в 2–4 недели и обязательно после каждого крупного релиза, смены шаблона, изменения структуры каталога или переезда. На активно развивающихся магазинах имеет смысл поставить еженедельный автоматический скан по расписанию с выгрузкой в общую папку: сравнение с предыдущим сканом ловит регресс за минуты, тогда как в панели вебмастера проблема проявится через недели.
Сначала снизьте скорость до 1 потока и 1 URL в секунду — в большинстве случаев блокировка снимается. Если не помогло, смените User-Agent на Googlebot или Chrome и проверьте, не срабатывает ли защита именно на строку Screaming Frog. Если и это не сработало, вопрос решается через администратора: ваш IP добавляется в исключения WAF или систем защиты от ботов. Косвенно эта ситуация полезна — она показывает, что защита сайта может так же резать и настоящих поисковых роботов, и это стоит проверить по логам.
Проведём технический аудит вашего сайта и доведём правки до внедрения
Просканируем сайт с правильной конфигурацией, подключим данные Search Console и аналитики, найдём выпавшие из индекса страницы, дубли, битые ссылки и цепочки редиректов. Отдадим не выгрузку на 12 тысяч строк, а приоритизированный план работ — и проконтролируем его внедрение контрольным сканом.
- Пакет «Старт» от 55 000 ₽/мес
- Пакет «Стандарт» 75 000 ₽/мес
- Пакет «Премиум» 95 000 ₽/мес
- Бесплатный аудит и прогноз
- Договор с гарантией результата
- Отчёты каждую неделю
Комментарии (14)
Егор
Таблицу «размер сайта — режим хранения — память для Java» распечатал и повесил рядом с монитором. Раньше просто ждал, пока Frog повиснет на 80 тысячах URL, и не понимал, что не так.
Марина_К
Узнала себя в первом абзаце. Запускала скан магазина на дефолтах, через сутки получила гору URL с сортировками и параметрами фильтров и честно пыталась это анализировать. Теперь сначала делаю разведочный проход на 300 URL и смотрю топ параметров — экономит день работы.
AdminSEO Мастер
Марина, всё верно — разведочный скан это самая окупаемая процедура во всём аудите. К Exclude добавьте ещё URL Rewriting → Remove Parameters: он не отсекает адреса, а схлопывает их в один, и общее число URL падает в разы без риска потерять нужный раздел.
vladimir77
Про Crawl Analysis реально не знал, хотя работаю с программой третий год. То есть Link Score и Near Duplicates у меня всё это время просто были пустыми колонками? И правильно понял, что запускать его надо после того, как скан полностью завершился?
AdminSEO Мастер
Владимир, да, именно так: это постобработка, она считается по уже собранному графу ссылок, поэтому запускается только после завершения обхода. И учтите, что Near Duplicates дополнительно требуют включить Configuration → Content → Duplicates ещё до старта — задним числом их посчитать не выйдет, придётся пересканировать.
Ольга
Совет про вкладку Directives с фильтром Noindex сработал в тот же вечер. У нас целый раздел с услугами оказался закрыт мета-robots со времён разработки, а все удивлялись, почему по нему нет ни одного показа.
Дмитрий В.
С сегментацией по разделам не всё так однозначно. Когда сканируешь ветку через Include, теряется общая картина перелинковки: входящие ссылки из других разделов краулер просто не увидит, и Link Score получается недостоверный.
AdminSEO Мастер
Дмитрий, замечание справедливое, и мы это разводим по задачам. Сегментированные сканы годятся для поиска шаблонных ошибок в метатегах, кодах ответа и разметке, а вот вес и глубину считаем только на общем обходе — пусть выборочном по карточкам, но охватывающем все разделы сразу.
Анна Т.
Только начинаю разбираться. Скачала бесплатную версию, а половины меню Configuration из статьи у меня просто нет — теперь хотя бы понятно почему.
Сергей_бизнес
Я не специалист, у меня производство. Подрядчик прислал ровно то, что вы описали: файл на несколько тысяч строк с колонками на английском и подпись «исправьте». Я его открыл один раз и закрыл. Как заказчику понять, аудит нормальный или это выгрузка ради галочки?
AdminSEO Мастер
Сергей, простой критерий: в нормальном аудите есть приоритеты и оценка последствий, а не просто перечень находок. Спросите у подрядчика, какие пункты относятся к P0, сколько URL затронуто по каждому и что изменится после правки — если ответа нет, значит выгрузку просто переслали как есть. Если нужен второй взгляд, можем посмотреть ваш сайт в рамках бесплатного разбора и сказать, что там действительно критично.
Костя_практик
Custom Extraction реально недооценён. Вытащил XPath статус наличия со всех карточек и нашёл около сотни товаров, которые полгода висели «нет в наличии» и при этом были в sitemap. Плюс тем же приёмом проверил, где отвалился код аналитики.
Ирина П.
А что делать, если сайт на Vue и с JavaScript-рендерингом обход идёт настолько медленно, что до конца не доживает? Ставить таймаут побольше страшно, а без рендеринга страницы пустые.
AdminSEO Мастер
Ирина, тотальный обход с рендерингом на SPA почти никогда не нужен. Сделайте выборку: все категории плюс по несколько десятков карточек каждого шаблона, прогоните её в режиме List с рендерингом, а полный скан оставьте в Text Only для кодов ответа и редиректов. Ошибки на таких сайтах шаблонные, и выборка их показывает не хуже, чем сутки обхода.
Тимур
Про скорость обхода подписываюсь двумя руками. Запустил дефолтные 5 потоков днём по боевому сайту на слабом хостинге и получил стену из 429, а заодно звонок от клиента. Теперь всегда начинаю с двух потоков и смотрю на Response Time.
Наталья_В
Таблица с P0-P3 — самое полезное в статье. Наконец есть чем аргументировать разработчикам, почему noindex чиним сегодня, а короткие Description когда-нибудь потом.
alex_dev
Я со стороны разработки. Насчёт цепочек редиректов кажется, что паника преувеличена: два-три звена никого технически не убивают, страница всё равно отдаётся. Хотя про внутренние ссылки на старые адреса согласен, это чинится в шаблоне за час и выглядит разумно.
Полина
Подскажите, а можно получить отчёт по страницам-сиротам, если доступа к Search Console клиента пока нет? Только через sitemap.xml?
Максим
Поставил ночной скан ключевых разделов через Scheduling с автоэкспортом в общую папку. Через две недели поймали релиз, после которого у половины категорий отвалился canonical. Сравнение через Compare заняло минут пять.