Hreflang-аудит мультиязычного сайта: найдём и исправим ошибки

Ваш сайт отлично ранжируется в Германии, но Google упорно показывает русскую версию немецким пользователям. Или английская страница появляется в Украине вместо украинской. Знакомо? Это классическая проблема отсутствия или неправильной настройки hreflang. Мы сталкивались с такими кейсами десятки раз — и каждый раз трафик восстанавливался на 20–40%. На одном проекте с 12 языками (более 5000 страниц) мы нашли 340 ошибок возвратных ссылок и 60 неверных кодов. После исправления трафик из Европы вырос на 35% за 2 месяца, а клиент сэкономил 1.2 млн рублей в год на контекстной рекламе. По оценкам, 90% мультиязычных сайтов имеют хотя бы одну критическую ошибку hreflang, что приводит к потере до 40% потенциального трафика.

Почему hreflang критичен для мультиязычного SEO?

Представьте интернет-магазин с версиями для России (ru-RU), Украины (ru-UA) и Казахстана (ru-KZ). Без hreflang Google не понимает, какую страницу показывать пользователю в Алматы. В итоге — низкий CTR, высокий bounce rate. Hreflang решает эту задачу, привязывая каждую страницу к конкретному языку и региону. Это особенно важно для сайтов с одинаковым контентом на разных языках — без hreflang они воспринимаются как дубли. Согласно исследованию, сайты с правильно настроенным hreflang получают на 30% больше органического трафика. Hreflang-аудит в 2 раза эффективнее для решения дублей, чем использование только canonical.

Какие коды языков и регионов использовать?

Типичная ошибка: код ua для украинского языка (это код страны, а не языка). Правильно — uk. Также не используйте eng (трёхбуквенный), только двухбуквенные коды.

Как избежать типичных ошибок hreflang?

Каждая страница должна включать самоссылку. Если canonical ведёт на https://example.com/ru/, а hreflang на http://example.com/ru/ — конфликт. URL должны совпадать полностью.

Как провести hreflang-аудит самостоятельно?

1. Соберите все URL сайта с помощью краулера (например, Screaming Frog).
2. Экспортируйте отчёт Hreflang Pages и отфильтруйте ошибки: Missing Return Links, Incorrect Language Codes, Non-Canonical Return Link.
3. Проверьте взаимность ссылок — каждая языковая версия должна ссылаться на все остальные, включая себя.
4. Убедитесь, что страницы с noindex не содержат hreflang.
5. Исправьте найденные ошибки: добавьте недостающие ссылки, поправьте коды, синхронизируйте canonical и hreflang.

Мы используем аналогичный подход, но автоматизируем его с помощью Python-скриптов. Пример скрипта выше.

Что такое x-default и когда он необходим?

x-default — это резервная страница для пользователей, чей язык или регион не указан. Типичные сценарии:

• Страница выбора языка.
• Английская версия как дефолтная для незнакомых рынков.
• Если нейтральной версии нет, x-default можно опустить — поисковик сам выберет наиболее подходящую.

Выбор структуры URL: подпапки, поддомены или ccTLD

Выбор структуры URL влияет на SEO и управляемость. Подпапки (example.com/ru/) сохраняют ссылочный вес и просты в обслуживании — это баланс между SEO и удобством. Поддомены (ru.example.com) дают гибкость в аналитике и разделении кода, но размывают авторитет домена. ccTLD (.ru) даёт сильный геосигнал, но требует отдельных настроек для каждого домена, дороже и сложнее в управлении. Для большинства проектов мы рекомендуем подпапки как оптимальный вариант.

Как мы проводим аудит hreflang

Наш подход — комплексный: от автоматизированного краулинга до ручной валидации. Используем Screaming Frog с фильтрами: Missing Return Links, Incorrect Language Codes, Non-Canonical Return Link. Для клиента с 12 языками (более 5000 страниц) мы нашли 340 ошибок возвратных ссылок и 60 неверных кодов. После исправления трафик из Европы вырос на 35% за 2 месяца.

Для автоматической проверки взаимности пишем Python-скрипт. Он собирает hreflang с каждой страницы и проверяет, есть ли обратная ссылка.

import requests, time
from bs4 import BeautifulSoup
from urllib.parse import urljoin

def fetch_hreflang(url):
    try:
        resp = requests.get(url, timeout=10, headers={'User-Agent': 'HreflangAudit/1.0'})
        soup = BeautifulSoup(resp.text, 'html.parser')
        links = soup.find_all('link', rel='alternate')
        return {link.get('hreflang'): link.get('href') for link in links if link.get('hreflang')}
    except:
        return {}

def audit_hreflang(urls):
    hreflang_map = {}
    errors = []
    for url in urls:
        hreflang_map[url] = fetch_hreflang(url)
        time.sleep(0.5)
    for url, alternates in hreflang_map.items():
        for lang, alt_url in alternates.items():
            if lang == 'x-default':
                continue
            if alt_url not in hreflang_map:
                errors.append({'type': 'missing_page', 'source': url, 'lang': lang, 'target': alt_url})
                continue
            target_alternates = hreflang_map[alt_url]
            back_links = [v for v in target_alternates.values() if v == url]
            if not back_links:
                errors.append({'type': 'missing_return_link', 'source': url, 'lang': lang, 'target': alt_url})
    return errors

Также проверяем через Google Search Console International Targeting — раздел Language. Там видны критические ошибки, которые заметил Googlebot.

Что входит в аудит hreflang

• Полный отчёт по всем языковым версиям с детальным списком ошибок (отсутствие самоссылок, неверные коды, конфликты canonical).
• Рекомендации по исправлению каждой ошибки с примерами кода.
• Настройка автогенерации hreflang для sitemap или сборки (под ваш стек).
• Консультация инженера по оптимизации мультиязычной структуры.
• Повторная проверка после внедрения правок.

Сроки и стоимость

Аудит hreflang на сайте до 5 языков и 500 страниц занимает 2–3 рабочих дня. Реализация правок и настройка автогенерации — ещё 3–5 дней. Точный срок и стоимость рассчитываем индивидуально после предварительного анализа. Свяжитесь с нами — оценим ваш проект бесплатно. Закажите hreflang-аудит, и вы увидите реальные результаты в Search Console уже через месяц. Получите консультацию — наши инженеры помогут разобраться даже в самой запутанной конфигурации.

Почему Core Web Vitals критичны для технического SEO

PageSpeed показывает 34/100 на мобильных. В Search Console — красные метрики по всем страницам категорий. Конкурент с сайтом на 3 года старше стоит выше в выдаче, несмотря на более слабые тексты. Техническая производительность стала прямым ранжирующим фактором — и разрыв между «приемлемо» и «быстро» стоит позиций. Мы решали эту проблему для десятков проектов — от интернет-магазинов до SaaS-платформ — и знаем, какие ошибки съедают ранжирование.

Core Web Vitals: что реально влияет на позиции

Google использует три метрики как сигналы ранжирования (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, заменил FID с последнего крупного обновления алгоритма).

LCP: почему 8 секунд — это не проблема изображения

LCP измеряет время отрисовки самого большого видимого элемента страницы. Чаще всего — hero image или H1. Пороги: хорошо < 2.5s, плохо > 4s.

Типичный диагноз на реальном проекте: интернет-магазин одежды, LCP 7.8s на мобильных. Элемент — hero image категории, 4.2MB JPEG без srcset, загружается через CSS background-image (не <img>). Проблема здесь двойная: во-первых, браузер не может preload CSS background images через <link rel="preload"> стандартным способом. Во-вторых, 4.2MB на мобильном соединении — это физически медленно.

Решение по шагам:

1. Переносим hero из CSS background в <img> с fetchpriority="high" и loading="eager"
2. Конвертируем в WebP, добавляем srcset: 800w для мобильных, 1400w для десктопа
3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
4. Убираем все render-blocking скрипты выше hero через defer

Итог: LCP 7.8s → 1.9s. Без смены хостинга, без CDN.

Если LCP — не изображение, а текстовый блок: проблема может быть в TTFB (медленный сервер), в render-blocking CSS/JS, или в web fonts с font-display: block.

CLS: смещения, которые раздражают пользователя и Google

CLS измеряет суммарный сдвиг элементов в процессе загрузки. Пороги: хорошо < 0.1, плохо > 0.25. CLS 0.35 — это баннер, который появляется через секунду и сдвигает всё содержимое страницы вниз.

Источники CLS:

• Изображения без заданных размеров. <img src="photo.jpg"> без width и height — браузер не резервирует место, контент прыгает при загрузке. Фикс: явные width/height или aspect-ratio в CSS.
• Рекламные блоки и виджеты. Google Ads, чат-виджеты, cookie consent — всё, что появляется после основного контента. Решение: резервировать место через min-height или загружать до рендера основного контента.
• Web fonts. FOUT (Flash of Unstyled Text) и FOIT (Flash of Invisible Text) могут вызывать переформатирование. font-display: swap с size-adjust (CSS свойство для выравнивания размеров fallback шрифта) минимизирует CLS.
• Динамический контент. Если блок появляется после загрузки (fetch данных, lazy load) — добавляем skeleton placeholder с нужными размерами.

INP: почему интерфейс «зависает» на 500ms

INP измеряет задержку ответа на любое взаимодействие пользователя: клик, тап, ввод. Пороги: хорошо < 200ms, плохо > 500ms. INP 680ms — это когда пользователь нажимает кнопку фильтра, а ничего не происходит полсекунды.

Главная причина высокого INP — заблокированный main thread. JavaScript-бандл 2.1MB парсируется и выполняется синхронно. Пока выполняется, пользовательские события не обрабатываются.

Диагностика через Chrome DevTools → Performance → взаимодействие с подозрительной задержкой → найти Long Tasks (> 50ms). Типичные виновники:

• Непрерывная обработка большого списка без requestIdleCallback или requestAnimationFrame
• Тяжёлые event listeners без debounce/throttle
• Синхронный setState в React, который триггерит полный ре-рендер сложного дерева компонентов
• Third-party scripts: livechat, аналитика, виджеты — они исполняются в том же main thread

Решения: code splitting через динамический import(), перенос тяжёлых вычислений в Web Workers, React.memo + useMemo для предотвращения лишних ре-рендеров, scheduler API для приоритизации задач.

Schema.org: разметка, которую читают роботы

Структурированные данные через JSON-LD — не прямой ранжирующий фактор, но дают rich snippets в выдаче (звёзды рейтингов, цены, дата публикации), что увеличивает CTR на 20–30%.

Типы разметки по сценариям:

• E-commerce: Product с offers (цена, наличие, валюта), aggregateRating (рейтинг из отзывов), brand. BreadcrumbList для навигации. ItemList для страниц категорий.
• Статьи и блог: Article или BlogPosting с author, datePublished, dateModified, image. Organization и WebSite на главной странице — помогают Google связать сайт с брендом.
• Локальный бизнес: LocalBusiness с address, telephone, openingHours, geo. Критично для локального SEO.
• FAQ: FAQPage с mainEntity — вопросы и ответы могут появляться прямо в выдаче как раскрывающийся блок.

Валидация: Google Rich Results Test и Schema Markup Validator. Частая ошибка — указать price без priceCurrency, или ratingValue без reviewCount. Google игнорирует неполную разметку.

Как проводить технический SEO-аудит

Сканируемость. robots.txt блокирует нужные страницы (или наоборот, не блокирует служебные). Canonical URLs настроены неправильно — дублируются страницы с UTM-метками. Sitemap содержит страницы с noindex. Всё это Screaming Frog или Sitebulb покажут за час сканирования.

Core Web Vitals в масштабе. Google Search Console → Core Web Vitals → смотрим не отдельные страницы, а группы URL (шаблон страницы продукта, шаблон категории, блог). Проблема обычно системная — одна ошибка в шаблоне портит сотни страниц.

JavaScript SEO. Google рендерит JavaScript, но с задержкой (иногда дни для полного рендера). Для критичного контента — SSR или SSG обязательны. Проверяем через Search Console → Inspect URL → View Crawled Page: что видит Googlebot.

Internal linking. Орфанные страницы (нет входящих внутренних ссылок) теряют PageRank. Битые ссылки (404) — сигнал качества.

Что входит в работу

• Документация: отчёт с найденными проблемами, roadmap по приоритетам, тайминги для каждого этапа.
• Доступы: настройка мониторинга (SpeedCurve, Sentry Search Console), передача dashboard.
• Обучение: разбор типичных ошибок для вашей команды (1–2 созвона).
• Поддержка: сопровождение в течение месяца после деплоя — проверка метрик, фикс регрессий.

Свяжитесь с нами — мы оценим ваш проект за 2 дня и покажем, сколько позиций можно вернуть за счёт технического SEO. Опыт работы с проектами уровня сотен тысяч посещений в месяц — гарантируем измеримый результат в Core Web Vitals до/после. Закажите аудит в этой форме — получите персональный чек-лист из 15 пунктов.