Screaming Frog SEO Spider — настольный краулер: программа обходит сайт по ссылкам и собирает технические данные по каждому URL. С ее помощью находят битые ссылки, цепочки редиректов, дубли метатегов, ошибки canonical, закрытые страницы и другие проблемы. Программа не выносит готовый SEO-вердикт: специалист должен настроить обход, понять контекст URL и проверить найденные отклонения.
Что обновлено 25.08.2026 для «Screaming Frog SEO Spider: как провести технический аудит сайта»: удалён массовый универсальный хвост; добавлены QA-контроли данных и пример различения причин одного симптома; уточнены ограничения и действия после проверки.
Возможности и подготовка
Следующий связанный шаг: BI для SEO на 800+ поддоменов. Для материала «Screaming Frog SEO Spider: как провести технический аудит сайта» эта ссылка продолжает соседнюю задачу без повторения текущего раздела.
Что умеет Screaming Frog
SEO Spider имитирует обход сайта роботом и сводит ответы сервера, директивы индексирования, заголовки, ссылки, изображения и другие элементы в таблицы. Это быстрее ручной проверки, особенно когда у сайта сотни или тысячи адресов.
Краулер показывает техническое состояние в момент запуска. Он не знает бизнес-ценность страницы, не подтверждает ее наличие в индексе и не заменяет данные поисковых консолей, логов и аналитики.
Установка и выбор режима
Скачивайте программу с официального сайта разработчика и проверяйте системные требования для своей ОС. Перед большим обходом убедитесь, что на диске достаточно места, а лимиты памяти и хранения соответствуют размеру проекта.
В режиме Spider вводят стартовый адрес и переходят по найденным ссылкам. В режиме List загружают заранее подготовленный список URL — например, адреса из Sitemap, выгрузки CMS или карты миграции.
Что настроить до запуска
Укажите нужный поддомен и протокол, правила перехода во внешние домены, обработку параметров, ограничения скорости и типы ресурсов. Не начинайте объемный обход с максимальной частотой: чрезмерная нагрузка может повлиять на сервер.
Проверьте user-agent, robots.txt и авторизацию. Если задача — увидеть сайт так, как его получает поисковый робот, настройки должны это отражать. Для закрытого тестового стенда используют разрешенные учетные данные.
Обычный HTML и рендеринг JavaScript
Стандартный обход анализирует полученный HTML и подходит большинству серверных страниц. Если важный контент и ссылки появляются только после выполнения JavaScript, включают JavaScript rendering и сравнивают результат.
Рендеринг требует больше времени и ресурсов. Его включают по задаче, а не по привычке: сначала выясняют, чего нет в исходном HTML и зависит ли обнаружение URL от клиентского кода.
Разбор результатов обхода
Следующий связанный шаг: Аналитика страниц. Построение сегментов. Для материала «Screaming Frog SEO Spider: как провести технический аудит сайта» эта ссылка продолжает соседнюю задачу без повторения текущего раздела.
Коды ответа и редиректы
Начните с вкладки Response Codes. Ошибки 4xx требуют проверки источника ссылки и назначения URL; 5xx могут указывать на сбой сервера. Для 3xx проверьте, действительно ли перенос нужен и ведет ли он сразу к конечной странице.
Цепочки расходуют лишние запросы и замедляют переход. Цикл делает ресурс недоступным. При массовой проблеме исправляют шаблон или правило маршрутизации, а не каждую строку отчета вручную.
Indexability, robots и canonical
Разделяйте доступность для обхода и возможность индексирования. URL может отвечать 200, но иметь noindex; страница может быть закрыта robots.txt, поэтому робот не увидит ее содержимое.
Canonical — сигнал о предпочтительной версии среди дублей, а не команда удалить URL. Проверяйте абсолютный адрес, ответ 200, индексируемость цели и согласованность с внутренними ссылками и Sitemap.
Title, Description, H1 и содержимое
Фильтры помогают найти отсутствующие, повторяющиеся или чрезмерно шаблонные элементы. Длина сама по себе не определяет качество: важнее точность, уникальность и соответствие содержанию страницы.
Дубли допустимы в отдельных технических сценариях, но массовое совпадение у индексируемых карточек или категорий часто говорит о слабом шаблоне либо одинаковых страницах.
Внутренние ссылки и глубина
Inlinks показывают, откуда ведут ссылки на URL, Outlinks — куда он ссылается. Низкое число входящих ссылок и большая глубина помогают обнаружить сиротские или плохо встроенные страницы, но вывод проверяют по навигации и Sitemap.
Анкор должен объяснять назначение перехода. Если важная страница доступна только через поиск на сайте, форму или JavaScript-событие без обычной ссылки, краулер может ее не найти.
Изображения и ресурсы
Проверьте битые изображения, большой размер файлов, отсутствие alt у содержательных иллюстраций и загрузку ресурсов с ошибками. Alt описывает функцию или содержание, а декоративным изображениям обычно нужен пустой alt.
Вес изображения оценивают вместе с форматом, реальным размером отображения и загрузкой. Один универсальный порог не заменяет измерение производительности страницы.
Сопоставление с Sitemap и аналитикой
Сравните обход с XML Sitemap: индексируемые важные URL должны быть в карте, а редиректы, ошибки и noindex — обычно нет. Несовпадение помогает найти адреса, которые существуют только в одном источнике.
Подключения к Search Console и аналитике дополняют техническую таблицу показами и посещениями. Доступы выдавайте по принципу минимально необходимых прав и не публикуйте выгрузки с конфиденциальными данными.
Отчет, расширенные задачи и контроль
Как построить отчет аудита
Сначала сгруппируйте проблемы по причине и шаблону, затем оцените масштаб, влияние и сложность исправления. В отчете укажите пример URL, правило обнаружения, ожидаемое состояние и способ повторной проверки.
Список из тысяч строк без приоритета не является аудитом. Один дефект шаблона может объяснять тысячи URL; исправление на уровне CMS ценнее ручной обработки каждой страницы.
Типичные ошибки
Не сканируйте только главную страницу и не считайте найденное полным списком сайта. Не трактуйте каждое предупреждение как критическую ошибку и не меняйте URL, canonical или robots.txt без понимания последствий.
Сохраняйте конфигурацию, дату и версию программы, чтобы повторный обход был сопоставим. После внедрения запускайте контрольный crawl на той же выборке.
Проверка сайта перед миграцией
Соберите старые URL в режиме List и загрузите предполагаемые назначения. Проверьте, что каждая важная страница получает один прямой постоянный редирект на близкий по смыслу адрес, а конечная страница отвечает 200 и допускает индексирование.
После запуска обойдите новый сайт в Spider mode и сравните Title, H1, canonical, robots, глубину и внутренние ссылки. Отдельно сохраните отсутствующие соответствия: именно они часто становятся массовыми 404 после переключения.
Пользовательский поиск и извлечение данных
Custom Search помогает найти шаблонные фрагменты, идентификаторы аналитики, устаревшие телефоны или признаки разметки. Custom Extraction извлекает элементы по CSSPath, XPath или регулярному выражению для последующего анализа.
Правило сначала тестируют на нескольких типах страниц. Пустое значение может означать отсутствие элемента, ошибочный селектор или контент, появляющийся только после рендеринга; эти причины нельзя смешивать.
Крупные сайты и хранение обхода
Для большого проекта уменьшите скорость, исключите заведомо ненужные области и выберите подходящее хранение. Деление по разделам упрощает повторную проверку, но итоговые выборки нужно свести, чтобы не потерять переходы между сегментами.
Следите за ответами сервера во время crawl. Рост 5xx или времени ответа — причина остановить задачу и согласовать окно с разработчиками, а не продолжать ради полного отчета.
Пошаговый технический аудит в Screaming Frog
Работайте не по принципу «выгрузить все ошибки», а по заранее определенному сценарию. Ниже — минимальный порядок, который позволяет воспроизвести аудит и проверить исправления.
Порядок действий
- Сохраните контрольный список URL из XML Sitemap, поисковых консолей, аналитики и базы CMS. Он понадобится, чтобы найти страницы, до которых краулер не дошел по внутренним ссылкам.
- Создайте отдельную конфигурацию проекта. Зафиксируйте стартовый URL, user-agent, учет robots.txt, область поддоменов, ограничения параметров, скорость обхода и режим HTML или JavaScript.
- Запустите небольшой тест на одном разделе. Убедитесь, что программа не уходит в календарь, фасетные комбинации, бесконечную пагинацию и служебные параметры. Только после этого запускайте полный crawl.
- Сначала разберите Response Codes: 5xx, 4xx, циклы и цепочки редиректов. Для каждой группы откройте Inlinks и определите шаблон-источник, а не исправляйте URL по одному.
- Затем проверьте Indexability и Canonicals. Для каждого подозрительного URL сопоставьте код ответа, meta robots, X-Robots-Tag, canonical, наличие в Sitemap и внутренние ссылки.
- Проверьте Title, Description, H1, глубину и входящие ссылки только для индексируемых HTML-страниц. Иначе отчет будет заполнен техническими URL, от которых эти элементы не требуются.
- Экспортируйте не «все», а отдельные задачи: проблема, правило отбора, примеры, масштаб, ожидаемое состояние, владелец и способ повторной проверки.
- После релиза загрузите исходный crawl и новый обход в режим сравнения. Убедитесь, что дефект исчез, а количество индексируемых URL и внутренних ссылок не изменилось неожиданно.
Контрольный чек-лист
- Область обхода совпадает с задачей аудита
- Скорость согласована с владельцем инфраструктуры
- Параметры и ловушки обхода исключены
- JavaScript-режим включен только при подтвержденной необходимости
- Для ошибок проверены Inlinks и шаблон-источник
- Canonical ведет на доступный индексируемый URL
- В Sitemap нет 3xx, 4xx, 5xx и noindex
- Каждая задача содержит примеры и критерий приемки
- Конфигурация и дата обхода сохранены
- После внедрения выполнен сопоставимый повторный crawl
Таблица решений
| Сигнал в отчете | Что проверить | Действие |
|---|---|---|
| 404 с Inlinks | Нужна ли страница и откуда ведут ссылки | Исправить ссылку или вернуть релевантную страницу |
| Redirect chain | Все переходы и конечный код | Ссылаться сразу на финальный URL |
| Canonical non-indexable | Код, robots и canonical цели | Назначить доступную каноническую версию |
| Indexable URL not in Sitemap | Ценность и шаблон страницы | Добавить в карту либо обосновать исключение |
Частые вопросы
Можно ли проверить сайт бесплатно? У программы есть бесплатный режим с ограничениями; актуальный состав и лимиты проверяйте на странице лицензий разработчика.
Почему краулер не нашел страницу? На нее может не быть доступной ссылки, она закрыта правилами, требует авторизации или появляется только после сценария, который обход не выполняет.
Можно ли исправлять сайт прямо из Screaming Frog? Нет: программа диагностирует и экспортирует данные, а изменения вносят в CMS, код или серверную конфигурацию.
Семь QA-проверок обхода в Screaming Frog
Для темы «Screaming Frog SEO Spider: как провести технический аудит сайта» график становится основанием для действия только после QA области, периода, сегмента и источника. Допуск задаётся владельцем данных по фактической системе; универсальная цифра здесь создала бы ложную точность.
| Проверка | Эталон | Причина расхождения | Действие |
|---|---|---|---|
| Область обхода | Разрешённые хосты и папки заданы | Краулер ушёл на служебные домены | Ограничить scope и повторить |
| User-Agent | Режим соответствует вопросу проверки | Поведение сервера различается | Сравнить штатный и поисковый агент |
| Рендеринг | JavaScript включён только когда нужен | HTML-обход принят за полный DOM | Сделать отдельный JS-crawl выборки |
| Лимиты | Паузы и ресурсы безопасны для сайта | Обход перегружает staging/production | Согласовать скорость и окно |
| Indexability | Robots, meta, headers и canonical читаются вместе | Один фильтр заменяет диагноз | Проверить конфликтующие сигналы |
| Sitemap/аналитика | Импорты имеют тот же формат URL | Протоколы и параметры не совпадают | Нормализовать до сопоставления |
| Экспорт | Фильтры и конфигурация сохранены | CSV нельзя воспроизвести | Приложить конфиг и дату обхода |
Почему одинаковый график требует разных решений: Screaming Frog SEO Spider: как провести технический аудит сайта
Рост числа неиндексируемых URL может быть реальной регрессией, изменением scope или результатом подключения JavaScript-рендеринга. Сначала повторяют контрольный набор с сохранённой конфигурацией, затем открывают HTML конкретных примеров.
Приёмка данных: Screaming Frog SEO Spider: как провести технический аудит сайта
- Сохранены точный ресурс, период, сегмент, фильтры и дата выгрузки. Для темы «Screaming Frog SEO Spider: как провести технический аудит сайта» критерий проверяется в описанном контексте.
- Метрика имеет формулу, источник, гранулярность и владельца. Для темы «Screaming Frog SEO Spider: как провести технический аудит сайта» критерий проверяется в описанном контексте.
- Сбой сбора отделён от изменения поискового или бизнес-результата. Для темы «Screaming Frog SEO Spider: как провести технический аудит сайта» критерий проверяется в описанном контексте.
- Пример диагноза можно воспроизвести без доступа к вымышленным данным. Для темы «Screaming Frog SEO Spider: как провести технический аудит сайта» критерий проверяется в описанном контексте.
Если контрольный срез не воспроизводится, вывод отменяют и сначала чинят данные. Решение по сайту не ставят по отчёту, которому команда не может объяснить происхождение. Для темы «Screaming Frog SEO Spider: как провести технический аудит сайта» критерий проверяется в описанном контексте.
Получите бесплатный аудит и стратегию роста
Изучим сайт, покажем точки роста и подготовим прогноз до квалифицированных лидов и оборота из SEO/GEO.