Руководства/Руководство по индексации CMS

Индексация WordPress в Google: полное руководство по тому, как добиться появления каждой страницы в поиске

На WordPress работает свыше 40% сайтов в интернете, однако у тысяч сайтов на этой CMS есть страницы, которые Google так и не находит. Это руководство проведёт Вас через каждую настройку, конфигурацию плагина и серверный параметр, необходимые для полной и быстрой индексации Вашего контента на WordPress.

Обновлено: 1 апр. 2026 г.

На WordPress работает свыше 40% сайтов в интернете, но его гибкость создаёт десятки мест, где индексация может сломаться. Случайно отмеченная галочка в разделе «Настройки → Чтение» способна скрыть весь Ваш сайт. Неправильная конфигурация SEO-плагина может незаметно добавить директивы noindex. Плохо написанная тема может внедрить дублирующиеся canonical-теги, которые сбивают Googlebot с толку.

Это руководство — пошаговый разбор каждой точки конфигурации WordPress, влияющей на индексацию: базовые настройки, карты сайта Yoast и Rank Math, структуры постоянных ссылок, правила .htaccess и эндпоинты REST API. Независимо от того, ведёте ли Вы блог или магазин на WooCommerce, описанные шаги применимы.

IndexBolt добивается, чтобы Google просканировал Ваши URL менее чем за 24 часа — без ручных отправок и недель ожидания.

Как Google сканирует сайты на WordPress

Google обнаруживает страницы WordPress через три основных канала:

  • Ваша XML-карта сайта — основной механизм обнаружения
  • Внутренние ссылки на Вашем сайте, по которым переходит Googlebot
  • Внешние обратные ссылки, ведущие на Ваши страницы с других сайтов

Начиная с версии 5.5 WordPress генерирует встроенную карту сайта по адресу /wp-sitemap.xml, однако большинство владельцев сайтов используют карту, созданную плагином, так как это даёт больше контроля над тем, какие типы записей, таксономии и архивы в неё включены.

Попадая на сайт WordPress, Googlebot сначала проверяет robots.txt в корне домена. WordPress генерирует виртуальный robots.txt через PHP-функцию, а не отдаёт статический файл, что позволяет плагинам и функциям темы изменять его программно. Стандартный robots.txt в WordPress разрешает доступ всем краулерам и указывает на карту сайта, однако плагины безопасности часто добавляют ограничивающие правила, блокирующие доступ к /wp-admin/, /wp-includes/, а иногда и к /wp-content/uploads/ — папке, где хранятся все Ваши медиафайлы.

Прочитав robots.txt, Googlebot начинает обход страниц. WordPress отдаёт в целом хорошо структурированный HTML, но важен сам конвейер рендеринга. Если Ваша тема активно использует JavaScript для разметки (характерно для конструкторов страниц, таких как Elementor, Divi или WPBakery), Google вынужден делать второй проход рендеринга. Эта двухэтапная индексация — сначала «сырой» HTML, затем JavaScript-версия — может задержать полную индексацию на дни и даже недели. Страницы, собранные в стандартном блочном редакторе Gutenberg, рендерятся на сервере и полностью лишены этой задержки.

WordPress также раскрывает контент через REST API по адресу /wp-json/wp/v2/. Хотя Googlebot обычно не сканирует эндпоинты REST API для индексации, на плохо настроенных сайтах URL REST API иногда попадают в карту сайта или внутренние ссылки, что вносит путаницу в очередь сканирования Google.

Браузер с открытым /robots.txt на сайте WordPress, на котором показаны стандартные правила User-agent и Disallow
WordPress генерирует виртуальный robots.txt, который плагины и темы могут изменять программно

Базовые настройки WordPress, влияющие на индексацию

Самая важная настройка индексации в WordPress находится по адресу Настройки → Чтение. Галочка с подписью «Попросить поисковые системы не индексировать сайт» добавляет тег <meta name="robots" content="noindex, nofollow"> на каждую страницу и модифицирует robots.txt, включая в него Disallow: /. Эта настройка предназначена для разработки и staging-окружений, но в продакшне её оставляют включённой чаще, чем можно подумать. Любой аудит индексации WordPress должен начинаться именно отсюда.

Структура постоянных ссылок, настраиваемая в Настройки → Постоянные ссылки, определяет формат URL для каждой записи и страницы. Стандартная структура использует простые query-строки вида /?p=123, которые сканируются, но не дают Google никаких ключевых сигналов. Рекомендуемая структура для большинства сайтов — «Название записи» (/%postname%/), создающая чистые, читаемые URL. Если Вы меняете структуру постоянных ссылок на уже существующем сайте, WordPress не создаёт автоматических редиректов для старых URL. Каждый ранее проиндексированный URL вернёт 404, если только Вы не добавите правила редиректа в .htaccess или не воспользуетесь плагином вроде Redirection.

Настройки адреса сайта в Настройки → Общие тоже важны. Если адрес WordPress и адрес сайта не совпадают, или если один использует www, а другой — нет, Google видит две разные версии каждого URL. WordPress обрабатывает редирект www↔без-www с помощью правил RewriteRule в .htaccess, но ошибки в настройках приводят к циклам редиректов, полностью блокирующим сканирование.

WordPress также рассылает XML-RPC-пингбэки при публикации нового контента. Хотя система XML-RPC по адресу /xmlrpc.php в значительной мере считается устаревшей в пользу REST API, в разделе Настройки → Написание есть список «сервисов уведомлений», управляющий тем, какие сервисы получают оповещения. Добавление в этот список эндпоинта пинга карт сайта Google больше не имеет эффекта, так как Google отказался от пинга карт сайта в 2023 году, однако многие устаревшие руководства всё ещё рекомендуют это делать.

Страница «Настройки → Чтение» в WordPress с галочкой «Попросить поисковые системы не индексировать сайт»
Самая распространённая ошибка индексации в WordPress — эта галочка добавляет noindex-тег на весь сайт

Забудьте о ручной работе — IndexBolt отправляет Ваши URL прямо в очередь сканирования Google. Начните со 100 бесплатных кредитов.

100 бесплатных кредитов. Без банковской карты.

Настройка SEO-плагинов: Yoast SEO и Rank Math

Yoast SEO и Rank Math — два самых популярных SEO-плагина для WordPress, и оба дают широкие возможности управления индексацией. Они генерируют XML-карты сайта, управляют директивами meta robots, задают канонические URL и определяют, как Ваш контент отображается в результатах поиска.

Yoast SEO создаёт карту сайта по адресу /sitemap_index.xml — это индекс карт, ссылающийся на отдельные карты для записей, страниц, рубрик, меток, архивов авторов и пользовательских типов записей. Управлять тем, какие типы контента в неё попадают, можно через Yoast → Настройки → Типы контента и Yoast → Настройки → Рубрики и метки. У каждого типа контента есть переключатель «Показывать в результатах поиска» — его отключение добавляет директиву noindex ко всему типу контента и удаляет его из карты сайта. Это главная причина случайной деиндексации в WordPress.

Rank Math использует похожий подход, но с более гибким интерфейсом. Настройки карты сайта находятся в Rank Math → Настройки карты сайта, где у каждого типа записей и таксономии есть собственная вкладка. У Rank Math также есть отдельная вкладка «Расширенные» в редакторе записей, где можно установить для отдельных страниц noindex, nofollow или noarchive. Распространённая ошибка — поставить странице noindex на этапе разработки и забыть снять его перед публикацией.

Оба плагина автоматически задают канонические URL. Конфликты канонических URL возникают, когда:

  • Оба плагина активны одновременно — никогда не запускайте два SEO-плагина одновременно
  • Плагин кеширования отдаёт устаревшую версию страницы с устаревшим canonical-тегом

Карта сайта, создаваемая этими плагинами, заменяет встроенную карту WordPress. Если активны и встроенная карта (/wp-sitemap.xml), и плагинная (/sitemap_index.xml), Google может обнаружить обе и впустую потратить бюджет сканирования на обработку дублирующихся записей. И Yoast, и Rank Math автоматически отключают встроенную карту сайта, но отключение SEO-плагина без удаления его конфигурации может снова включить встроенную карту, оставив при этом «осиротевшие» URL карт сайта в Google Search Console.

Файл .htaccess и серверный контроль индексации

Файл .htaccess в корневой папке WordPress — один из самых мощных и наименее понятных файлов, влияющих на индексацию. WordPress пишет в него собственные правила перезаписи для обработки постоянных ссылок, но плагины, хостинг-провайдеры и ручные правки могут добавлять правила, блокирующие краулеров или создающие цепочки редиректов.

Стандартный блок .htaccess в WordPress проверяет, существует ли запрошенный файл или каталог, и если нет, направляет запрос на index.php, чтобы его обработал WordPress. Плагины безопасности вроде Wordfence, Sucuri и iThemes Security добавляют свои правила над блоком WordPress. Эти правила иногда включают блокировку по IP, ограничение частоты запросов или фильтрацию по User-Agent, что может непреднамеренно блокировать Googlebot. Если у Вашего плагина безопасности есть функция «блокировать подозрительные User-Agent», убедитесь, что строка User-Agent Googlebot явно внесена в белый список.

Хостинг-провайдеры также модифицируют .htaccess. Управляемые хостинги для WordPress, такие как WP Engine, Kinsta и Flywheel, добавляют заголовки кеширования, правила сжатия GZIP, а иногда и правила редиректа для CDN. Обычно с этим всё в порядке, но если хостинг принудительно переводит на HTTPS через .htaccess, а в настройках WordPress всё ещё указаны HTTP-URL, Вы получаете цепочку редиректов:

  1. 1HTTP → HTTPS (через .htaccess)
  2. 2Нормализация www↔без-www (через WordPress)

Каждый редирект в цепочке тратит бюджет сканирования и увеличивает задержку.

Чтобы провести аудит .htaccess, скачайте его через SFTP или файловый менеджер хостинга и просмотрите каждый блок правил. Ищите:

  • Правила Deny from all, способные блокировать целые каталоги
  • Шаблоны RewriteRule, перенаправляющие User-Agent краулеров
  • Директивы Header set X-Robots-Tag, добавляющие noindex на уровне сервера

Заголовок X-Robots-Tag особенно коварен, так как не отображается в исходном коде страницы — увидеть его можно только в заголовках HTTP-ответа с помощью curl или инструментов разработчика в браузере.

Конфликты плагинов и проблемы темы, блокирующие индексацию

Архитектура плагинов WordPress означает, что любой установленный плагин может изменять HTTP-заголовки, внедрять мета-теги, модифицировать robots.txt или менять карту сайта. Наиболее распространённые конфликты, ломающие индексацию, связаны с:

Плагинами кеширования (WP Rocket, W3 Total Cache, LiteSpeed Cache), отдающими устаревший HTML, содержащий неактуальные теги meta robots или канонические URL. Когда Вы меняете страницу с noindex на index, кешированная версия может продолжать отдавать noindex-тег, пока кеш не будет очищен. После любых SEO-изменений всегда полностью очищайте кеш страниц.

Плагинами членства и платного доступа (MemberPress, Restrict Content Pro, WooCommerce Memberships), оборачивающими контент в проверки авторизации. Если плагин скрывает контент за входом в систему, не предоставляя альтернативу для анонимных посетителей, Googlebot видит либо форму входа, либо пустой контент. У некоторых плагинов членства есть опция «Показывать отрывок поисковым системам» — включите её, чтобы Google мог проиндексировать осмысленный сниппет.

Плагинами-конструкторами страниц — они хранят контент в собственных форматах базы данных, которые стандартная функция WordPress the_content() не выводит. Elementor хранит данные макета как мета-поля записи и рендерит их через JavaScript. Если CSS- и JS-файлы Elementor заблокированы в robots.txt, Google не может отрендерить страницу и индексирует пустой макет. То же касается Divi, Beaver Builder и WPBakery. Воспользуйтесь инструментом «Проверка URL» в Google Search Console и нажмите «Просмотреть просканированную страницу», чтобы увидеть, что именно рендерит Googlebot.

Темы также могут мешать. Некоторые темы включают собственные SEO-функции — поля для meta description, Open Graph-теги или даже генераторы карт сайта, конфликтующие с Вашим SEO-плагином. Сгенерированные темой мета-теги могут создавать дублирующиеся title и description в HTML-заголовке. Просмотрите исходный код страницы и поищите дубликаты <meta name="description"> или <meta name="robots">. Если Ваша тема добавляет свои, отключите эту функцию в настройках темы или смените тему.

REST API WordPress и оптимизация бюджета сканирования

REST API WordPress отдаёт Ваш контент по эндпоинтам /wp-json/wp/v2/posts, /wp-json/wp/v2/pages и подобным. Хотя они не предназначены для поисковых систем, иногда они попадают в индекс Google, если на них ссылаются Ваша карта сайта, JavaScript темы или внешние источники. Ответы REST API возвращают JSON, а не HTML, поэтому проиндексированные URL API отображаются в поиске как необработанные данные.

Чтобы предотвратить индексацию URL REST API, добавьте заголовок X-Robots-Tag: noindex к ответам REST API. Это можно сделать небольшим фрагментом кода в functions.php Вашей темы или в собственном плагине. Некоторые SEO-плагины делают это автоматически, но проверьте, посетив URL REST API и просмотрев заголовки ответа.

Бюджет сканирования — реальная проблема для крупных сайтов на WordPress. Если у Вас тысячи записей плюс архивы меток, рубрик, дат, авторов и постраничные версии всех этих архивов, Google приходится сканировать десятки тысяч URL. У многих архивных страниц тонкий контент. Установите следующее значение noindex в настройках SEO-плагина:

  • Архивы меток — часто содержат лишь 1–2 записи
  • Архивы по датам — месяцы, в которых Вы опубликовали одну запись
  • Архивы авторов — не нужны на блогах с одним автором

Это сосредотачивает бюджет сканирования на Вашем настоящем контенте.

WordPress генерирует URL фидов по адресам /feed/, /comments/feed/, а также по отдельным фидам для рубрик и меток. Это валидные механизмы обнаружения, и они должны оставаться сканируемыми, но не должны индексироваться. Большинство SEO-плагинов по умолчанию добавляют noindex к ответам фидов. Проверьте, посетив /feed/ и убедившись в наличии директивы noindex в XML-заголовке.

Наконец, обратите внимание на время отклика сайта. WordPress на shared-хостинге с большим количеством активных плагинов часто имеет Time to First Byte (TTFB) 2–4 секунды. Googlebot воспринимает медленный отклик как сигнал перегрузки сервера и снижает частоту сканирования. Используйте серверное кеширование (объектный кеш Redis или Memcached, кеш страниц от хостинг-провайдера), чтобы добиться TTFB ниже 500 мс. Только это способно существенно увеличить количество страниц, которые Google сканирует за день.

Пошаговое руководство

1

Убедитесь, что галочка «Попросить поисковые системы…» снята

Войдите в админку WordPress и перейдите в Настройки → Чтение. Прокрутите вниз до раздела «Видимость для поисковых систем».

Галочка «Попросить поисковые системы не индексировать сайт» на продакшн-сайтах должна быть снята. Если она установлена, снимите её и нажмите «Сохранить изменения».

Эта единственная галочка управляет общесайтовой директивой noindex, полностью блокирующей индексацию любой страницы. После снятия галочки откройте исходный код страницы и убедитесь, что тег <meta name="robots" content="noindex, nofollow"> больше не появляется в секции <head>.

Страница «Настройки → Чтение» в WordPress с выделенным разделом «Видимость для поисковых систем»
Перейдите в «Настройки → Чтение» и убедитесь, что эта галочка снята
2

Настройте карту сайта и параметры индексации SEO-плагина

Yoast SEO: перейдите в Настройки → Типы контента и включите «Показывать в результатах поиска» для записей и страниц. В разделе «Рубрики и метки» оставьте рубрики индексируемыми, но рассмотрите вариант с noindex для меток.

Rank Math: перейдите в «Настройки карты сайта» и включите каждый тип записей. В «Заголовки и мета» убедитесь, что ни у одного типа контента в Robots Meta не выставлено noindex.

Откройте /sitemap_index.xml в браузере и подтвердите, что он загружается как валидный XML со ссылками на Ваш контент.

Yoast SEO «Настройки → Типы контента» с переключателем «Показывать в результатах поиска» для записей
Убедитесь, что у каждого типа контента в SEO-плагине включён параметр «Показывать в результатах поиска»
3

Задайте оптимальную структуру постоянных ссылок и настройте редиректы

Перейдите в Настройки → Постоянные ссылки и выберите вариант «Название записи» в качестве структуры постоянных ссылок. Так Вы получите URL вида yourdomain.com/your-post-title/ — чистые, насыщенные ключевыми словами и понятные Google.

Если Вы переходите с другой структуры на существующем сайте:

  1. 1Установите плагин Redirection до внесения изменений
  2. 2Смените структуру постоянных ссылок и сохраните
  3. 3Плагин Redirection автоматически зафиксирует ошибки 404 со старых URL
  4. 4Настройте правила редиректа со старых шаблонов на новые

Например, если Ваша старая структура была /%year%/%monthnum%/%postname%/, создайте регулярный редирект с ^/\d{4}/\d{2}/(.+)$ на /$1, чтобы сохранить ссылочный вес.

Страница «Настройки → Постоянные ссылки» в WordPress с выбранным вариантом «Название записи»
Выберите «Название записи» для чистых URL с ключевыми словами, легко читаемых Google
4

Проверьте robots.txt и .htaccess на наличие блокировок краулеров

Откройте yourdomain.com/robots.txt и убедитесь, что там нет правила Disallow: / и что URL карты сайта указан с директивой Sitemap:.

Скачайте .htaccess через SFTP и проверьте наличие правил блокировки User-Agent, ограничений по IP, затрагивающих диапазон Google 66.249.x.x, и заголовков X-Robots-Tag от плагинов безопасности. Если Вы нашли подозрительные правила, отключайте плагины безопасности по одному, чтобы выявить источник.

5

Отправьте карту сайта в Google Search Console

Войдите в Google Search Console и выберите свой ресурс WordPress. Перейдите в «Файлы Sitemap» в левой боковой панели и введите URL карты сайта:

  • /sitemap_index.xml, если Вы используете Yoast или Rank Math
  • /wp-sitemap.xml, если используете встроенную карту WordPress

Нажмите «Отправить». Google начнёт обработку карты сайта — обычно первоначальное чтение занимает 24–48 часов.

После отправки следите за отчётом «Файлы Sitemap» на предмет распространённых ошибок:

  • URL, возвращающие 404 (удалённые записи всё ещё в карте сайта)
  • URL, заблокированные robots.txt
  • URL с цепочками редиректов

Отчёт «Страницы» покажет, сколько отправленных URL проиндексировано, исключено или содержит ошибки.

6

Проверьте рендеринг страницы через «Проверку URL»

В Google Search Console используйте «Проверку URL» для самых важных страниц. Нажмите «Проверить опубликованный URL» и убедитесь, что HTTP-ответ — 200, статус индексации показывает, что URL можно индексировать, а скриншот рендеринга в «Просмотреть просканированную страницу» соответствует тому, что Вы видите в браузере.

Если отрендеренная страница показывает отсутствующий контент или пустые секции, у Вас проблема с JavaScript-рендерингом из-за заблокированных ресурсов или конфликтов конструктора страниц.

7

Ускорьте индексацию оставшихся страниц с помощью IndexBolt

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

Используйте IndexBolt, чтобы отправить эти URL напрямую на индексацию:

  1. 1Экспортируйте URL из карты сайта (найдите их в sitemap_index.xml, нажав на каждую вложенную карту)
  2. 2Вставьте их в форму отправки IndexBolt
  3. 3Позвольте нашему API провести их через конвейер индексации Google

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

Закончили ручные шаги? Ускорьте процесс.

IndexBolt отправляет Ваши URL прямо в Google — большинство сканируется менее чем за 24 часа.

Частые проблемы и способы их решения

Галочка «Попросить поисковые системы…» по-прежнему установлена

Причина: Эта галочка в «Настройки → Чтение» была включена во время разработки или миграции сайта и так и не была отключена. Некоторые хостинг-провайдеры включают её по умолчанию на staging-окружениях, и она сохраняется при переносе на продакшн. Автоматические установщики WordPress из панелей хостинга также иногда оставляют её включённой.

Решение: 1. Перейдите в **«Настройки → Чтение»**, снимите галочку **«Попросить поисковые системы не индексировать сайт»** и нажмите **«Сохранить изменения»** 2. Откройте исходный код главной страницы и убедитесь, что мета-тег **noindex** исчез 3. Проверьте `robots.txt` (`yourdomain.com/robots.txt`) и убедитесь, что в нём больше нет `Disallow: /` 4. **Очистите кеш всех плагинов кеширования** после этого изменения, чтобы обновлённый HTML сразу же стал отдаваться

SEO-плагин закрывает от индексации целый тип записей или таксономию

Причина: В Yoast SEO переключатель «Показывать в результатах поиска» в «Настройки → Типы контента» был выключен для типа записей. В Rank Math параметр Robots Meta для типа контента был установлен в noindex в «Заголовки и мета». Это добавляет директиву noindex к каждой странице данного типа и удаляет их из карты сайта, даже если у отдельных записей ценный контент.

Решение: Откройте настройки SEO-плагина и проверьте каждый тип записей и каждую таксономию. - **Yoast:** перейдите в **«Настройки → Типы контента»** и включите **«Показывать в результатах поиска»** для каждого типа, который должен индексироваться - **Rank Math:** перейдите в **«Заголовки и мета → Типы записей»** и установите Robots Meta в значение **«index»** После изменений перегенерируйте карту сайта, посетив её в браузере и убедившись, что затронутые URL теперь появились. **Повторно отправьте карту сайта** в Google Search Console.

Смена структуры постоянных ссылок привела к массовым ошибкам 404

Причина: Изменение структуры постоянных ссылок в «Настройки → Постоянные ссылки» обновляет все внутренние ссылки, но не создаёт редиректов со старых шаблонов URL. Любые внешние ссылки, закладки и ранее проиндексированные URL, указывающие на старую структуру, теперь возвращают 404. Со временем Google деиндексирует эти страницы.

Решение: 1. Установите плагин **Redirection** (или используйте `.htaccess` напрямую), чтобы создать **301-редиректы по шаблонам** со старой структуры URL на новую 2. Если Ваша старая структура была `/%category%/%postname%/`, создайте сопоставление со старых URL на новую структуру `/%postname%/` 3. Отслеживайте **ошибки 404** в отчёте «Страницы» Google Search Console 4. Добавляйте индивидуальные редиректы для URL, которые не покрыло правило по шаблону Со временем Google обновит свой индекс в соответствии с новой структурой URL.

Несколько плагинов генерируют конфликтующие карты сайта

Причина: Одновременное использование двух SEO-плагинов (например, Yoast и Rank Math) или наличие SEO-плагина вместе с отдельным плагином карты сайта вроде Google XML Sitemaps создаёт несколько файлов карт сайта. Если robots.txt или Google Search Console ссылаются на обе карты, Google обрабатывает дублирующиеся записи URL и может счесть их подозрительными. Некоторые комплексные плагины безопасности, такие как All In One WP Security, также генерируют собственные карты сайта.

Решение: **Используйте только один плагин для генерации карты сайта.** Если Вы используете Yoast или Rank Math, отключите или удалите все отдельные плагины карты сайта. 1. Проверьте `robots.txt` на наличие нескольких строк `Sitemap:` и удалите дубликаты 2. В Google Search Console перейдите в **«Файлы Sitemap»** и удалите все устаревшие или дублирующиеся отправки 3. Убедитесь, что встроенная карта сайта WordPress по адресу `/wp-sitemap.xml` отключена Вашим SEO-плагином (Yoast и Rank Math оба делают это автоматически при работе)

Плагин кеширования отдаёт устаревшие страницы с noindex

Причина: Вы изменили страницу с noindex на index (или исправили проблему с мета-тегом), но Ваш плагин кеширования (WP Rocket, W3 Total Cache, LiteSpeed Cache и другие) по-прежнему отдаёт старый кешированный HTML с директивой noindex. Кеш страниц может сохраняться часами или днями в зависимости от настроек.

Решение: **Полностью очищайте кеш страниц** после любого SEO-изменения: - **WP Rocket:** «Настройки → WP Rocket → «Очистить кеш» - **W3 Total Cache:** «Производительность → Панель → «Очистить все кеши» - **LiteSpeed Cache:** «LiteSpeed Cache → Toolbox → «Очистить всё» Если Вы используете CDN, например **Cloudflare**, также очистите кеш CDN в панели Cloudflare. После очистки проверьте, открыв страницу в **окне инкогнито** и просмотрев исходный код, что нужные мета-теги присутствуют.

Тяжёлая тема и конструктор страниц замедляют скорость сканирования

Причина: Сложные темы WordPress с большими CSS/JS-бандлами и конструкторы вроде Elementor или Divi значительно увеличивают время загрузки страницы. Когда Time to First Byte превышает 2 секунды, Googlebot снижает скорость сканирования, чтобы не перегружать сервер. На shared-хостинге это может уменьшить дневной объём сканирования с сотен страниц до нескольких десятков.

Решение: Включите **серверное кеширование** для улучшения времени отклика: 1. Установите плагин кеширования и настройте **полностраничное кеширование** 2. Используйте **объектный кеш** (**Redis** или **Memcached**), если Ваш хостинг это поддерживает 3. **Минифицируйте и объединяйте** CSS/JS-файлы средствами плагина кеширования 4. Рассмотрите переход на управляемый хостинг WordPress (**WP Engine**, **Kinsta**, **Cloudways**), включающий серверное кеширование и CDN Проверяйте скорость сканирования в Google Search Console в разделе **«Настройки → Статистика сканирования»**, где видны дневные запросы сканирования, объём загрузки и время ответа.

Советы профи

Запустите обход в Screaming Frog перед изменениями, чтобы зафиксировать исходное состояние всех meta robots и canonical-тегов.
Установите noindex для страниц корзины, оформления заказа, личного кабинета и /shop/ в WooCommerce, чтобы избежать тонких дублирующихся URL.
Установите Query Monitor, чтобы выявить скрытые заголовки X-Robots-Tag, которые плагины добавляют на уровне сервера.
Проверьте галочку видимости для поисковых систем на каждом подсайте мультисетевой инсталляции WordPress.
Экспортируйте URL из sitemap_index.xml Вашего SEO-плагина при отправке в IndexBolt для точности.

На сайтах WordPress могут быть сотни или тысячи страниц, ожидающих, пока Google их обнаружит. IndexBolt позволяет отправить URL Вашего WordPress-сайта на индексацию напрямую, минуя ожидание следующего обхода Googlebot. Только что устранили проблему с noindex или опубликовали серию новых записей? Добавьте их в индекс Google за часы, а не за недели.

100 бесплатных кредитов. Без банковской карты. Результаты менее чем за 24 часа.

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

Сколько времени нужно Google, чтобы проиндексировать новую страницу на WordPress?+

Для **устоявшихся сайтов WordPress** с хорошей частотой сканирования новые страницы обычно появляются в Google в течение **2–7 дней** после публикации. Для **новых сайтов** или сайтов с низким авторитетом домена это может занять **2–6 недель**. Если Ваша страница не проиндексирована через 4 недели, скорее всего, есть техническая проблема, блокирующая сканирование или индексацию. Использование **IndexBolt** может сократить срок до **часов** для срочных страниц.

Использовать встроенную карту сайта WordPress или карту SEO-плагина?+

Используйте **карту сайта SEO-плагина**, если у Вас установлен Yoast SEO или Rank Math. Эти плагины генерируют более полные карты сайта с лучшим контролем над тем, какие типы контента включены, и **автоматически отключают встроенную карту**, чтобы избежать дубликатов. Встроенной карты сайта WordPress по адресу `/wp-sitemap.xml` достаточно для простых сайтов без SEO-плагина, но в ней нет тех гибких настроек, которые предоставляют Yoast и Rank Math.

Может ли в моей карте сайта WordPress быть слишком много страниц?+

В одном файле карты сайта может быть до **50 000 URL** согласно спецификации протокола sitemap. И Yoast, и Rank Math разбивают большие карты сайта на подкарты по **1 000 URL** в каждой (с возможностью настройки). Реальная проблема — не размер карты сайта, а **качество URL** в ней. Если в карте тысячи тонких архивных страниц, страниц меток с одной записью или постраничных URL, **бюджет сканирования** Google тратится на малоценные страницы. Поддерживайте карту сайта компактной, **закрывая от индексации тонкие типы контента**.

Влияет ли смена темы WordPress на мои позиции в Google?+

Смена темы может **существенно повлиять на индексацию и ранжирование**. Новая тема может: - Изменить **структуру страницы** и **иерархию заголовков** - Модифицировать **схему внутренних ссылок** - Добавить или удалить **структурированные данные** - Внести изменения в поведение **JavaScript-рендеринга** Если новая тема медленнее или активно использует JavaScript, Google может сканировать и индексировать Ваши страницы менее эффективно. **Всегда тестируйте смену темы сначала на staging-сайте** и внимательно следите за отчётом «Страницы» в Google Search Console после переключения.

Почему страницы меток WordPress отображаются как «Обнаружена, не проиндексирована»?+

Google часто классифицирует страницы архивов меток как **малоценные**, потому что они содержат те же отрывки записей, которые встречаются и на других архивных страницах (страницах рубрик, авторов, главной странице блога). Когда Google определяет, что страница не добавляет уникальной ценности, он обнаруживает URL, но **решает не индексировать его**. Лучшая практика — **закрыть от индексации архивы меток** в настройках SEO-плагина, если только у Ваших меток нет существенного уникального содержания. Это фактически помогает Вашим важным страницам индексироваться быстрее за счёт **концентрации бюджета сканирования**.

Мой сайт WordPress использует конструктор страниц. Это влияет на индексацию?+

Конструкторы страниц вроде **Elementor**, **Divi** и **WPBakery** хранят контент в собственном формате и рендерят его через JavaScript на стороне клиента. Google умеет рендерить JavaScript, но делает это в **отложенном втором проходе**, из-за чего страницы, собранные конструктором, могут индексироваться полностью дольше. Что ещё критичнее, если Ваш `robots.txt` блокирует CSS- или JS-файлы конструктора (некоторые плагины безопасности так делают), Google **не сможет отрендерить страницу вовсе** и проиндексирует пустой макет. Проверяйте инструментом **«Проверка URL»** в Google Search Console, что Google видит полностью отрендеренную страницу.

Готовы проиндексировать свои URL?

Начните со 100 бесплатных кредитов. Без банковской карты.