Навредит ли SEO индексируемый тестовый поддомен с дублями сайта?

Да, одинаковые страницы на site.ru и test.site.ru Google будет рассматривать как дублирующиеся или практически идентичные URL. Но сам факт попадания 1000 тестовых страниц в индекс не означает санкцию и не позволяет утверждать, что сайт потерял определённый процент позиций или трафика.

Google обычно объединяет одинаковые или очень похожие страницы в группу дублей и выбирает одну из них как каноническую. Дублирование само по себе обычно не является нарушением правил Google и не вызывает отдельного «штрафа за дубли».

Проблема в другом: пока test.site.ru был доступен с кодом 200 и разрешён для индексации, Google видел две версии одних и тех же документов и должен был самостоятельно определять, какую считать основной.

Насколько это могло навредить сайту

По числу «1000 страниц из 6000» оценить ущерб нельзя. Нужно смотреть, что Google сделал с конкретными парами URL.

Наиболее безопасный сценарий — Google определил страницы site.ru как канонические, а test.site.ru считал их дублями. Тогда существенного влияния на позиции могло вообще не быть.

Хуже, если для части страниц Google выбрал test.site.ru канонической версией. В таком случае соответствующий URL основного домена мог определяться как дубль, а в поиске могла показываться тестовая версия. После удаления поддомена Google потребуется заново обработать эти URL и вернуть основной домен в качестве канонического.

Риск был выше, если на test.site.ru:

• стояли canonical на URL самого test.site.ru;
• внутренние ссылки указывали на test.site.ru;
• существовал отдельный sitemap с тестовыми URL;
• на тестовый поддомен появились внешние ссылки;
• отсутствовали какие-либо сигналы, явно указывающие Google на site.ru как основную версию.

Если же вместе с копией HTML на тестовом поддомене сохранились canonical вида https://site.ru/..., это было дополнительным сигналом в пользу основного домена, хотя canonical для Google не является гарантированной директивой.

Отдельно раздувать проблему через crawl budget для сайта из 6000 страниц не стоит. Google рассматривает разные hostname отдельно при управлении сканированием: site.ru и test.site.ru — разные hostname. Поэтому нельзя просто сказать, что сканирование 1000 тестовых страниц «отняло» такой же объём обхода у основного домена. Для сайта такого размера crawl budget вообще редко является главным ограничением.

Что означает наличие test.site.ru в индексе после удаления поддомена

Если поддомен уже действительно перестал отдавать контент, наличие старых URL в Google не означает, что дублирование продолжается прямо сейчас. Индекс Google не обновляется одновременно с изменениями на сервере: старые URL могут оставаться в результатах до повторного обхода и обработки.

Нужно проверить, что реально происходит при запросе старого URL, например:

https://test.site.ru/category/page/

Принципиально важно отличать несколько ситуаций.

Если тестовая страница имеет точный аналог:

https://test.site.ru/category/page/ → https://site.ru/category/page/

лучший вариант — снова направить test.site.ru на сервер и настроить постоянный 301 или 308 редирект каждого тестового URL на соответствующий URL основного домена.

Это одновременно сообщает Google, что страница перемещена, и является сильным сигналом в пользу основного URL как канонического.

Не следует отправлять все 1000 URL редиректом на главную страницу. Редирект должен вести на соответствующий документ.

Если подходящего URL на основном сайте больше не существует, старый URL должен возвращать настоящий HTTP 404 или 410.

Если test.site.ru сейчас возвращает 200 с пустой страницей, заглушкой хостинга или сообщением «сайт удалён», ситуацию нужно исправить. Ответ 200 означает успешный URL и может замедлять его нормальное удаление из поиска.

Инструмент «Удаления» в Google Search Console можно использовать, если тестовые URL необходимо быстро скрыть из результатов. Но он предназначен для временного скрытия и не заменяет 301, 404, 410 или другой постоянный способ обработки URL.

Закрывать уже проиндексированный test.site.ru только через robots.txt для решения этой проблемы не нужно: robots.txt управляет сканированием и сам по себе не является надёжным способом удаления URL из индекса.

Как проверить реальный ущерб

В Search Console нужно проверить несколько страниц, которые существовали одновременно на обоих хостах.

Для URL основного сайта через проверку URL следует посмотреть:

• находится ли страница в индексе;
• какой URL указан как выбранная Google каноническая страница;
• не получила ли страница статус дубля;
• присутствует ли основной URL в результатах поиска.

Если для нормальных страниц site.ru Google выбирает site.ru канонической версией, а тестовые URL постепенно исчезают, оснований считать инцидент серьёзным нет.

Если же Google выбрал test.site.ru каноническим для заметной части страниц и одновременно основные URL выпали из индекса или потеряли видимость, влияние было реальным. Тогда приоритетная задача — восстановить test.site.ru только для корректных постраничных 301-редиректов на site.ru и устранить любые оставшиеся ссылки, sitemap и canonical, ведущие на тестовый hostname.

На будущее тестовую среду лучше вообще не делать публично доступной поисковым роботам. Надёжнее закрывать staging авторизацией или паролем, а не рассчитывать только на robots.txt или последующее удаление URL из индекса.