Типичная история сайта агентства, переведённого на семь языков, выглядит так: на основном языке он как-то работает, на английском — еле-еле, на остальных пяти — почти никак. Команда сначала винит контент, переделывает перевод, добавляет пару статей. Цифры не двигаются. Потому что проблема чаще всего не в тексте, который вы написали, а в том, со скольких разных адресов, с каким кодом состояния и с какой языковой меткой этот текст отдаётся поисковой системе.
Эта статья превращает в руководство результаты сквозного технического аудита, который мы провели на семиязычном сайте туристического ПО. Все цифры взяты либо из этого аудита, либо из внешних исследований с указанным источником; ни одна не является предположением. Аудит охватил 1088 живых страниц, 1469 адресов в карте сайта и все семь языков, и картина оказалась такой: у 85% страниц не было тега канонического адреса вообще, сайт полностью дублировался на двух разных хостах, а объявленные переводы на шести языках на самом деле возвращали сообщение «страница не найдена».
Каждый раздел ниже даёт проверку, порог или правило принятия решения, которое вы можете применить на собственном сайте с помощью браузера и curl, даже если не купите ни одной программы. Порядок тоже важен: без технической уборки не работает глубина контента, без глубины контента не работает видимость в ИИ-поиске.
Порядок аудита: сначала единый источник истины (канонический адрес, взаимный hreflang, честный код состояния), затем контент и только в конце — видимость в ИИ-поиске.
1. Сначала посчитайте: со скольких адресов открывается одна и та же страница?
Начинайте аудит не с контента, а с подсчёта адресов. Измерить, со скольких разных адресов открывается страница, занимает десять минут — и обычно уже в первом заходе вскрывает самую крупную потерю.
На измеренном сайте было две базовых поломки. Первая: домен с www и без www оба отдавали 200, то есть весь сайт был доступен дважды. Вторая: старые и новые имена путей были оставлены открытыми одновременно, поэтому /ru/portfolio и /ru/nashi-raboty отдавали одно и то же содержимое; один этот шаблон порождал примерно 1713 теневых адресов.
Запросите на своём сайте следующие пять вариантов по очереди и запишите возвращаемый код состояния:
| Вариант | Пример | Ожидаемый результат |
|---|---|---|
| Хост без www | primer.com/ru/blog |
301 → вариант с www |
| Хост с www | www.primer.com/ru/blog |
200 |
| Слеш в конце | www.primer.com/ru/blog/ |
301 → вариант без слеша |
| Параметр отслеживания | www.primer.com/ru/blog?utm=x |
200 + canonical без параметра |
| Старое имя пути | www.primer.com/ru/stati |
301 → новый путь |
В командной строке это можно посмотреть одной строкой:
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -I <адрес>
Если 200 отдают два варианта из пяти или больше, поисковая система видит не одну вашу страницу, а несколько страниц, копирующих друг друга. Это вопрос не санкций, а расщепления сигнала. Ссылки, клики и краулинговый бюджет, приходящиеся на одно и то же содержимое, распределяются между несколькими адресами.
Если все пять вариантов отдают 200, сигнал делится на пять. Порядок решения: старые пути объединяются через 301, остальные собираются самоссылающимся тегом canonical.
Правило решения
Определите для страницы ровно одну каноническую форму и зафиксируйте на ней три вещи: хост (с www или без — одно из двух), политику завершающего слеша (всегда есть или никогда нет) и регистр букв. Пока эти три решения не записаны, каждый новый шаблон страницы будет порождать свой вариант.
2. Canonical — не приказ, а сигнал
Самая показательная цифра аудита была именно здесь: из 1088 страниц, отдающих 200, у 921 (85%) тега canonical не было вообще. А из 167 страниц с тегом у 60 тег не указывал на себя — страница отдавалась по адресу www.primer.com/ru, а в canonical было написано https://primer.com/ru/. То есть не совпадали ни хост, ни слеш.
В этом месте нужно знать два технических факта. Собственная документация Google определяет тег rel="canonical" не как директиву, а как «сильный сигнал того, что указанный адрес должен быть каноническим»; окончательное решение принимает поисковая система. Та же документация выстраивает методы канонизации от сильного к слабому: редирект > тег canonical > присутствие в карте сайта. Карта сайта прямо называется «слабым сигналом».
Практический вывод такой: тег canonical сам по себе не инструмент уборки. Если вы хотите закрыть старый адрес, используйте редирект; canonical оставьте только для тех вариантов, которые нельзя перенаправить (адреса с параметрами, комбинации фильтров).
Второй факт: Google рекомендует, чтобы каноническая страница несла самоссылающийся canonical. То есть предположение «canonical пишется только на страницах-копиях» неверно; основная страница тоже должна указывать на себя.
Почему написанный вручную canonical неизбежно ломается
На проверенном сайте canonical был написан вручную в десяти разных шаблонах страниц: в одном — со слешем, в другом — без www, в третьем — с уже несуществующим фрагментом пути. Ещё в четырнадцати шаблонах его не было вообще. Это не невнимательность, а структурное следствие: если каждый, кто пишет новый шаблон страницы, обязан заново вспомнить правило, правило рано или поздно забудут.
Применимое правило: тройка canonical, hreflang и og:url должна формироваться не в шаблонах страниц, а в одном общем месте и выводиться ровно один раз на страницу. Если страница пытается написать собственный canonical, процесс публикации должен это запретить. В структуре, выстроенной после аудита, это правило было привязано к проверке на этапе сборки; оно обеспечено «конструкцией», а не «дисциплиной».
3. hreflang: цена объявления языка, у которого нет перевода
Самая дорогая ошибка многоязычных сайтов находится здесь. На проверенном сайте одна русскоязычная запись блога объявляла в качестве английского соответствия некий адрес. Этот адрес отдавал HTTP 200 — но в теле страницы было написано «Blog Post Not Found». Тот же шаблон повторялся на шести языках. То есть сайт собственными руками сообщал поисковой системе о сотнях пустых страниц.
Документация Google по международным версиям высказывается однозначно: «Если страница X ссылается на страницу Y, страница Y должна ссылаться обратно на X. Если это не так для всех страниц, использующих hreflang, эти аннотации могут быть проигнорированы или интерпретированы неверно.» Тот же документ формулирует и более жёсткую фразу: «Если две страницы не указывают друг на друга, теги игнорируются.»
Отсюда следуют три правила:
| Ситуация | Верное поведение | Неверное поведение |
|---|---|---|
| Перевод есть, опубликован | Написать взаимный hreflang | Одностороннее объявление |
| Перевода нет | Не писать hreflang вообще | Написать тот же slug и для этого языка |
| Перевод есть, черновик | Не писать до публикации | Написать «всё равно скоро выйдет» |
Слева: язык, объявленный односторонне, указывает на адрес, который отдаёт 200, но не содержит контента. Справа: взаимно объявляются только языки с реальным переводом, строка для немецкого не пишется вовсе.
Внимания требуют и две другие частые ошибки, которые перечисляет Google: выход кодов языка за пределы ISO 639-1 и использование в качестве кода региона неофициальных значений вроде EU, UK, UN. Код региона должен соответствовать ISO 3166-1 Alpha 2, и указывать регион отдельно нельзя — пишут не hreflang="RU", а hreflang="ru" или hreflang="ru-RU".
x-default же задаёт запасной адрес для пользователей, для которых язык выбрать не удалось. На многоязычном сайте агентства самый разумный выбор — главная страница языка, на котором ведутся международные продажи (чаще всего английского), либо экран выбора языка, если он есть.
4. Soft 404: написать «не найдено» и вернуть 200
Soft 404 — это, по определению Google, ситуация, когда содержимое представляет собой сообщение об ошибке или пустую страницу, а сервер при этом возвращает код успеха 2xx. Это самая труднообнаружимая поломка, потому что ни один инструмент мониторинга не поднимает тревогу: страница выглядит «работающей», а люди по этому адресу и так не ходят.
На проверенном сайте несуществующее содержимое отдавало 200 + «не найдено». Когда мы перевели это на честный 404, одновременно стали видны три поломки, до того полностью скрытые:
| Проявившаяся поломка | Затронутые адреса |
|---|---|
| Процентно-кодированные пути вообще не разбирались | 23 |
| Категорийные страницы без соответствия в карте сайта | 33 |
| Слаги в базе не совпадали с описанием продукта | 10 |
Самый драматичный результат был таким: арабские страницы продуктов с момента публикации не работали ни для одного реального клиента. При запросе в сыром UTF-8 они отдавали 200, а в процентно-кодированном виде, который браузер реально отправляет, — 404. Из-за soft 404 этого никто не заметил; команда считала, что арабские страницы «в эфире».
Правило решения
Не бойтесь переходить на честный 404. В короткой перспективе число ошибок вырастет — это не ухудшение, а выпрямление измерения. Для адресов, которые уже не вернутся навсегда, ещё точнее 410; но какой адрес не вернётся — это решение по контенту, сначала примите его.
5. URL на нелатинском алфавите: ловушка процентного кодирования
Пути, содержащие арабские, русские или турецкие символы, отправляются браузером в процентно-кодированном виде. Документация Google по структуре адресов прямо это рекомендует: «Символы вне диапазона ASCII должны быть закодированы процентами.» Тот же документ поддерживает и использование в адресе слов на языке целевой аудитории (а при необходимости — их транслитерации).
Проблема в том, что если серверная сторона это кодирование не разбирает, весь язык тихо умирает. Для собственной проверки запросите один и тот же адрес в двух формах:
- Сырой вид:
/ru/blog/<русский-слаг> - Процентно-кодированный вид:
/ru/blog/%D1%80%D1%83...
Если они отдают разные коды состояния, у вас поломка. Языков для проверки немного, но эффект охватывает целый рынок.
Применимая политика: для языков с нелатинским алфавитом осознанно выберите один из трёх вариантов и последовательно примените его во всех семи языках — (а) собственный алфавит целевого языка (если подтверждено, что процентное кодирование работает), (б) транслитерация (для русского — вроде budushcheye-...), (в) английский slug + языковой суффикс. Неверного варианта нет; неверно — вести себя по-разному от языка к языку.
Кроме того, Google рекомендует в качестве разделителя слов дефис, а не подчёркивание: «Мы рекомендуем использовать в адресах дефис (-) вместо подчёркивания (_) для разделения слов.» Обоснование в том, что подчёркивание в программировании используется для обозначения связанных между собой понятий.
6. Карта сайта — не список, а обязательство
Каждым адресом, который вы кладёте в карту сайта, вы утверждаете: «это настоящая страница, заслуживающая индексации». На проверенном сайте карта объявляла 1469 адресов; после уборки их стало 1386. Отсеяны были следующие:
- 28 адресов отдавали не HTML, а сырые данные (JSON) — конец программного интерфейса был объявлен как страница.
- 21 адрес вообще не отрисовывался.
- 33 адреса были категорийными страницами без соответствия; их тела состояли из 21–25 слов, и все они выводили один и тот же шаблон «не удалось загрузить».
Кроме того, все 1469 адресов публиковались с неверным хостом (без www); то есть карта сайта объявляла список, противоречащий собственному каноническому решению сайта.
Вторая тихая ошибка была в поле lastmod: на каждый запрос оно выдавало значение «сегодня». Это полностью обессмысливает поле. lastmod должен питаться реальной датой последнего обновления содержимого; иначе краулер перестаёт принимать этот сигнал во внимание.
Чек-лист по карте сайта
- Совпадает ли хост в карте сайта в точности с каноническим хостом сайта?
- Запросите случайные 10 адресов — все ли отдают 200 и
Content-Type: text/html? - Применена ли политика завершающего слеша и в карте сайта?
- Отличаются ли значения
lastmodдруг от друга или все они относятся к одному дню? - Точно ли языки без перевода не попадают в карту сайта?
- Исключены ли из карты сайта страницы с
noindex?
7. Тихая ошибка robots.txt: правило групп
Это была одна из самых дешёвых и одновременно самых дорогих ошибок, найденных в аудите: в файле была строка Disallow, написанная правильно, но помещённая не в ту группу, из-за чего для Googlebot она была полностью бесполезна.
Причина — логика групп robots.txt, стандартизированная в RFC 9309. Стандарт говорит: краулер находит группу, соответствующую его продуктовому токену (product token), и подчиняется правилам этой группы. Группа-джокер * вступает в силу только если совпадающей группы нет. То есть:
Представьте такой файл:
| Группа | Правила внутри |
|---|---|
User-agent: Googlebot |
Disallow: /poisk |
User-agent: * |
Disallow: /poisk и Disallow: /korzina |
В этом файле Googlebot может сканировать путь /korzina, потому что в его собственной группе такой строки нет, а объединения с группой-джокером не происходит. Правило простое: если вы хотите, чтобы правило действовало, повторите его отдельно в каждой группе User-agent.
Вместо ручной проверки скопируйте свой файл и протестируйте целевой путь в отчёте robots.txt в Search Console. Первая строка, где ожидаемое расходится с результатом, вероятно, и есть эта ошибка группировки.
8. Кэш CDN: язык одного посетителя отдаётся всем
Это было самое странное поведение, вскрытое аудитом. Корневой адрес выдавал редирект 302, менявшийся в зависимости от языка браузера посетителя. Промежуточный слой держал этот ответ в кэше в течение часа, не отправляя заголовок Vary. Результат: язык первого человека, зашедшего на сайт в этот час, отдавался всем последующим. Корпоративный клиент, пришедший с немецким браузером, попадал на турецкую версию, и никто не мог понять почему.
Функция заголовка Vary ровно в этом и состоит: он сообщает кэшу, от каких заголовков запроса зависит сохраняемый ответ. По определению MDN, наличие заголовка Vary «обеспечивает раздельное кэширование ответов в зависимости от заголовков, перечисленных в поле Vary». Если заголовок не отправляется, кэш считает все запросы к одному адресу идентичными и отдаёт один и тот же ответ независимо от языка, cookie или устройства.
Ответ меняется в зависимости от языка, а ключ кэша — только адрес. Язык первого посетителя на час становится языком всех.
Выберите одно из двух решений:
A — Разделите ответ. Добавьте Vary: Accept-Language к каждому ответу, который меняется в зависимости от языка. Кэш будет вести отдельную запись на язык. Цена: падает доля попаданий в кэш.
B — Зафиксируйте ответ (предпочтительно). Пусть корневой адрес делает один постоянный редирект независимо от языка (например, / → 301 → /ru), а языковое предпочтение решается уже внутри страницы. Так и кэш остаётся эффективным, и поисковая система видит одно-единственное поведение.
Второе правило: не измеряйте, не очистив кэш
CDN может держать HTML-ответы до двадцати четырёх часов. Если вы измерите выпущенное исправление сразу, вы измерите старое состояние и придёте к выводу «не исправилось». Порядок проверки после выпуска такой: опубликуйте → очистите кэш соответствующих путей → измерьте. Из-за пропуска этого шага мы не раз наблюдали, как откатывали корректно работающее исправление.
9. Цепочки редиректов и неканонические цели
До аудита корневой адрес вёл себя так: / → 302 → /ru/ → 308 → /ru. Три остановки. Каждая остановка — и дополнительная задержка для браузера, и потеря сигнала; к тому же 302 (временный) на первом шаге говорит, что цель как раз не является постоянной канонической. Всё было сведено к одному шагу: / → 301 → /ru.
Более коварной оказалась вторая находка. На сайте была таблица редиректов, переносившая старые адреса на новые, и 329 целей в этой таблице сами не были каноническими — то есть при применении правил редиректа каждая из них породила бы ещё один редирект. Это отловили до выпуска канонизации; если бы выпустили, родилось бы 329 новых цепочек.
Правило решения
Прежде чем добавить новую строку в таблицу редиректов, проверьте саму цель против канонической формы: верный хост, верная политика слеша, страница действительно отдаёт 200. Эта проверка должна быть обязательным шагом любой работы, меняющей таблицу; разбирать потом по одной обходится в разы дороже.
10. Страницы, теряющиеся на вашем же сайте
Наличие страницы в карте сайта не означает, что её можно найти. Аудит выявил две отдельные статьи потерь.
49 индексируемых страниц-сирот. Страницы, объявленные в карте сайта, но не получающие ни одной ссылки на сайте: одна страница справочного центра (7 языков), пять категорийных страниц интеграций (35 адресов) и 7 адресов, разошедшихся между списками и кодом. Для части из них была написана функция, формирующая адрес, она даже была включена в компонент меню — но её ни разу не вызвали.
70 битых внутренних ссылок. Четыре карточки категорий на странице справки вели на несуществующий путь (4 карточки × 7 языков = 28 ссылок). Хлебные крошки страниц с описанием услуг указывали на так и не написанную страницу-каталог услуг (2 локации × 3 услуги × 7 языков = 42 ссылки) — и тот же битый адрес попадал ещё и в структурированные данные.
Третья находка тоньше: 21 из 33 записей блога находилась на глубине клика 3, и единственным путём к ним был шаг пагинации, помеченный noindex. Технически они сканировались, потому что ссылки были доступны для перехода, но настоящей индексируемой внутренней ссылки на эти записи не существовало.
Метод измерения
Положите с одной стороны список адресов карты сайта, с другой — граф внутренних ссылок вашего сайта (сумму всех <a href> на каждой странице) и возьмите разность. То, что есть в карте, но нет в графе, — сироты; то, что есть в графе, но не отдаёт 200, — битые ссылки. Формировать эти два множества раз в месяц — значит делать видимой потерю, которую большинство сайтов не замечает.
11. Тонкий контент и страницы, которые «считаются переведёнными»
В измерении после аудита среднее по сайту составило 472 слова, а страниц короче 300 слов было 176. Но главной находкой была не сама сырая цифра, а способ её читать.
Первая поправка: вычтите обвязку страницы. Считать текст страницы как есть — значит включить в контент верхнее меню и подвал. На измеренном сайте эта постоянная обвязка занимала от 117 до 233 слов на язык. То есть сырые 300 слов на деле соответствовали телу примерно в 120 слов. Стройте реальный порог не по сырому числу, а по телу с вычтенной обвязкой.
Вторая поправка: нормализуйте морфологию языка. По сырым числам немецкие переводы выглядели неполными (медиана 393 против 610 у испанского). Между тем содержание было один в один тем же; разница целиком объяснялась словообразованием: Flugbuchungssoftware — одно слово, то же выражение по-испански — пять слов. Коэффициенты, измеренные нами на восьми полностью переведённых страницах, оказались такими:
| Язык | Коэффициент (en = 1,00) |
|---|---|
| Немецкий | 0,827 |
| Азербайджанский | 0,916 |
| Турецкий | 0,929 |
| Русский | 0,939 |
| Арабский | 0,963 |
| Испанский | 1,165 |
После этой поправки выяснилось, что дефицита перевода в немецком и испанском нет, а реальный дефицит сосредоточен в арабском (22 адреса) и английском (16 адресов).
Третья находка: краткое изложение — не перевод. Многие арабские версии были не полным переводом, а сокращённым вариантом английского текста — 38–48% от медианы группы. Формально они считались «переведёнными», на практике не могли конкурировать ни по одному запросу.
Четвёртая находка: 7 групп / 67 адресов имели буквально одинаковое тело. Большинство из них были языковыми версиями, открытыми без выполнения перевода.
Правило решения
Если язык «открывают», не сделав перевод, этот язык порождает дублирующийся контент и не приносит пользы даже существующим языкам. Порог для вывода нового языка должен быть таким: тело на этом языке — не менее 85% нормализованного числа слов исходного языка. Если ниже — не публикуйте; а для неопубликованного языка не пишите и hreflang (см. раздел 3).
12. ИИ-поиск: работа, которая идёт после уборки
Не переходите к этому разделу, не закрыв предыдущие одиннадцать пунктов. ИИ-поиск — не отдельный канал, а слой, надстроенный над тем же индексом; если нижний слой сломан, верхний работает сломанно.
Цифры говорят следующее. По наблюдению BrightEdge с февраля 2025 по февраль 2026 ИИ-обзоры появляются примерно в 48% отслеживаемых запросов (годом ранее было ~30%); примерно в половине запросов обзора по-прежнему нет вообще. По измерению Seer Interactive за февраль 2026 в запросах с обзором органический CTR составил 2,4%, без обзора — 3,8%. В панели Pew Research из 900 человек в США (март 2025, 68 879 поисков) в 8% визитов с показанным ИИ-обзором был клик по классической ссылке результата; без обзора эта доля составила 15%. Доля кликов по ссылке внутри обзора — всего 1%.
Ключевая для туризма цифра такая: по данным BrightEdge лишь 17,7% цитат в ИИ-обзорах по туристическим запросам приходят из органической первой десятки (годом ранее было 5,7%). То есть более трёх четвертей цитат берутся из источников, которых нет на первой странице.
Сверху — сравнение органического CTR, снизу — распределение источников цитирования по туристическим запросам. Источники: Seer Interactive и BrightEdge, февраль 2026.
Практический вывод при совместном чтении этих двух цифр таков: первое место в выдаче не гарантирует цитирования, а быть процитированным — отдельная работа. И у цитирования есть измеримый эквивалент: по измерению Seer Interactive за апрель 2026 бренды, процитированные в том же запросе, получают на 120% больше органических кликов на показ, чем непроцитированные.
Так что же делать — и чего не делать
Сначала проясним, чего делать не надо, потому что шума в этой области слишком много.
llms.txt — не решение. В исследовании Ahrefs, охватившем 137 000 доменов, 97% файлов llms.txt в мае 2026 не получили ни одного запроса; из примерно 38 000 доменов с валидным файлом лишь около 1100 получили хотя бы один запрос, причём 96% этих запросов пришли от ботов, и большинство из них были не ИИ-инструментами, а средствами аудита и профилирования. На стороне Google картина тоже ясна: официальная документация по ИИ-функциям говорит: «Вам не нужно создавать новые машиночитаемые файлы, текстовые файлы для ИИ или разметку, чтобы появляться в этих функциях», и добавляет: «Нет и специальных структурированных данных schema.org, которые нужно было бы добавить.»
Создать файл безвредно, но строить на нём стратегию видимости нельзя. По-настоящему работают четыре вещи:
- Абзац-ответ на каждой странице, который машина может чисто извлечь. Сразу под заголовком, 40–60 слов, определительный и осмысленный сам по себе. Фразы вида «в этой статье мы рассмотрим» процитировать нельзя; фразу «Void — это признание билета невыписанным после тикетинга, и оно возможно только внутри окна, заданного поставщиком» процитировать можно.
- Проверяемая цифра и источник. Цифра с названием организации и годом ценнее бездоказательного утверждения и для человека, и для машины. Не пишите цифру, источник которой не сможете назвать; расскажите качественно.
- Стандартные структурированные данные, настроенные правильно. Не ищите специальную схему; корректно и последовательно заполняйте стандартные типы вроде
Organization,BreadcrumbList,FAQPage. Две типичные ошибки, найденные в аудите: логотип организации указывал на несуществующий файл (не сумев подтянуть логотип, поисковая система полностью отбрасывает изображение издателя) и данные хлебных крошек указывали на неверную категорию. - Уникальный контент, действительно переведённый. Ни один из 67 адресов с одинаковым телом на семи языках не мог быть процитирован.
Здесь же действуют и элементы управления сниппетами: Google указывает, что nosnippet, data-nosnippet и noindex работают и для ИИ-функций. То есть если вы не хотите, чтобы раздел использовался в обзорах, инструмент у вас уже есть.
13. Чек-лист технической видимости из двадцати пунктов
Не требует инструментов, кроме браузера и curl. В каждом пункте указан ожидаемый результат.
| № | Проверка | Ожидаемый результат |
|---|---|---|
| 1 | Запрашивается хост без www | 301 → вариант с www (или наоборот, последовательно) |
| 2 | Запрашивается вариант со слешем в конце | 301 → к единой форме |
| 3 | Запрашивается корневой адрес | 301 за один шаг, независимо от языка |
| 4 | На 10 случайных страницах считается canonical | Ровно 1 на каждой странице |
| 5 | Значение canonical — адрес самой страницы? | Да, включая хост и слеш |
| 6 | Набор hreflang на странице продукта/блога | Только языки с реальным переводом |
| 7 | Каждая цель hreflang запрашивается по одной | Все 200 и с настоящим контентом |
| 8 | Указывает ли каждая цель обратно | Да, взаимно |
| 9 | Коды языков соответствуют ISO 639-1? | Да; регион отдельно не написан |
| 10 | Выдумывается и запрашивается несуществующий адрес | 404 (а не 200 + «не найдено») |
| 11 | Нелатинский slug запрашивается сырым и кодированным | Обе формы отдают один код |
| 12 | Хост карты сайта — канонический хост? | Да |
| 13 | Из карты сайта выбираются 10 адресов | Все 200 и HTML |
| 14 | Изучаются значения lastmod |
Различаются, реальные даты |
| 15 | Читаются группы robots.txt | Правило написано отдельно в каждой группе |
| 16 | Vary в ответе, зависящем от языка |
Есть; либо ответ от языка не зависит |
| 17 | Выбираются цели редиректов | Все канонические и отдают 200 |
| 18 | Разность «карта сайта − граф внутренних ссылок» | Пустое множество (сирот нет) |
| 19 | Сканируются ссылки меню и хлебных крошек | Ни одна не отдаёт 404 |
| 20 | Порядок измерения после выпуска | Опубликовать → очистить кэш → измерить |
14. Календарь аудита
Если вы поставите эту работу как разовый проект, через полгода она вернётся. На измеренном сайте единственной причиной деградации была не халатность; система сама уходила в сторону, потому что каждый новый шаблон страницы порождал свой вариант.
| Частота | Работа | Почему |
|---|---|---|
| При каждом выпуске | Пункты 1–5, 10, 20 | Новый шаблон не знает старого правила |
| Еженедельно | Пункты 7, 8, 19 | Переводы и добавления контента ломают набор |
| Ежемесячно | Пункты 12–14, 18 | Карта сайта и реальность медленно расходятся |
| Раз в квартал | Пункты 6, 9, 11, 15–17 | Меняются инфраструктура и таблица редиректов |
Источники
- Google Search Central — Локализованные версии страниц (hreflang)
- Google Search Central — Объединение дублирующихся URL (canonical)
- Google Search Central — Коды состояния HTTP и soft 404
- Google Search Central — Рекомендации по структуре URL
- Google Search Central — Функции ИИ и ваш сайт
- IETF — RFC 9309: Robots Exclusion Protocol
- MDN Web Docs — Заголовок Vary
- BrightEdge — AI Overviews at the One-Year Mark: Presence, Size, and What They're Citing (февраль 2026)
- Данные Seer Interactive, изложение ALM Corp — Google AI Overviews and Organic CTR in 2026
- Данные Seer Interactive, изложение Omnibound — Google AI Overviews Statistics (апрель 2026)
- Pew Research Center — Google users are less likely to click on links when an AI summary appears
- Ahrefs — We Analyzed 137K Sites: 97% of llms.txt Files Never Get Read (июнь 2026)
Все измерения без указания источника (1088 страниц, 921 отсутствующий canonical, 1469 → 1386 в карте сайта, 49 сирот, 70 битых ссылок, 329 неканонических целей редиректа, языковые коэффициенты) относятся к нашему собственному аудиту, проведённому в июле 2026 года на семиязычном сайте туристического ПО.
Часто задаваемые вопросы
Для чего именно нужен тег canonical?
Если одно и то же или очень похожее содержимое доступно с нескольких адресов, он сообщает поисковой системе, какой из них следует считать «основным». Но это не приказ, а, по собственной формулировке Google, сильный сигнал; окончательное решение принимает поисковая система. Для адресов, которые вы хотите закрыть навсегда, используйте вместо canonical редирект 301 — редирект является более сильным сигналом.
Почему плохо, что открыты и адрес с www, и без него?
Потому что технически это два разных сайта. Если оба отдают 200, каждая ваша страница становится доступной дважды; входящие ссылки, данные о кликах и краулинговый бюджет делятся пополам. Выберите один вариант и перенаправьте на него другой через 301, а карта сайта и внутренние ссылки пусть используют выбранный вариант.
Можно ли писать hreflang для всех языков с одним и тем же slug?
Только если этот slug действительно работает на том языке. Google связывает hreflang с условием взаимности: если две страницы не указывают друг на друга, теги могут быть проигнорированы. Написать hreflang для языка без перевода — значит объявить поисковой системе несуществующую страницу. Отсутствующий hreflang лучше, чем неверный.
Что такое soft 404 и как его заметить?
Это ситуация, когда содержимое представляет собой сообщение об ошибке, а сервер возвращает код успеха 200. Быстрее всего заметить так: выдумайте несуществующий адрес на своём сайте и запросите его; если возвращается не 404, у вас soft 404. Отчёт об индексировании в Search Console тоже перечисляет такие страницы в отдельной категории.
Почему адреса с арабскими или русскими символами иногда отдают 404?
Браузер отправляет эти символы в процентно-кодированном виде; если сервер это кодирование не разбирает, адрес не находится. Поскольку при проверке сырого вида всё работает, проблема может долго оставаться скрытой. Метод контроля — запросить один и тот же адрес и в сыром, и в процентно-кодированном виде и убедиться, что оба ответа отдают одинаковый код состояния.
Почему мой органический трафик упал с момента появления ИИ-обзоров?
Измерения показывают структурную разницу: по данным Seer Interactive за февраль 2026 в запросах с обзором органический CTR составил 2,4%, без обзора — 3,8%. А в панели Pew Research доля кликов по ссылке результата составила 8% при показанном обзоре и 15% без него. То есть даже оставшись на той же позиции, в запросах с обзором вы получите меньше кликов; цель — быть процитированным внутри этого обзора.
Нужно ли мне создавать файл llms.txt?
Вреда нет, но не стройте на нём свой план видимости. В исследовании Ahrefs по 137 000 доменов 97% этих файлов в мае 2026 не получили ни одного запроса. Google в официальной документации тоже прямо указывает, что для показа в ИИ-функциях не требуются новые машиночитаемые файлы, разметка или специальные структурированные данные.
Как часто следует повторять аудит?
Если задумать это как разовый проект, через несколько месяцев всё сломается, потому что каждый новый шаблон страницы склонен порождать собственный вариант адреса. Практический порядок: проверки адресов и canonical — при каждом выпуске, проверки hreflang и внутренних ссылок — еженедельно, анализ карты сайта и сирот — ежемесячно, инфраструктурные проверки — раз в квартал.
Пять дел, которые можно сделать завтра утром
- Запустите тест пяти вариантов. Для трёх самых посещаемых страниц запросите варианты с www и без, со слешем и без, а также старый путь, если он есть; запишите коды в таблицу. Если 200 отдают несколько — ваша первая задача определена.
- Посчитайте canonical на десяти страницах. Сколько
rel="canonical"в исходном коде страницы и является ли значение адресом самой страницы? Каждая страница, где получился ноль или больше одного, — это находка. - Запросите по одной все цели hreflang одной записи. Все ли отдают 200, настоящий ли контент в теле, указывают ли обратно? Если есть язык без соответствия, уберите эту строку — это самый быстрый выигрыш из всех.
- Выдумайте несуществующий адрес и запросите его. Если не приходит 404, у вас soft 404; одно это исправление вскроет сразу несколько невидимых поломок.
- Выберите десять адресов из карты сайта. Верный ли хост, все ли отдают 200 и HTML, настоящие ли значения
lastmod? Если карта сайта сообщает не то, что есть, все остальные ваши измерения тоже лягут на неверное основание.