Стейдж и прод: где искать битые ссылки

Тестовый стенд (стейдж) нужен, чтобы не выкатить белый экран на боевой сайт. Как единственный источник правды о битых ссылках он слаб: хосты разные (staging.example.com и www.example.com), абсолютные href в CMS могут смотреть на production, пока вы сидите на стейдже, или наоборот. robots.txt на стейдже иногда отдаёт 403 краулеру. HTTP-авторизация останавливает расширение так же, как и Googlebot без доступа.

Если сканировать только стейдж, легко пропустить ассеты боевого сайта: живой CDN, контейнер тег-менеджера, «настоящий» PDF в подвале, который на превью лежит по другому пути.

Разделение по этапу

• До релиза: стейдж, чтобы ловить баги шаблона и относительные ссылки. Учтите, что пароль, noindex и другой домен прячут часть поломок, которые проявятся на публичном сайте.
• В день релиза: боевой сайт (production). Этот проход совпадает с тем, что увидит Search Console. См. после редизайна.
• Preview-домены (Webflow, Vercel, Netlify): это стейдж. Кастомный домен сканируйте отдельно. Заметки по Webflow.

Как проверять в Chrome

Откройте тот хост, который хотите оценить. Если Chrome его показывает, расширение его просканирует. Адреса chrome:// и страница магазина расширений недоступны для скана. При basic auth сначала войдите во вкладке, затем запустите проверку.

Нужно сравнить стейдж и прод: сделайте два CSV и сверьте списки 404. Списки редко совпадают один в один.

Пользователь не ходит на ваш preview. Его имеет смысл сканировать для QA, но последним аргументом остаётся URL, который открывает клиент на боевом домене.