Страница открывается в браузере, но её таблица стилей и основной bundle закрыты для робота. Для статического текста это одна ситуация, для каталога, где карточки появляются после API-запроса, — другая. Сначала определите, какие ресурсы действительно нужны для понимания страницы.
Какие ресурсы влияют на понимание страницы
Оценивайте влияние недоступного ресурса на основной текст, ссылки и отображение. Не нужно разрешать весь служебный каталог ради одного файла; значимые CSS и JavaScript выделяйте по реальным запросам страницы.
Google предупреждает, что блокировка необходимых ресурсов мешает понимать зависящие от них страницы. Официальная документация.
Ресурс style.css может отвечать только за цвет кнопки, а app.js — за появление всего каталога. Их недоступность имеет разный эффект. Начните с определения основного содержимого: название услуги, описание, товары и навигационные ссылки. Отметьте, какие элементы уже есть в серверном HTML и какие создаются позже. Сайт с полной серверной карточкой и небольшим интерактивным виджетом не нужно оценивать так же, как пустую оболочку, ожидающую bundle. Проверка влияния важнее механической рекомендации открыть каждую папку assets.
Соберите реальные запросы вместо списка расширений
Учебные сценарии в таблице задают ожидаемое поведение; фактические ответы своего сайта заносите отдельно.
| Сценарий | Отличие | Решение | Проверка |
|---|---|---|---|
| /assets/app.js | Рисует каталог | Проверить правило | Разрешить нужный bundle |
| /assets/style.css | Задаёт отображение | Сравнить рендер | Разрешить нужные стили |
| CDN другого хоста | Свой robots.txt | Проверить отдельно | Не переносить правило домена |
| /internal/ | Служебный раздел | Оценить назначение | Не открывать всё |
В Network сохраните запрос документа, CSS, JavaScript и запросы данных, которые понадобились основному содержимому. Не путайте неиспользуемый аналитический скрипт с обязательным кодом каталога. Для каждого ресурса запишите полный хост и путь, статус и назначение. Если данные приходят с API, проверьте его доступность отдельно; разрешённый app.js не поможет, когда нужный endpoint отвечает ошибкой. Для изображений определите, влияют ли они на содержательный ответ страницы или только на оформление. Такой список делает изменение robots точным и объяснимым.
Сравните исходный HTML и содержимое после рендера
Соберите в Network адреса CSS, JS и необходимых запросов данных. Проверьте каждый путь по robots.txt соответствующего хоста, включая CDN. Сравните исходный HTML, обычный DOM и доступное представление отрендеренной страницы в поисковом инструменте.
Сохраните текст и ссылки из исходного HTML, затем сравните с готовым DOM. Отдельно посмотрите доступный результат рендера в поисковом инструменте. Важно видеть не только скриншот: карточки могут выглядеть нормально, но не содержать настоящих ссылок. Ошибка Console тоже может объяснять отсутствие содержимого независимо от robots. Если ресурс закрыт, проверьте, действительно ли нужная группа робота запрещает его путь. Нормальная загрузка в вашем браузере показывает работу сервера для пользователя, но браузер не применяет robots.txt как поисковый обходчик.
Учебный тест заблокированного bundle
Учебная категория сначала отдаёт заголовок, а карточки создаёт app.js. Заблокируйте этот ресурс только на тестовой среде и сравните текст и ссылки. Затем верните доступ и повторите тот же сценарий без изменения данных каталога.
На тестовой копии выберите страницу, у которой bundle создаёт карточки. Заблокируйте только этот файл средствами диагностического браузера и сравните результат. Затем восстановите загрузку, не меняя данные, и повторите. Такой опыт показывает зависимость содержимого от ресурса, но не моделирует всю поисковую обработку. После этого проверяйте настоящие robots-правила и серверный доступ. Если отсутствие bundle не меняет основной текст, запишите это наблюдение; не называйте автоматически любую блокировку JavaScript критической потерей содержимого.
Разрешите нужный путь и сохраните служебные ограничения
Измените правила для необходимых ресурсов, сохранив ограничения ненужных служебных путей. Проверьте новый build: хешированные имена bundle могут поменяться, поэтому правило на один старый файл недостаточно.
Если /assets/ закрыт широким правилом, уточните, какие его пути нужны. Можно изменить структуру или ограничения так, чтобы необходимые общие ресурсы были доступны, а служебные файлы сохраняли предусмотренный доступ. Перед правкой проверьте вложенные архивы, исходные карты и конфигурационные файлы: SEO-разрешение не должно превращаться в публикацию приватной информации. Вопрос безопасности решается реальным доступом сервера. Robots лишь сообщает добровольно соблюдающим его обходчикам политику загрузки и не заменяет проверку того, что сервер вообще отдаёт публично.
Проверьте CDN и новое имя сборки
Браузер владельца не соблюдает robots.txt как поисковый робот. Успешная загрузка CSS на вашем компьютере не подтверждает разрешение ресурса для Googlebot.
У CDN-хоста свой robots.txt и собственные ответы. Правило основного домена не управляет автоматически cdn.example.com. После новой сборки имя app.abc.js может стать app.def.js; разрешение только старого файла перестанет помогать. Проверьте правило на предусмотренный стабильный путь, затем фактические имена актуальных ресурсов. Убедитесь, что переход на CDN не создал mixed content или не потребовал авторизацию. Приёмка новой сборки должна включать получение именно её bundle, а не файла, который остался в кеше предыдущего релиза.
Приёмка основного текста, ссылок и отображения
Завершайте проверку после того, как основной текст и переходы действительно доступны в предусмотренном рендере. Для каталога проверьте число и назначение контрольных карточек, для услуги — описание и контактный переход. Сохраните список ресурсов и влияние каждого заблокированного пути. Если часть поискового инструмента недоступна, отметьте границу: серверный доступ, robots и обычный браузер проверены, поисковый рендер — нет. Это точнее, чем объявлять страницу полностью исправной на основании одного разрешённого CSS. Повторная проверка нужна после изменения сборки или правил ресурсов.
Критерии завершения проверки
Ресурсы, необходимые основному содержимому, разрешены и отвечают успешно. Текст и навигация видны в проверенном рендере; приватные служебные данные не стали публичными после ослабления правила.
- /assets/app.js: Разрешить нужный bundle. Зафиксируйте фактический результат и адрес проверенного сценария.
- /assets/style.css: Разрешить нужные стили. Зафиксируйте фактический результат и адрес проверенного сценария.
- CDN другого хоста: Не переносить правило домена. Зафиксируйте фактический результат и адрес проверенного сценария.
- /internal/: Не открывать всё. Зафиксируйте фактический результат и адрес проверенного сценария.
Для смежных вопросов: SSR vs CSR vs SSG для SEO: что выбрать в 2026 году и Robots.txt: полное руководство по настройке для SEO и веб-разработки. Отдельные проверки сайта собраны на странице технического аудита reChecker.