Техническое SEO для владельца нового сайта: руководство 2026 года

Digital Craft Tbilisi

Введение: Почему техническое SEO — это фундамент вашего успеха в интернете

Представьте, что вы построили красивый магазин в центре города, но забыли сделать вход или указатели к нему. Примерно так же работает сайт без правильной технической оптимизации — он существует, но поисковые системы его не видят, а потенциальные клиенты не могут найти.

Техническое SEO — это фундамент, на котором строится все продвижение вашего сайта в Google. Это набор технических настроек и требований, которые позволяют поисковым роботам правильно индексировать ваш ресурс, а пользователям — комфортно с ним взаимодействовать. Без этой базы даже самый качественный контент и дорогостоящая реклама не принесут желаемого результата.

Эта статья представляет собой чек-лист технических требований для запуска нового сайта, который будет отлично ранжироваться в поисковых системах. Мы разберем каждый аспект простым языком, чтобы вы понимали не только "что делать", но и "зачем это нужно".

1. Настройка 301 редиректов: обеспечиваем единственный путь к каждой странице

Что такое 301 редирект и зачем он нужен?

301 редирект — это постоянное перенаправление с одного адреса страницы на другой. Это как указатель "Офис переехал по новому адресу", который автоматически отправляет посетителя в нужное место.

Проблема в том, что технически одна и та же страница может быть доступна по разным адресам. Например:

  • https://site.com/
  • http://site.com/
  • https://www.site.com/
  • https://site.com/index.html

Для Google это разные страницы с одинаковым контентом — дубли. Это размывает вес страницы и негативно влияет на ранжирование.

Обязательные редиректы для вашего сайта

1. Редиректы с index-файлов

Все варианты с index.html или index.php должны перенаправляться на чистый URL:

  • С https://site.com/index.html → на https://site.com/
  • С https://site.com/blog/index.php → на https://site.com/blog/

2. Редиректы на HTTPS

В 2026 году сайт без SSL-сертификата считается плохой практикой и негативно воспринимается как поисковыми системами, так и пользователями. Google официально использует HTTPS как фактор ранжирования:

  • С http://site.com/ → на https://site.com/

3. Редиректы для www/без www

Выберите одну версию (с www или без) и придерживайтесь её:

  • С https://www.site.com/ → на https://site.com/ (или наоборот)

4. Редиректы для слеша в конце URL

Главное правило здесь — выбрать единый формат для всего сайта и настроить редиректы на канонический вариант. Оба подхода валидны с технической точки зрения:

Вариант А (рекомендуемый):

  • Главная страница — всегда СО слешем: https://site.com/
  • Все остальные страницы — всегда БЕЗ слеша: https://site.com/blog

Вариант Б:

  • Все страницы со слешем на конце

Мы рекомендуем вариант А, но главное — не смешивать подходы. Если выбрали формат без слеша для внутренних страниц, настраивайте редирект с /blog/ на /blog для всех URL.

Важно: избегайте цепочек редиректов

Частая ошибка — настройка нескольких последовательных редиректов:

http://www.site.com/blog/ → https://www.site.com/blog/ → https://site.com/blog/ → https://site.com/blog

Это 4 редиректа! Каждый из них замедляет загрузку и может привести к тому, что поисковый робот просто прекратит обход страницы. Настраивайте правила так, чтобы было максимум 1-2 редиректа.

2. Скорость загрузки сайта: почему это критически важно

Целевые показатели скорости

Google прямо заявляет: скорость загрузки — это фактор ранжирования, особенно через призму Core Web Vitals — набора метрик, которые измеряют реальный пользовательский опыт. Особенно это важно для мобильных устройств.

Ваши цели:

  • PageSpeed Insights: 70-75 баллов для мобильной версии, 85+ для десктопной
  • TTFB (Time To First Byte): не более 0,6 секунды
  • First Interactive (TTI): не более 3-5 секунд при эмуляции 4G

Как измерять скорость правильно

Используйте два инструмента:

  1. Google PageSpeed Insights (developers.google.com/speed/pagespeed/insights)
    Показывает оценку и конкретные рекомендации по улучшению
  2. WebPageTest.org
    Настройте проверку из целевого региона, включите эмуляцию мобильного устройства и скорость 4G. Обращайте внимание на TTFB и First Interactive.

Практические шаги для ускорения

На начальном этапе после запуска:

  • Подключите CDN (Content Delivery Network) — даже бесплатный CloudFlare существенно ускорит загрузку статических файлов
  • Активируйте HTTP/3 (QUIC) — к 2026 году это стандарт, который существенно ускоряет загрузку на мобильных сетях (или как минимум HTTP/2)
  • Включите сжатие Gzip или Brotli для текстовых ресурсов
  • Настройте кеширование статических файлов (минимум на 3 дня)

3. Валидность HTML-кода: чистота под капотом

HTML-код вашего сайта должен быть валидным, то есть соответствовать стандартам W3C. Грубые ошибки в коде могут привести к тому, что поисковый робот неправильно поймет структуру страницы или вообще не сможет её обработать.

Как проверить валидность

Используйте официальный валидатор: validator.w3.org

100% валидность не всегда достижима (некоторые современные технологии могут вызывать предупреждения), но критических ошибок быть не должно. Google обращает внимание в первую очередь на структурные проблемы — незакрытые теги, неправильную вложенность элементов.

4. Рендеринг контента: что видит Google на вашем сайте

Правило: важный контент должен быть в HTML

Частая ошибка — загрузка текстов, заголовков или навигации через JavaScript с задержкой (AJAX-запросы). У робота Google очень маленький таймаут для выполнения JS-скриптов, и он может просто не дождаться загрузки важного контента.

Правильный подход: весь значимый для SEO контент (заголовки H1-H6, основной текст, ссылки на другие страницы, мета-теги) должен быть сразу в HTML-коде страницы.

Lazy Load для изображений: современный подход

Отложенная загрузка изображений (Lazy Load) — это отличная техника для ускорения сайта. Не волнуйтесь, это легко проверить с помощью современных встроенных возможностей браузеров.

Рекомендуемый способ: используйте нативный атрибут loading="lazy":

<img src="image.jpg" alt="Описание" loading="lazy">

Это встроенная функция браузеров, которая полностью поддерживается Google и не требует никаких дополнительных скриптов. Изображения будут загружаться только когда пользователь прокручивает страницу до них.

Важно (Исключение для LCP): Никогда не используйте loading="lazy" для самого первого изображения на странице (главный баннер, логотип или фото товара). Для него лучше использовать fetchpriority="high", чтобы оно загружалось мгновенно.

Для сложных случаев: если вам нужна поддержка старых браузеров или более тонкая настройка (например, для фоновых изображений через CSS), можно использовать JavaScript-решения типа yall.js, но обязательно убедитесь, что выбранное решение SEO-friendly.

Важно: после внедрения любого Lazy Load обязательно проверьте корректность рендеринга через инструмент проверки URL в Google Search Console.

5. Пагинация: как правильно организовать многостраничность

Пагинация — это разбивка длинного списка (товаров, статей, событий) на несколько страниц. Для блога или каталога это стандартная практика, но с точки зрения SEO здесь много нюансов.

Основные правила пагинации

1. Ссылки должны быть понятны роботу

Используйте обычные HTML-ссылки:

<a href="/blog/?page=2">2</a>

Не используйте навигацию через JavaScript без ссылок в HTML.

2. Несуществующие страницы отдают 404

Если в вашем блоге 50 статей по 10 на странице (5 страниц пагинации), то:

  • /blog/?page=6 должна вернуть код 404 Not Found
  • /blog/?page=qwerty или /blog/?page=-1 тоже 404

3. Избегайте дублей

Страницы /blog/ и /blog/?page=1 — это один и тот же контент.

Решение: настройте 301 редирект с /blog/?page=1 на /blog/

В самом пагинаторе не должно быть ссылки на /?page=1 — только на чистый URL /blog/.

4. Уникальные Title и Description для страниц пагинации

Реализуйте возможность шаблонизации мета-тегов:

  • Страница 1: "Блог компании — полезные статьи о маркетинге"
  • Страница 2: "Блог компании — страница 2 | Статьи о маркетинге"

Это помогает избежать проблем с дублированным контентом, о которых мы подробно поговорим в разделе "Борьба с дублями".

6. Микроразметка: помогаем Google понять контент сайта

Open Graph для социальных сетей

Open Graph — это мета-теги, которые определяют, как ваша страница будет выглядеть при публикации в Facebook, LinkedIn или мессенджерах.

Обязательные теги:

<meta property="og:title" content="Заголовок страницы" />
<meta property="og:description" content="Описание страницы" />
<meta property="og:image" content="https://site.com/image.jpg" />
<meta property="og:url" content="https://site.com/page" />

Проверка: используйте developers.facebook.com/tools/debug или opengraphcheck.com

Хлебные крошки (Breadcrumbs) с микроразметкой Schema.org

Хлебные крошки — это навигационная цепочка вида:
Главная > Услуги > SEO-продвижение

Они должны быть размечены через Schema.org в формате JSON-LD:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [{
    "@type": "ListItem",
    "position": 1,
    "name": "Главная",
    "item": "https://site.com/"
  },{
    "@type": "ListItem",
    "position": 2,
    "name": "Услуги",
    "item": "https://site.com/services"
  }]
}
</script>

Важно: используйте именно Schema.org, а не устаревший data-vocabulary.org.

Проверка: search.google.com/structured-data/testing-tool

7. Hreflang и HTML lang: работаем с многоязычностью

Если ваш сайт работает на нескольких языках (что актуально для бизнеса, работающего на международную аудиторию), вам нужно правильно указать это поисковикам.

Атрибут HTML lang

На каждой странице в теге 

<html>
указываем язык контента:
<html lang="ru"> <!-- для русской версии -->
<html lang="ka"> <!-- для грузинской версии -->
<html lang="en"> <!-- для английской версии -->

Важно: регистр имеет значение. Правильно: en, ka, неправильно: EN, Ka.

Атрибут hreflang

Hreflang сообщает Google, что у вас есть альтернативные языковые версии страницы. Согласно официальной документации Google, вы можете указывать либо только код языка, либо язык + регион.

Когда достаточно только кода языка:

В большинстве случаев достаточно указывать только язык (ka, ru, en):

<link rel="alternate" hreflang="ru" 
  href="https://site.com/ru/page" />
<link rel="alternate" hreflang="ka" 
  href="https://site.com/ka/page" />
<link rel="alternate" hreflang="en" 
  href="https://site.com/en/page" />

Когда добавлять региональный код:

Региональный код (например, ka-GE, ru-GE) добавляется только если контент для аудитории в конкретной стране принципиально отличается от контента для носителей этого языка в других странах. Например, для сайта, работающего в Грузии:

  • Цены указаны в лари вместо рублей или долларов
  • Упоминаются местные реалии, законы, адреса
  • Контент заточен под местный рынок
<link rel="alternate" hreflang="ru-GE" 
  href="https://site.com/ru/page" />
<link rel="alternate" hreflang="ka-GE" 
  href="https://site.com/ka/page" />

Атрибут x-default:

x-default — это специальный атрибут hreflang, который указывает Google, какую страницу показывать пользователям, если их язык/регион не соответствует ни одному из указанных в hreflang.

Как использовать x-default:

Вариант 1: Если ваш бизнес международный (Отели, IT, Экспорт)

Если вы хотите, чтобы любой иностранец (француз, японец, швед) понял ваш контент, в x-default нужно указать английскую версию.

<link rel="alternate" hreflang="x-default" 
  href="https://site.com/en/" />
<link rel="alternate" hreflang="en" 
  href="https://site.com/en/" />
<link rel="alternate" hreflang="ka" 
  href="https://site.com/ka/" />
<link rel="alternate" hreflang="ru" 
  href="https://site.com/ru/" />

Вариант 2: Если ваш бизнес локальный (Доставка еды в Грузии, местный сервис)

Если ваши услуги привязаны к стране и вам важно показать «оригинал», в x-default нужно указать грузинский (основной местный) язык.

<link rel="alternate" hreflang="x-default" 
  href="https://site.com/ka/" />
<link rel="alternate" hreflang="ka" 
  href="https://site.com/ka/" />
<link rel="alternate" hreflang="ru" 
  href="https://site.com/ru/" />
<link rel="alternate" hreflang="en" 
  href="https://site.com/en/" />

Правило self-referencing: каждая страница должна ссылаться сама на себя. Этот блок ссылок должен быть идентичным на всех языковых версиях.

Например, на русской версии он выглядит так же, как и на английской:

<link rel="alternate" hreflang="ru" 
  href="https://site.com/ru/page" />
<link rel="alternate" hreflang="ka" 
  href="https://site.com/ka/page" />
<link rel="alternate" hreflang="en" 
  href="https://site.com/en/page" />

8. Борьба с дублями: один контент — один URL

Дублированный контент — одна из самых распространенных проблем, которая размывает вес страниц и мешает продвижению.

Типичные причины появления дублей

1. Завершающий слеш

Как мы говорили в разделе о редиректах, выберите один формат и настройте 301 редирект на канонический вариант.

2. Регистр букв в URL

/services и /Services — технически разные страницы. Всегда приводите URL к нижнему регистру (lowercase).

3. Бесконечный слеш

Некоторые сайты отдают код 200 OK на такие запросы:
/blog/////article/////

Решение: настройте 301 редирект на нормализованный URL.

4. Страницы поиска

Страницы с результатами поиска по сайту (/search?q=keyword) создают бесконечное количество дублей. Частая "боль" многих владельцев бизнеса в том, что эти страницы случайно попадают в индекс и конкурируют с основными страницами.

Решение:

  • Добавьте в 
    <head>
    : 
    <meta name="robots" content="noindex, nofollow" />
  • Закройте в robots.txt: Disallow: /*?search=

5. GET-параметры с произвольными значениями

Если у вас есть сортировка /catalog?sort=price, то страница /catalog?sort=blahblah не должна возвращать 200 OK — только 404 или 301 редирект на дефолтное значение.

Исключение: UTM-метки (например, ?utm_source=facebook) могут содержать любые значения — это нормально.

9. Canonical URL: указываем главную версию страницы

Canonical — это специальный тег, который говорит Google: "Если есть несколько похожих страниц, вот эта — главная".

Основные правила использования canonical

1. Каждая страница должна иметь canonical

Даже если страница не является дублем, canonical должен указывать на саму себя:

<link rel="canonical" href="https://site.com/page" />

2. Пагинация: canonical на саму себя

В отличие от некоторых старых рекомендаций, мы считаем, что каждая страница пагинации меняет контент, поэтому:

/blog/?page=2 → canonical на https://site.com/blog/?page=2

3. GET-параметры, не влияющие на контент

Для UTM-меток и других параметров, которые не меняют контент:

/page?utm_source=fb → canonical на https://site.com/page

4. Только абсолютные URL

Неправильно: 

<link rel="canonical" href="/page" />

Правильно: 
<link rel="canonical" href="https://site.com/page" />

5. Указываем только главное зеркало

Если доступны и HTTP, и HTTPS версии, canonical на обеих должен вести на HTTPS.

10. Безопасность сайта: SSL и защита от уязвимостей

SSL-сертификат — это обязательно

В 2026 году HTTPS — это не опция, а базовое требование. Google явно понижает в выдаче сайты без SSL, а браузеры показывают пугающие предупреждения.

Проверка SSL:

  • SSL Labs — должна быть оценка не ниже A
  • htbridge.com — проверка на корректность настроек

Проверка на уязвимости

Обязательно проверьте сайт через:

Уязвимый сайт — это не только риск взлома, но и потенциальные санкции от Google.

11. Мобильная адаптация: большинство трафика с телефонов

Тест на мобилопригодность

Каждая страница вашего сайта должна проходить проверку:
search.google.com/test/mobile-friendly

Контент должен быть идентичным

Критическое правило для Google Mobile-First Index: контент на мобильной и десктопной версиях должен быть идентичен.

Это означает:

  • Все заголовки H1-H6
  • Мета-теги Title и Description
  • Основной текст
  • Изображения
  • Перелинковка между страницами
  • Микроразметка

На мобильной версии можно прятать контент под вкладки или спойлеры, но он должен быть в HTML-коде страницы (не через AJAX).

Запрещено: перманентно скрывать важные блоки контента на мобильной версии.

12. Требования к формированию URL

Что можно использовать в URL

До знака "?":

  • Латинские буквы (a-z)
  • Цифры (0-9)
  • Дефис (-)
  • Нижнее подчеркивание (_) — допустимо, но не рекомендуется

В GET-параметрах (после "?"):

  • Латинские буквы
  • Цифры
  • Дефис
  • Нижнее подчеркивание

Что недопустимо

  • Пробелы
  • Точки, запятые
  • Кавычки
  • Спецсимволы (#, %, &, кроме разделителей GET-параметров)
  • Юникод-символы (кириллица, эмодзи)

Все недопустимые символы заменяйте на дефис или удаляйте.

Стабильность URL

Критически важно: при изменении контента страницы (например, при смене названия товара) URL должен оставаться прежним. Менять адреса можно только в крайних случаях, с обязательной настройкой 301 редиректа.

13. Дополнительные технические требования

Структура заголовков H1-H6

  • H1 — только один на странице (основной заголовок)
  • H2-H6 — используются строго для оформления заголовков и подзаголовков контента
  • Заголовки не должны использоваться для меню или сквозных элементов

Внешние CSS и JavaScript

  • Стили выносятся в отдельные .css файлы
  • JavaScript выносится в .js файлы
  • Минимизируйте количество внешних файлов (объединяйте где возможно)
  • Избегайте inline-стилей

Кодировка

Используйте UTF-8 для всех страниц:

<meta charset="UTF-8">

Фреймы

Не используйте фреймы (

<frame>
, 
<iframe>
для построения структуры сайта) — это устаревшая технология, которая мешает индексации.

Редактирование мета-тегов

У вас должна быть возможность:

  • Редактировать Title, Description, Keywords, H1 для каждой страницы индивидуально
  • Настраивать шаблоны мета-тегов для страниц одного типа (например, всех товаров)

ALT для изображений

Все значимые изображения должны иметь атрибут alt с описанием:

<img src="product.jpg" 
  alt="Красный диван в интерьере гостиной" />

Внутренние ссылки

  • Все ссылки на другие страницы вашего сайта должны быть оформлены через 
    <a href="...">
  • Ссылки должны быть видны в HTML (не генерироваться только через JavaScript)
  • Избегайте 
    rel="nofollow"
    на внутренних ссылках

Страница 404

  • Должна отдавать HTTP-код 404 (не 200 или 302)
  • Должна быть оформлена в стиле сайта
  • Должна содержать навигацию и предложение вернуться на главную

Sitemap.xml

  • Лучше если будет генерироваться автоматически
  • Должен проходить валидацию
  • Должен содержать все основные страницы (разделы, товары, статьи)
  • Не должен содержать пагинацию, дубли, битые ссылки, страницы с noindex

Favicon

Должен быть расположен в корне сайта (/favicon.ico) и иметь размер минимум 32x32 пикселя.

Google Analytics

Установите счетчик Google Analytics (рекомендуем через Google Tag Manager) для отслеживания эффективности продвижения.

14. Требования к тестовой версии сайта

Если вы разрабатываете сайт, обязательно соблюдайте эти правила для тестовой версии:

  1. Размещение: только на поддомене основного сайта (test.site.com)
  2. Доступ: только после авторизации
  3. Meta robots: на каждой странице 
    <meta name="robots" content="noindex, nofollow" />
  4. X-Robots-Tag: в HTTP-заголовках добавить 
    X-Robots-Tag: noindex, nofollow

Это критически важно, чтобы Google не проиндексировал недоготовую версию сайта.

Часто задаваемые вопросы (FAQ)

1. Я настроил редирект с HTTP на HTTPS, но в Search Console вижу обе версии сайта как отдельные свойства. Означает ли это, что редирект не работает или Google просто ещё не обновил данные?

Это нормальная ситуация, которая часто вводит в заблуждение владельцев сайтов.

Google Search Console позволяет добавлять разные версии сайта как отдельные "ресурсы" (свойства) — HTTP, HTTPS, с www и без. Это не означает, что редирект не работает. Наличие обеих версий в Search Console — это просто способ увидеть статистику по старым URL, которые ещё могли быть проиндексированы.

Как проверить, работает ли редирект:

  1. Используйте инструмент проверки HTTP-заголовков (httpstatus.io)
  2. Введите http://site.com и убедитесь, что сервер возвращает код 301 (не 302) с редиректом на https://site.com
  3. В Search Console проверьте раздел "Покрытие" — HTTP-версия должна показывать ноль страниц в индексе через несколько недель после настройки редиректа

Что делать:

  • Если редирект работает правильно (код 301), просто подождите. Google постепенно переиндексирует все страницы на новую версию
  • Отправьте sitemap.xml только для HTTPS-версии
  • Используйте в Search Console функцию "Изменение адреса" (если переезжали с домена на домен)

Обычно полный переход занимает от 2 недель до 2 месяцев, в зависимости от размера сайта.

2. PageSpeed Insights даёт 48 баллов для мобильной версии из-за 'неиспользуемого JavaScript', но если я отключу эти скрипты, сломается функционал. Что важнее для ранжирования — скорость или работоспособность?

Это одна из самых частых дилемм при аудите сайтов.

Короткий ответ: работоспособность всегда важнее числа в PageSpeed Insights.

Длинное объяснение:

Google использует скорость как фактор ранжирования, но это не единственный и даже не главный фактор. Сайт с оценкой 48 баллов, но с отличным контентом и хорошим пользовательским опытом, будет ранжироваться лучше, чем сайт с 95 баллами, но бесполезным контентом.

Правильная стратегия:

  1. Не гонитесь за идеальным числом. Оценка 48 — это не катастрофа, особенно если она вызвана необходимым функционалом (корзина, калькулятор, формы). Стремитесь к 60-70 баллам — это уже хороший результат.
  2. Оптимизируйте, не ломая функционал:
    • Отложите загрузку неприоритетных скриптов через атрибут defer или async
    • Загружайте тяжелые библиотеки (карты, виджеты соцсетей) только когда пользователь доскроллит до них
    • Минифицируйте JS-файлы
    • Используйте tree-shaking для удаления неиспользуемых частей библиотек
  3. Фокусируйтесь на реальных метриках Core Web Vitals:
    • LCP (Largest Contentful Paint) — время загрузки основного контента (цель: < 2.5 сек)
    • INP (Interaction to Next Paint) — задержка после взаимодействия (цель: < 200 мс). Эта метрика официально заменила устаревший FID в марте 2024 года.
    • CLS (Cumulative Layout Shift) — стабильность визуальной загрузки (цель: < 0.1)

    Эти метрики важнее итогового балла PageSpeed.

Сайт с баллом 50-60, но быстрым LCP (2 секунды), ранжируется отлично. А сайт с баллом 90, но с LCP 5 секунд (из-за тяжелого слайдера на главной) — страдает в выдаче.

3. W3C валидатор показывает 200+ предупреждений, в основном из-за устаревших атрибутов в шаблоне CMS. Нужно ли переписывать весь код или Google смотрит только на критические ошибки типа незакрытых тегов?

Google смотрит не на валидность W3C, а на способность правильно распарсить страницу.

Критические ошибки (нужно исправлять):

  • Незакрытые теги (
    <div>
    без закрывающего 
    </div>
    )
  • Неправильная вложенность (например, 
    <p>
    внутри другого 
    <p>
    )
  • Дублирующиеся ID элементов
  • Неправильная структура таблиц
  • Отсутствие обязательных атрибутов (например, alt у важных изображений)

Эти ошибки мешают браузеру и поисковому роботу правильно понять структуру страницы.

Некритические предупреждения (можно оставить):

  • Устаревшие атрибуты (например, align, valign — работают, просто не рекомендуются)
  • Экспериментальные HTML5-элементы, не признанные W3C
  • Предупреждения о CSS-свойствах
  • Vendor-префиксы

Если у вас 200 предупреждений из-за устаревших атрибутов в шаблоне CMS (например, WordPress, Joomla с готовой темой), переписывать всё не обязательно.

Что делать:

  1. Проверьте наличие критических ошибок. В отчете W3C валидатора они обычно выделены красным.
  2. Исправьте критические ошибки (незакрытые теги, неправильная вложенность).
  3. Проверьте рендеринг в Search Console. Используйте инструмент "Проверка URL" — если Google корректно видит контент, значит всё в порядке.
  4. Не тратьте время на косметические предупреждения, если функционал работает.

Исключение: если вы создаёте сайт с нуля, сразу придерживайтесь современных стандартов — это упростит поддержку в будущем.

4. Текст на сайте подгружается через AJAX с задержкой 0,5 секунды для плавной анимации. В 'Проверке URL' Search Console текст отображается, но попадает ли он в индекс с тем же весом, что и контент в чистом HTML?

Официальная позиция Google: робот умеет выполнять JavaScript и индексировать динамический контент, но есть важные нюансы.

Реальность:

  1. Google имеет ограниченный таймаут на выполнение JS — обычно около 5 секунд. Ваша задержка в 0,5 сек укладывается, но:
    • Если на странице много скриптов, робот может не дождаться
    • Если задержка зависит от внешних факторов (медленный сервер, API), робот может не увидеть контент
  2. Двухфазная индексация. Google сначала индексирует HTML, а потом через некоторое время (часы/дни) возвращается для рендеринга JS. Если ваш контент критически важен для понимания темы страницы, задержка с индексацией может навредить.
  3. Вес контента. Если "Проверка URL" показывает текст, он попадёт в индекс. Однако нет официального подтверждения, что динамический контент имеет тот же вес, что и статический HTML. Мы считаем, что разница если и есть, то минимальная.

Наша рекомендация:

  • Критически важный контент (заголовки H1-H6, основной текст, первый экран) должен быть в чистом HTML.
  • Дополнительный контент (отзывы, комментарии, связанные статьи) можно подгружать через AJAX.
  • Если анимация важна для UX, оставьте её, но убедитесь, что контент всё равно присутствует в HTML в скрытом виде (например, 
    display: none
    с последующей анимацией появления).

Как проверить:

  1. Откройте страницу в режиме "Просмотр кода" (Ctrl+U в браузере)
  2. Найдите важный текст через поиск (Ctrl+F)
  3. Если текста нет в исходном HTML — значит он загружается через JS

Если текст подгружается через JS, и это критично для бизнеса, рассмотрите серверный рендеринг (SSR) или переделайте логику подгрузки.

5. У меня в блоге 500 статей, разбитых на 50 страниц пагинации. Google индексирует только первые 10 страниц. Это проблема краулингового бюджета или глубокие страницы пагинации вообще не должны попадать в индекс?

Это типичная ситуация для больших блогов и каталогов.

Проблема не в том, что Google не должен индексировать глубокие страницы пагинации, а в том, что у него может не хватить краулингового бюджета или мотивации это делать. В 2026 году Google еще реже сканирует глубокие страницы пагинации.

Что такое крауллинговый бюджет:

Это условное количество страниц, которое Google готов обходить на вашем сайте за определённый период. Для небольших сайтов (до 10 000 страниц) это обычно не проблема, но для крупных — может быть.

Почему Google останавливается на 10-й странице пагинации:

  1. Низкая ценность глубоких страниц. Google понимает, что большинство пользователей не доходят дальше 2-3 страницы, поэтому приоритет на индексацию получают первые страницы.
  2. Проблемы с краулингом. Проверьте:
    • Есть ли ссылки на глубокие страницы пагинации в HTML-коде (не генерируются ли они только через JS)
    • Не закрыты ли эти страницы в robots.txt
    • Отдают ли они код 200 (не 404, не 302)
  3. Отсутствие внутренней перелинковки. Если на страницы пагинации 40-50 нет ни одной ссылки, кроме как с 39-й страницы, Google может их не найти.

Решения:

  1. Добавьте все страницы пагинации в sitemap.xml — это даст сигнал Google, что они важны.
  2. Улучшите внутреннюю перелинковку:
    • Добавьте пагинатор с прыжками (1, 2, 3 ... 25, 26, 27 ... 48, 49, 50)
    • Создайте страницу "Архив статей" со ссылками на все страницы пагинации
    • Добавьте категории или теги, которые разделят 500 статей на меньшие группы
  3. Повысьте приоритет индексации:
    • Увеличьте скорость сайта (медленные сайты получают меньше краулингового бюджета)
    • Исправьте все ошибки 404, дубли, редиректы — они "съедают" крауллинговый бюджет
  4. Рассмотрите альтернативу классической пагинации:
    • Infinite scroll с правильной реализацией (URL для каждого состояния)
    • Более детальная категоризация статей

Важно: если индексируются первые 10 страниц, это уже 100 статей. Убедитесь, что остальные 400 статей не доступны через другие разделы сайта (категории, теги, поиск по сайту).

6. Canonical на всех страницах указывает правильно, но Search Console пишет 'Страница является дублем, выбрана другая страница'. Почему Google игнорирует мой canonical и можно ли это исправить?

Это одна из самых частых "болей" SEO-специалистов. Разберёмся, почему так происходит.

Важно понимать: canonical — это не директива, а рекомендация.

Google может игнорировать ваш canonical, если считает, что другая страница лучше подходит для индекса. Это называется "Google-selected canonical" (канонический URL, выбранный Google).

Причины, почему Google игнорирует ваш canonical:

  1. Страницы действительно дублируются.
    • Проверьте, идентичен ли контент на обеих страницах
    • Возможно, canonical указан неправильно (относительный вместо абсолютного URL)
    • Canonical может конфликтовать с другими сигналами (например, hreflang)
  2. Редиректы противоречат canonical.
    Если canonical указывает на страницу А, но есть редирект на страницу Б, Google запутается
  3. Внешние и внутренние ссылки ведут на другую версию.
    Если все ссылки на сайте ведут на /page/, а canonical указывает на /page, Google может выбрать /page/ как более популярную версию
  4. Sitemap.xml содержит неканоническую версию.
    Проверьте, что в sitemap.xml указаны только канонические URL
  5. Проблемы с мобильной версией.
    Если мобильная и десктопная версии сильно отличаются, Google может выбрать другую страницу как каноническую

Как исправить:

  1. Проверьте Search Console → Покрытие → "Исключено" → найдите конкретные URL с проблемой "Дубликат, выбрана другая каноническая страница".
  2. Сравните обе страницы (ту, что вы указали в canonical, и ту, что выбрал Google):
    • Идентичен ли контент?
    • Какая версия имеет больше внутренних ссылок?
    • Какая версия указана в sitemap.xml?
  3. Унифицируйте все сигналы:
    • Canonical должен указывать на нужную версию
    • Все внутренние ссылки должны вести на эту версию
    • В sitemap.xml должна быть только эта версия
    • Настройте 301 редирект со всех альтернативных версий
  4. Подождите. После исправления Google может переиндексировать страницы в течение 2-4 недель.

Когда не стоит беспокоиться:

Если Google выбрал в качестве канонической страницы ту версию, которая вам подходит (например, HTTPS вместо HTTP, без слеша вместо со слешем), и контент идентичен — проблемы нет. Просто Google принял решение за вас.

7. В robots.txt запретил индексацию директории /admin/, но в логах сервера вижу, что Googlebot всё равно обращается к этим URL. Это означает, что файл не работает или робот проверяет доступность даже запрещённых страниц?

Важное правило: robots.txt запрещает индексацию, но НЕ запрещает краулинг (обход).

Что это значит:

  • Индексация — это добавление страницы в базу данных Google с её содержимым.
  • Краулинг — это технический обход страницы ботом для проверки ссылок, редиректов и других сигналов.

Даже если страница закрыта в robots.txt:

  • Googlebot может обращаться к ней (вы увидите это в логах)
  • Google может проверять, не изменились ли правила в robots.txt
  • Googlebot может проверять редиректы с этой страницы

Но содержимое страницы не будет проиндексировано.

Проверьте правильность настройки robots.txt:

User-agent: *
Disallow: /admin/

Убедитесь:

  • Слеш в конце (/admin/) — закрывает всё, что начинается с /admin/
  • Файл доступен по адресу https://site.com/robots.txt
  • Нет синтаксических ошибок

Как проверить, работает ли robots.txt:

  1. Перейдите в Google Search Console → "Проверка URL"
  2. Введите любой URL из директории /admin/
  3. Нажмите "Проверить URL"
  4. Если видите сообщение "URL заблокирован файлом robots.txt" — всё работает правильно

Когда запрет НЕ работает:

Если на страницу /admin/page есть внешние ссылки с других сайтов, Google может добавить её в индекс даже без краулинга, показывая только URL без описания (это называется "мягкая индексация").

Решение для полной защиты:

Если действительно нужно полностью скрыть директорию:

  1. Закройте её в robots.txt (от индексации)
  2. Закройте паролем через .htaccess или конфигурацию сервера (от доступа)
  3. Добавьте на все страницы в директории 
    <meta name="robots" content="noindex, nofollow" />
    (двойная защита)

8. Мой sitemap содержит 8000 URL, но рекомендация — не больше 50 000. Стоит ли разбивать его на несколько файлов сейчас или только когда количество URL перевалит за определённый порог?

Официальные лимиты Google:

  • Максимум 50 000 URL в одном sitemap.xml
  • Максимальный размер файла — 50 МБ (несжатый)

При 8000 URL вы далеки от лимита, но есть нюансы.

Когда стоит разбивать sitemap уже сейчас:

  1. Разные типы контента.
    Если у вас:
    • 3000 страниц товаров
    • 2000 статей блога
    • 2000 категорий
    • 1000 служебных страниц
    Лучше создать отдельные sitemap для каждого типа: 
    • sitemap-products.xml
    • sitemap-blog.xml
    • sitemap-categories.xml
    Это упростит управление и отслеживание индексации в Search Console.
  2. Разная частота обновления.
    • Товары обновляются ежедневно → 
      sitemap-products.xml
      (часто отправлять в Google)
    • Статьи добавляются раз в неделю → 
      sitemap-blog.xml
    • Статические страницы не меняются → 
      sitemap-static.xml
  3. Размер файла близок к 10 МБ.
    Даже при 8000 URL, если каждый элемент содержит изображения (теги 
    <image:image>
    ), файл может быть тяжёлым.

Когда можно оставить один файл:

  • Если все 8000 URL примерно одного типа (например, только статьи блога)
  • Если сайт растёт медленно (100-200 страниц в год)
  • Если файл весит меньше 5 МБ

Как правильно разбивать:

Создайте индексный sitemap (

sitemap-index.xml
):
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex 
  xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://site.com/sitemap-products.xml</loc>
    <lastmod>2026-02-15</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://site.com/sitemap-blog.xml</loc>
    <lastmod>2026-02-14</lastmod>
  </sitemap>
</sitemapindex>

В Search Console отправляйте только индексный файл.

Наша рекомендация:

Если планируете активный рост сайта (более 20 000 URL в ближайший год), разбейте sitemap уже сейчас. Это упростит управление в будущем. Если сайт стабильный — можно оставить один файл и разбить, когда достигнете 15-20 тысяч URL.

9. Сайт адаптивный, но Google Search Console выдаёт ошибки 'Контент шире экрана' на некоторых страницах. Как найти конкретные элементы, которые вызывают эту проблему, если визуально всё выглядит нормально?

Частая "боль" при работе с мобильной версией.

Причины ошибки "Контент шире экрана":

  • Изображения с фиксированной шириной больше viewport
  • Таблицы без адаптивной обёртки
  • Блоки с width: 1000px или min-width больше экрана
  • Элементы с отрицательным margin или padding в пикселях
  • Встроенные видео или карты без responsive-обёртки

Как найти проблемный элемент:

Метод 1: Эмуляция мобильного устройства в браузере

  1. Откройте проблемную страницу в Chrome
  2. Нажмите F12 (Инструменты разработчика)
  3. Нажмите Ctrl+Shift+M (режим мобильного устройства)
  4. Выберите размер экрана "iPhone SE" (375px) или "Galaxy S8" (360px)
  5. Медленно прокрутите страницу сверху вниз
  6. Ищите горизонтальную прокрутку — это сигнал проблемного элемента

Метод 2: Автоматический поиск через DevTools

  1. В режиме мобильной эмуляции нажмите Ctrl+Shift+C
  2. Наведите мышкой на элементы — браузер покажет их размеры
  3. Ищите элементы шире 360-375px
  4. Проверьте CSS в правой панели — какое свойство задаёт ширину

Метод 3: JavaScript в консоли

Выполните этот скрипт в консоли браузера (F12 → Console):

let elements = document.querySelectorAll('*');
elements.forEach(el => {
  if (el.offsetWidth > window.innerWidth) {
    console.log('Элемент шире экрана:', el, 
      'Ширина:', el.offsetWidth);
    el.style.outline = '3px solid red';
  }
});

Это выделит красным все элементы, которые шире экрана.

Типичные решения:

Для изображений:

img {
  max-width: 100%;
  height: auto;
}

Для таблиц:

<div style="overflow-x: auto;">
  <table>...</table>
</div>

Для встроенных iframe (видео, карты):

<div style="position: relative; 
  padding-bottom: 56.25%; height: 0;">
  <iframe src="..." style="position: absolute; 
    top: 0; left: 0; width: 100%; height: 100%;">
  </iframe>
</div>

После исправления:

  1. Повторите проверку в режиме эмуляции
  2. Через 1-2 недели используйте в Search Console "Проверка URL" → запросите переиндексацию
  3. Ошибка должна исчезнуть из отчёта "Покрытие" через 2-4 недели

10. Я добавил разметку Product с ценой и рейтингом, но в результатах поиска звёздочки не появляются. Валидатор Schema.org показывает, что всё правильно. От чего зависит, покажет ли Google расширенный сниппет?

Важно понимать: валидная разметка ≠ гарантия отображения расширенного сниппета.

Google использует микроразметку как возможность показать rich snippet, но не обязан это делать.

Почему Google может не показывать расширенный сниппет:

  1. Страница недавно проиндексирована
    • Обычно нужно 2-4 недели после индексации для появления rich snippets
    • Google тестирует отображение постепенно
  2. Недостаточно данных в разметке

    Для товаров (Product) обязательные поля:

    • name — название товара
    • image — изображение
    • offers с полями:
      • price — цена
      • priceCurrency — валюта (GEL, USD)
      • availability — наличие

    Для отображения звёздочек дополнительно нужно:

    • aggregateRating — средний рейтинг
      • ratingValue — оценка (например, 4.5)
      • reviewCount — количество отзывов (минимум 1)
  3. Недостаточно отзывов

    Google может не показывать звёздочки, если:

    • Меньше 5 отзывов
    • Все отзывы с одинаковым рейтингом (выглядит подозрительно)
    • Отзывы добавлены слишком быстро (все за один день)
  4. Конкуренция за rich snippets

    Если по вашему запросу уже есть 2-3 результата с расширенными сниппетами, Google может не показать ваш, чтобы разнообразить выдачу.

  5. Спам или манипуляции

    Google может игнорировать разметку, если:

    • Рейтинг на странице и в разметке не совпадают
    • Отзывы явно фейковые
    • Разметка применена к странице, которая не является товаром (например, к главной)
  6. Региональные особенности

    Rich snippets могут отображаться в одном регионе и не отображаться в другом. Проверяйте выдачу именно из вашего целевого региона (используйте VPN или параметр 

    &gl=XX
    в поиске).

Как повысить шансы на отображение:

  1. Убедитесь в корректности разметки:
    Используйте Rich Results Test (новая версия валидатора)
  2. Добавьте реальные отзывы:
    • Минимум 5-10 отзывов
    • С разными датами
    • С разными оценками (4-5 звёзд преимущественно, но и 3 звезды тоже должны быть)
  3. Проверьте соответствие разметки и визуала:
    • Если в разметке указано 4.8 звезды, на странице должен быть виджет с таким же рейтингом
    • Цена в разметке = цена на странице
  4. Запросите переиндексацию:
    Search Console → Проверка URL → "Запросить индексирование"
  5. Подождите 4-6 недель после всех исправлений.

Как проверить, видит ли Google разметку:

Search Console → "Улучшения" → "Товары"
Здесь будут показаны все страницы с разметкой Product и возможные ошибки.

11. На сайте три языка: грузинский (основной), русский и английский. Нужно ли в hreflang добавлять тег x-default и на какую языковую версию он должен указывать — на грузинскую или создавать отдельную страницу выбора языка?

Всё максимально просто. x-default — это страница, которую Google покажет любому пользователю, чей язык вы не предусмотрели в настройках.

Выбор конкретного языка для этого атрибута зависит только от того, кто ваш основной клиент:

1. Выбирайте АНГЛИЙСКИЙ в x-default, если:

Ваш сайт ориентирован на весь мир.

  • Логика: Английский — международный язык. Если на сайт зайдет швед, китаец или турок, им будет проще понять английский, чем любой другой локальный язык.
  • Кому подходит: Отели, экспортные компании, IT-сервисы, международные блоги.

2. Выбирайте ГРУЗИНСКИЙ (местный) в x-default, если:

Ваш бизнес привязан к конкретной стране.

  • Логика: Ваша услуга оказывается только в Грузии. Если иностранец ищет что-то внутри страны, он должен видеть «оригинальную» версию сайта с актуальными местными данными, даже если он не знает языка (браузер предложит ему авто-перевод).
  • Кому подходит: Доставка еды по городу, локальные юридические услуги, государственные сервисы, чисто местный интернет-магазин.

3. Выбирайте РУССКИЙ в x-default, если:

Ваша аудитория — страны СНГ.

  • Логика: Если вы продаете товары, например, на Казахстан, Армению и Узбекистан, но у вас нет версий на этих национальных языках, то русский будет лучшим «общим знаменателем» для этого региона.
  • Кому подходит: Оптовая торговля в рамках СНГ, региональные медиа-ресурсы.

Как решить за 5 секунд?

Задайте себе вопрос: «На каком языке говорит мой "случайный" посетитель, языка которого я не предусмотрел?»

  • Если это «человек мира» — ставьте английский.
  • Если это «человек, который сейчас находится в моей стране» — ставьте местный язык.

Техническое правило: В x-default всегда подставляйте ссылку на ту версию, которая уже существует в вашем списке hreflang.

  • Если решили, что дефолтным будет английский — в x-default вписывайте адрес английской страницы.
  • Если грузинский — адрес грузинской.

Дополнительные советы:

  1. Автоопределение языка браузера:
    Используйте JavaScript для автоматического редиректа на нужную версию при первом визите (но не показывайте страницу выбора каждый раз).
  2. Переключатель языков на всех страницах:
    В шапке сайта должны быть флажки/кнопки для смены языка, видимые на всех страницах.
  3. Проверка hreflang:
    Используйте Hreflang Tags Testing Tool для проверки корректности настройки.
  4. Search Console:
    Проверьте раздел "Международное таргетирование" — там будут показаны ошибки hreflang, если они есть.

Ошибки, которых следует избегать:

  • Не создавайте замкнутые круги: ka ссылается только на ka, ru только на ru — все версии должны ссылаться друг на друга
  • Не забывайте про self-referencing — каждая страница ссылается на саму себя
  • Убедитесь, что все URL в hreflang доступны (отдают код 200, не 404 и не 301)

12. Alt-атрибуты добавлены ко всем изображениям, но Google Images не показывает мои фотографии в поиске по картинкам. Это проблема оптимизации изображений (размер, формат) или недостаточно времени прошло с момента индексации?

Поиск по картинкам Google Images — это отдельная система с собственными правилами. Разберём все факторы.

Время индексации:

Для появления в Google Images обычно нужно:

  • 2-4 недели для нового сайта
  • 1-2 недели для существующего сайта с хорошей репутацией

Если прошло меньше месяца, подождите.

Факторы ранжирования в Google Images:

  1. Качество и оптимизация изображения
    • Формат: JPEG для фотографий, PNG для графики, WebP для современных сайтов
    • Размер: Минимум 300x300 пикселей (лучше 800x600+)
    • Вес: Не больше 200 КБ (оптимизируйте через TinyPNG)
    • Название файла: krasnyi-divan.jpg, а не IMG_12345.jpg
  2. Alt-атрибут (правильный)

    Недостаточно просто добавить alt — он должен быть описательным и уникальным:

    ❌ Плохо: 

    alt="Изображение"

    ❌ Плохо: 
    alt="Товар"

    ✅ Хорошо: 
    alt="Красный кожаный диван в скандинавском стиле"
  3. Контекст вокруг изображения

    Google смотрит на:

    • Заголовок страницы (H1)
    • Текст вокруг изображения (в радиусе 50-100 слов)
    • Подпись под изображением (
      <figcaption>
      если используется 
      <figure>
      )

    Если изображение дивана находится на странице о столах, Google запутается.

  4. Техническая доступность
    • Изображение не должно быть закрыто в robots.txt
    • Страница с изображением должна быть проиндексирована
    • Изображение должно загружаться без ошибок (не 404)
    • Путь к изображению должен быть в HTML (не только через CSS background-image)
  5. Структурированные данные (необязательно, но помогает)

    Для товаров добавьте микроразметку с изображением в формате JSON-LD.

Как проверить индексацию изображений:

  1. Поиск по URL:
    В Google Images введите:
    site:site.com/images/

    Это покажет все проиндексированные изображения с вашего сайта.
  2. Search Console:
    К сожалению, Search Console не показывает статистику по изображениям напрямую, но можно проверить индексацию страниц, на которых они размещены.
  3. Google Lens:
    Загрузите ваше изображение в Google Lens — если Google его распознал, вы увидите похожие результаты.

Типичные проблемы:

  • Lazy Load неправильно настроен — Google не видит изображения, загружаемые через JS
  • Изображения дублируются — одна и та же картинка на 10 страницах сайта
  • Низкое качество — размытые, мелкие изображения не индексируются
  • Отсутствие sitemap для изображений — создайте отдельный image-sitemap.xml

Что делать:

  1. Оптимизируйте изображения (размер, вес, названия файлов)
  2. Улучшите alt-атрибуты (уникальные, описательные)
  3. Добавьте контекст вокруг изображений (текст, заголовки)
  4. Создайте image sitemap
  5. Подождите 4-6 недель
  6. Проверьте через site:site.com/images/ в Google Images

13. Search Console подключён, но показывает 'Данные обрабатываются' уже неделю. Нормально ли такое время ожидания для нового сайта или есть ошибка в настройке подтверждения прав собственности?

Не волнуйтесь — для нового сайта это абсолютно нормальная ситуация.

Типичные сроки появления данных в Search Console:

  • Для нового сайта (домену меньше 3 месяцев): 7-14 дней
  • Для существующего сайта с переподключением: 2-3 дня
  • Для сайта после редизайна: 3-5 дней

Почему так долго:

Google должен:

  1. Обнаружить ваш сайт (через sitemap или ссылки с других сайтов)
  2. Обойти основные страницы
  3. Проиндексировать контент
  4. Накопить статистику по показам и кликам

Для нового сайта, у которого ещё нет позиций в поиске, процесс идёт медленнее.

Как проверить, что всё настроено правильно:

  1. Подтверждение прав собственности

    Перейдите в Search Console → Настройки → "Подтверждение прав собственности"
    Должен быть зелёный чекбокс с датой подтверждения.

    Если нет — переподтвердите права одним из способов:

    • HTML-файл
    • HTML-тег в 
      <head>
    • Google Analytics (если счётчик уже установлен)
    • Google Tag Manager
  2. Sitemap отправлен и обрабатывается

    Раздел "Sitemap" → введите URL вашего sitemap.xml → "Отправить"
    Статус должен быть "Успешно" (может появиться через 1-3 дня после отправки)

  3. Проверка индексации отдельных страниц

    Используйте инструмент "Проверка URL":

    • Введите главную страницу https://site.com/
    • Нажмите "Проверить URL"
    • Если страница проиндексирована, увидите "URL есть в индексе Google"

    Если страниц ещё нет в индексе, нажмите "Запросить индексирование" для ускорения процесса.

  4. Проверьте robots.txt

    Убедитесь, что вы случайно не закрыли весь сайт от индексации:

    Откройте https://site.com/robots.txt

    Проверьте, нет ли строки:

    User-agent: *
Disallow: /

    Это закрывает весь сайт. Правильный вариант:

    User-agent: *
Allow: /
Sitemap: https://site.com/sitemap.xml

Что делать, если через 2 недели данных всё ещё нет:

  1. Проверьте индексацию через поиск:
    Введите в Google: site:site.com
    Если показывается хотя бы главная страница — сайт в индексе, данные появятся в Search Console позже.
  2. Проверьте ошибки покрытия:
    Search Console → "Покрытие" → если страниц ноль, смотрите вкладку "Исключено" — там будут причины.
  3. Ускорьте процесс:
    • Отправьте 5-10 основных страниц через "Запросить индексирование"
    • Создайте несколько качественных внешних ссылок на сайт (профили в соцсетях, каталоги компаний)
    • Убедитесь, что у вас качественный, уникальный контент (не скопированный с других сайтов)

Когда действительно стоит беспокоиться:

Если через 3-4 недели:

  • В поиске site:site.com не показывается ни одной страницы
  • В разделе "Покрытие" Search Console ноль страниц
  • Все запросы индексирования игнорируются

Тогда проверьте:

  • Не наложены ли санкции на домен (купили домен с плохой историей)
  • Не дублируете ли вы контент с другого вашего сайта
  • Не используется ли агрессивный noindex на всех страницах

14. Тестовая версия на поддомене test.site.com закрыта через Basic Auth, но в логах вижу попытки доступа от Googlebot. Может ли робот каким-то образом обойти парольную защиту или это попытки сканирования, которые блокируются?

Googlebot НЕ может обойти Basic Auth.

Basic Authentication (HTTP-авторизация) — это надёжный метод защиты, который работает на уровне веб-сервера. Googlebot получит код ответа 401 Unauthorized и не сможет получить доступ к контенту.

Что вы видите в логах:

Это попытки доступа, которые блокируются сервером. Вот что происходит:

  1. Googlebot обращается к URL: GET https://test.site.com/page
  2. Сервер проверяет авторизацию → не находит → возвращает код 401
  3. Googlebot получает 401 и уходит (не видит содержимое страницы)
  4. В логах сервера остаётся запись о попытке доступа

Почему Googlebot вообще пытается обратиться к тестовой версии:

  1. Ссылки с основного сайта

    Если где-то на основном сайте (site.com) есть ссылка на тестовую версию:

    <a href="https://test.site.com/page">
  Test page
</a>

    Googlebot найдёт её и попытается обойти.

    Решение: проверьте основной сайт на наличие ссылок на test. поддомен.

  2. Sitemap.xml основного сайта

    Если в sitemap основного сайта указаны URL тестовой версии — удалите их.

  3. DNS-записи доступны публично

    Даже если сайт закрыт паролем, DNS-записи test.site.com видны всем. Googlebot может периодически проверять поддомены известных доменов.

  4. Внешние ссылки

    Если кто-то случайно дал ссылку на тестовую версию с другого сайта, Googlebot попытается её обойти.

Как убедиться, что тестовая версия защищена:

  1. Проверьте код ответа

    Откройте в браузере режим инкогнито (чтобы не использовались сохранённые пароли) и перейдите на https://test.site.com/

    Вы должны увидеть окно ввода логина/пароля. В DevTools (F12 → Network) проверьте код ответа — должен быть 401.

  2. Проверьте Google Search Console

    Если у вас добавлен поддомен test.site.com как отдельное свойство в Search Console, проверьте раздел "Покрытие":

    • Должно быть 0 проиндексированных страниц
    • Все страницы должны быть в разделе "Исключено" с причиной "Заблокировано авторизацией"
  3. Проверьте через поиск

    Введите в Google:

    site:test.site.com

    Если показывается хотя бы одна страница — значит защита неправильно настроена.

Дополнительные меры защиты:

Если хотите полностью исключить попытки Googlebot обратиться к тестовой версии:

  1. Robots.txt на поддомене:

    Создайте файл 

    https://test.site.com/robots.txt
    : 
    User-agent: *
Disallow: /
  2. Мета-теги на всех страницах: 
    <meta name="robots" 
  content="noindex, nofollow">
  3. X-Robots-Tag в HTTP-заголовках:

    Настройте сервер (Apache/.htaccess или Nginx) чтобы он отдавал:

    X-Robots-Tag: noindex, nofollow
  4. Закройте по IP Whitelist:

    Если возможно, дополнительно ограничьте доступ только для конкретных IP-адресов вашей команды.

Вывод:

Попытки доступа Googlebot к тестовой версии — это нормально и не страшно, если настроена Basic Auth. Робот получает 401 и уходит, не видя контента. Но для полной уверенности добавьте robots.txt и noindex как дополнительный слой защиты.

Заключение: техническое SEO — это инвестиция, которая работает годами

Техническая оптимизация сайта может показаться сложной и трудоемкой, но это тот фундамент, который закладывается один раз и работает на вас постоянно. В отличие от контекстной рекламы, где вы платите за каждый клик, правильно настроенный сайт привлекает органический трафик из Googleзначительно дешевле и месяц за месяцем.

Мы рекомендуем внедрять эти требования на этапе разработки сайта — исправление ошибок постфактум обходится в 3-5 раз дороже. Если ваш сайт уже работает, проведите технический аудит, чтобы выявить и устранить критические проблемы.

Узнайте, какие технические ошибки мешают вашему сайту быть на первой странице Google

Закажите технический SEO-аудит у нас:

  • ✅ Найдём все дубли за 48 часов
  • ✅ Настроим редиректы и canonical
  • ✅ Поможем внедрить hreflang для .ge доменов

От 500 лари за 100 страниц | Окупаемость 1.5-3 месяца

Contact us today: