17 сентября 2026 года в r/bigseo появился пост владельца сайта о компаниях и поставщиках: страницы начали постепенно выпадать из индекса Google, а каноническим для них Google считал страницу казино на постороннем домене. Никакого сходства в контенте не было, и найти на том домене что-то похожее тоже не удавалось. 18 сентября вышла новость в Search Engine Journal с ответом John Mueller, а 21 сентября вторичный разбор от Search Engine Watch. Ниже — про механизм, который здесь действительно документирован, и про то, что имеет смысл проверять на своём сайте.
Что произошло и что ответил Mueller
Другой участник того же обсуждения описал похожую ситуацию у себя: при поиске чужого URL, который Google выбрал каноническим, в выдаче показывался заголовок «Application error: a client-side exception has occurred (see the browser console for more information)» — типовая ошибка JavaScript-приложения. Ту же ошибку время от времени показывал и его собственный сайт во время коротких сбоев. Отсюда версия: Googlebot в какой-то момент получил страницу ошибки вместо контента и счёл несколько URL с одинаковой «оболочкой ошибки» дублями.
Mueller согласился, что это возможное объяснение, и дал важную формулировку. По его словам, вариантов развития всего три:
1. канонической считается ваша страница, но она проиндексирована с сообщением об ошибке — нормального контента в выдаче нет;
2. страница распознана как soft 404 — нормального контента в выдаче нет;
3. канонической считается чужая страница — нормального контента в выдаче нет.
Дальше он добавляет, что при любом из трёх сценариев для сайта результат один и тот же, так что выяснять, какой именно случился, не так уж важно. Важно ловить такую ошибку на своей стороне до того, как сайт уйдёт в прод. Среди собственных практик он называет прогон большого числа автоматических тестов перед публикацией — и добавление нового теста каждый раз, когда что-то ломается, — а также регулярную проверку критичных страниц («раз в час или как получится»), чтобы починить проблему раньше, чем её устойчиво подхватят поисковые системы.
Канонический URL — это рекомендация, а не команда
Канонический URL — это адрес, который Google выбирает представителем группы одинаковых страниц. Свой вариант можно предложить через rel="canonical", но Google вправе выбрать другой URL — он может сделать это и вообще без вашего указания. Поэтому «мы же прописали каноникал» не является защитой: в документации отдельно сказано, что при выборе учитываются и качество контента, и технические сигналы.
Механизм, который Google описал заранее
Самое интересное в этой истории — что сценарий с чужим доменом не является чем-то необъяснимым. В разделе про исправление проблем канонизации у Google есть таблица типичных причин, и в ней прямо сказано: два несвязанных веб-сервера могут возвращать идентичные soft 404 страницы, которые Google не распознаёт как страницы ошибок. Рекомендация в этом случае — обращаться к своему хостинг-провайдеру.
Логика простая. Если у двух разных сайтов приложение падает с одним и тем же текстом ошибки и этот текст подменяет собой основной контент, то страницы, которые получает Google, выглядят одинаково — хотя их предполагаемое содержимое не имеет ничего общего. Google не видит там ошибку, он видит дубликаты и выбирает одного представителя группы. Каким он окажется, предсказать нельзя.
В той же таблице перечислены и другие причины неожиданного выбора канонического URL: некорректные канонические элементы (типичная проблема CMS и плагинов), вредоносный код с редиректом или вставленным кросс-доменным rel="canonical", ошибки хостинга, а также сайт-копия. Это важно для диагностики: обнаружение чужого домена в отчёте — повод для проверки, но само по себе оно не говорит, какая именно причина сработала.
Про soft 404 и «успешный» ответ 200
Отдельный слой проблемы — soft 404: страница отдаёт успешный HTTP-код, но её содержимое указывает на ошибку или фактически пустое. В документации по ошибкам сканирования Google среди причин называет страницы, которые не загрузились корректно: страница ссылается на множество ресурсов, которые не удалось загрузить (картинки, скрипты и другие нетекстовые элементы), слишком много ресурсов на странице, серверные ошибки, медленная загрузка или очень большие ресурсы.
С этим связан практический вывод, который легко пропустить: приложение на клиентском JavaScript часто отдаёт 200, показывая при этом страницу ошибки. Это описано в руководстве по JavaScript — там прямо сказано, что такая практика ведёт к индексации страниц ошибок и их возможному появлению в выдаче.
Отсюда следствие про мониторинг: проверка только кода ответа даёт ложное спокойствие. Если ваш аптайм-монитор проверяет, что страница вернула 200, он может рапортовать об успехе, пока статьи на странице нет.
Как проверить ситуацию на своём сайте
Порядок важен, и его стоит соблюдать буквально. Сначала откройте в Search Console результат индексирования URL Inspection для подозрительной страницы и посмотрите: время последнего сканирования, ваш канонический URL и канонический URL, выбранный Google. Именно здесь видно выбор Google — в справке Search Console сказано, что определить каноническую версию можно только по проиндексированным данным, а live-тест не может предсказать, будет ли протестированная версия считаться канонической.
Только после этого запускайте Test live URL и через «View tested page» проверяйте скриншот и HTML: есть ли там ожидаемый заголовок и текст. Успешный тест сегодня не отменяет того, что при более раннем сканировании страница могла быть ошибочной.
И отдельно про сроки: Google предупреждает, что даже после исправления контента страницы могут оставаться в кластере дубликатов до двух недель. Это про переоценку группировки, а не про сроки возврата позиций. Заодно документация советует запрашивать переобход для важных URL — не для всего подряд, потому что у этой функции есть квоты.
Что делать до и после релиза
Здесь колонка Search Engine Watch и ответ Mueller сходятся в одном: лечить надо причину, а не тег. Правка канонического тега не вернёт текст, который приложение не отобразило. Если в отрендеренной странице только ошибка, нужно устранять сбой — независимо от того, какой URL выбрал Google.
Практический минимум, который из этого следует:
- Тест на рендеринг, а не на код ответа. Перед выкладкой загружать типовую статью или карточку и проверять, что после рендеринга на месте ожидаемый заголовок и основной текст.
- Автотесты перед публикацией. Подход Mueller: прогонять набор тестов до релиза и добавлять новый тест на каждый сбой — так ошибка не возвращается.
- Регулярные проверки после релиза. Опрашивать критичные страницы по расписанию и проверять содержимое, а не только статус.
- Сохранять сбой. Снимок ошибочной страницы и её время полезны, чтобы сопоставить их с логами приложения и временем сканирования из Search Console.
Чего в этой истории нет
Честные оговорки, без которых материал был бы неполным. Причина конкретного случая не подтверждена: это версия, которую Mueller счёл возможной, а не официальное объявление Google. Ответ Mueller был дан в Reddit, а публикации — это журналистский разбор, а не новая документация.
Есть и содержательная тонкость. Классический кросс-доменный каноникал работает так: тег стоит на вашем сайте и указывает на другой домен. Если у вас такого тега нет, это означает либо взлом, либо следы синдикации контента, — а не «Google что-то перепутал у себя». Search Engine Journal в этом же разборе отдельно замечает, что путать корреляцию с причиной здесь легко: сайт мог лишиться позиций по другой причине, а чужой домен в отчёте оказаться совпадением.
Мы в Adviko делаем технический аудит, и этот сюжет — ровно из нашей практики: сайты уходят в прод с ошибками рендеринга, которые не видит ни один статус-код. Если у вас сайт на JavaScript-фреймворке, интернет-магазин с большим каталогом или просто нет регулярной проверки содержимого критичных страниц — напишите нам, посмотрим, что получает поиск на ваших URLs. По теме: 10 ошибок технического SEO-аудита и в чём техническая сторона SEO сложнее «косметического ремонта» сайта.
_Источник: Google says page errors could explain cross-domain canonical mix-up — Search Engine Watch, Martin Ashmere, 21 сентября 2026. Первичные материалы: обсуждение в r/bigseo (ответ Mueller) и разбор Search Engine Journal — Roger Montti, 18 сентября 2026. Документация Google: исправление проблем канонизации, ошибки сканирования, проблемы JavaScript, URL Inspection._
