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

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

Когда GSC помечает урл как заблокированный в robots.txt, хотя ни в текущем файле, ни в предыдущей версии нет подходящего правила — это выглядит как баг репортинга.

Тест Rich Results на тот же урл показывает отсутствие блокировки и только подкрепляет эту версию.

Блокировка сидела на одно звено выше.

Забракованный урл — страница подписки на рассылку с параметрами кампании — редиректил через путь /sso/, который закрыт в robots.txt.

Более чистый вариант с одним слешем и теми же параметрами получил аналогичный вердикт.

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

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

Джон Мюллер подтверждает этот вывод и называет команду для проверки: curl -LI (URLHERE) проходит по всей цепочке и раскрывает каждое звено, которое вердикт GSC сворачивает в одну строчку.

Если есть подозрение на клоакинг, повторный фетч с фейковым юзер-агентом Гуглобота отделяет реальную блокировку от подмены контента; на этом урле сама цепочка дала исчерпывающий ответ.

GSC не показывает промежуточные звенья редиректов.

В итоге блокировка на любом участке цепочки всплывает как обвинение в адрес входного урла.

Вердикт "blocked by robots.txt" на урле без подходящих правил — это повод идти аудитить цепочку редиректов, а не строчить баг-репорт.

Инсайты комьюнити

— На том же сайте заметили: добавленный в .htaccess тег noindex, nofollow работает как второй слой подавления, который нужно аудитить отдельно от цепочки редиректов.

@MikeBlazerX

📈 "Пушки" — в @MikeBlazerPRO