Что делать, если страницы WordPress индексируются только в HTTP

Что такое индексация страниц в HTTP и её значение для WordPress

Под индексацией страниц в HTTP понимают ситуацию, когда поисковая система обходит, анализирует и добавляет в базу URL с протоколом http://, а не https://. Для WordPress это особенно важно, потому что CMS автоматически формирует множество технических сигналов: абсолютные ссылки, canonical, sitemap, Open Graph, внутренние переходы и ответы сервера. Если хотя бы часть этих сигналов указывает на другую версию протокола, поисковик может выбрать её как основную.

Почему это критично: WordPress сам по себе не решает вопрос каноничности между HTTP и HTTPS. Он лишь использует настройки адресов сайта и поведение плагинов. В результате управление индексацией WordPress превращается не в одну галочку, а в набор согласованных настроек.

С точки зрения SEO поисковики стремятся выбрать одну предпочтительную версию URL. Если этого не сделать явно, часть документов может индексироваться по HTTP, часть по HTTPS, а часть будет выпадать из индекса как дубли. В узнайте как правильно настроить все сигналы сразу — это и есть основа устойчивой индексации.

• HTTP и HTTPS для поисковика — это разные URL.
• WordPress передаёт сигналы о каноничности через тему, плагины и настройки URL.
• Непоследовательность в протоколах почти всегда ведёт к дублям.
• Даже при небольшом сайте ошибка может затронуть категории, пагинацию, медиа и записи.

Проблемы с индексацией HTTP-страниц в WordPress и их причины

На практике проблема редко сводится к одному фактору. Обычно индексация страниц только в http wordpress ломается из-за комбинации причин: сервер отвечает по двум протоколам, плагин SEO генерирует canonical на HTTPS, а карта сайта содержит смешанные адреса. В этой статье я покажу, почему важно искать не симптом, а первоисточник конфликта.

Чаще всего HTTPS-версии появляются в индексе, когда поисковик получает хотя бы один сильный сигнал в их пользу. Это может быть 200 OK для HTTPS, ссылки из меню, внешние бэклинки, автогенерация sitemap или HSTS на стороне сервера. Поисковые системы учитывают канонические URL HTTP, но если другие сигналы им противоречат, canonical может быть проигнорирован. Google прямо указывает, что canonical — это рекомендация, а не жёсткая директива, см. Google Search Central.

Для Яндекса проблема дублей тоже критична: робот может исключать часть страниц как повторяющиеся или выбирать не ту версию адреса, что влияет на представление сайта в поиске. Базовые принципы обхода и диагностики описаны в справке Яндекс Вебмастера.

Настройка файла robots.txt для исключения HTTPS и разрешения HTTP

С robots.txt важно понимать главное: он управляет обходом, а не гарантированным удалением URL из индекса. Поэтому robots txt в WordPress нужно использовать как вспомогательный инструмент, а не как единственный способ исключение HTTPS из индекса. Если ваша цель — разрешить индексацию HTTP-версий и не тратить краулинговый бюджет на лишние разделы, файл должен быть аккуратным и не конфликтовать с noindex и редиректами.

Технически robots.txt не умеет блокировать URL по протоколу отдельно, потому что файл действует в рамках конкретного хоста и схемы доступа к сайту. На практике robots.txt для HTTP сайта должен разрешать нужные разделы, а HTTPS-версию лучше убирать через редиректы и каноникал. Проверять синтаксис удобно через генератор robots.txt и проверку robots.txt.

Базовый пример robots.txt для WordPress на HTTP:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Sitemap: http://example.com/sitemap_index.xml

Если HTTPS-версия сайта доступна и не редиректит на HTTP, сам по себе такой файл проблему не решит. Но он важен как часть общей схемы: карта сайта должна содержать только HTTP-адреса, а технические разделы не должны мешать обходу полезных страниц.

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

1. Откройте robots.txt по HTTP и убедитесь, что сервер отдаёт код 200.
2. Проверьте, что в строке Sitemap указан только HTTP-адрес карты сайта.
3. Убедитесь, что нет случайного Disallow: /, оставшегося после разработки.
4. Сверьте, не блокируются ли CSS и JS, если тема WordPress зависит от них для рендеринга.
5. Проверьте файл в Яндекс Вебмастере и вручную протестируйте URL на обход.

Использование мета-тега noindex для управления индексацией страниц

Мета-тег noindex — один из самых точных способов показать поисковику, что конкретную страницу не нужно держать в индексе. Для сценария, когда HTTP должен остаться основной версией, noindex полезен на HTTPS-страницах, если они временно доступны и пока не переведены на 301-редирект. Это особенно актуально для сложных конфигураций WordPress, где часть URL генерируется плагинами, CDN или нестандартными шаблонами.

В WordPress мета-тег noindex чаще всего задаётся через SEO-плагины или условия в шаблоне. Важно, чтобы робот мог открыть страницу и увидеть этот тег. Если URL одновременно закрыт в robots.txt, директива noindex может не быть считана.

Пример мета-тега:

<meta name="robots" content="noindex, follow">

Условный пример для шаблона, если нужно пометить HTTPS-версию:

<?php if (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off') : ?>
<meta name="robots" content="noindex, follow">
<?php endif; ?>

Такой способ требует аккуратности: если сайт находится за прокси или CDN, переменная HTTPS может определяться иначе. Поэтому после внедрения обязательно проверяйте исходный код страницы и HTTP-заголовки.

• Используйте noindex для HTTPS-версий, если они ещё доступны пользователям.
• Не ставьте noindex на HTTP-страницы, которые должны ранжироваться.
• Не комбинируйте noindex с запретом обхода одной и той же страницы.
• После изменений запрашивайте переобход в вебмастерах.

Проверка и корректировка канонических URL для HTTP-версии сайта

Canonical — это один из ключевых сигналов для поисковика, когда на сайте есть дубли по протоколу. Если WordPress или SEO-плагин указывает canonical на HTTPS, а вы хотите индексировать только HTTP, поисковая система с высокой вероятностью выберет именно HTTPS как основную версию. Поэтому канонические URL HTTP нужно проверять не точечно, а по шаблонам: главная, записи, рубрики, теги, пагинация, страницы вложений.

В этой статье я приведу простой принцип: canonical должен совпадать с фактической индексируемой версией URL, а все внутренние сигналы должны его поддерживать. Проверять это удобно массово через проверку canonical или в рамках SEO-аудита сайта.

Корректный пример canonical для HTTP:

<link rel="canonical" href="http://example.com/category/post/">

Типичные ошибки:

• canonical на HTTPS при открытой HTTP-версии в меню и sitemap;
• относительный canonical без схемы, если тема или плагин формируют URL нестабильно;
• каноникал на главную вместо самоссылочного canonical на документ;
• разные canonical для desktop и mobile-версий без необходимости.

Настройка редиректов и исключение дублирующего контента

Если цель — оставить в индексе только HTTP, самым сильным техническим сигналом обычно становится 301-редирект с HTTPS на HTTP. Да, в 2026 это нестандартный сценарий, потому что большинство сайтов, наоборот, переводят трафик на HTTPS. Но если проект по внутренним ограничениям работает на HTTP, редирект должен быть настроен жёстко и без промежуточных цепочек. Именно редиректы HTTP HTTPS чаще всего определяют, какая версия будет признана главной.

Для Apache это можно сделать в .htaccess, для Nginx — в server block. Важно, чтобы редирект срабатывал на любой URL, а не только на главной странице.

Пример 301-редиректа для Apache:

RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]

Пример для Nginx:

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    return 301 http://example.com$request_uri;
}

После внедрения проверьте, что нет цепочки вида HTTPS → www HTTPS → HTTP или HTTPS → HTTP → slash-редирект. Каждое лишнее звено замедляет обход и ослабляет предсказуемость сигналов.

Проверка индексации в Яндекс Вебмастере и Google Search Console

После технических правок нельзя ограничиваться только просмотром исходного кода. Нужно убедиться, какую версию URL реально видит и выбирает поисковик. Для этого используйте проверка индексации Яндекс и аналогичный анализ в Google Search Console. В Яндекс Вебмастере смотрите статус страниц, обход роботом и диагностические сообщения; в Google Search Console — URL Inspection, Coverage и выбранный canonical.

Яндекс публикует общие рекомендации по диагностике обхода и индексирования в разделе помощи Яндекс Вебмастера, а Google — в Search Central. Для WordPress это особенно полезно после смены протокола, потому что поисковик может ещё некоторое время хранить старую версию в индексе.

Что проверять в первую очередь:

• Какой URL поисковик считает каноническим: HTTP или HTTPS.
• Есть ли в индексе страницы, которых уже не должно быть.
• Какой код ответа получает робот на HTTPS-страницах.
• Совпадает ли sitemap с выбранной схемой URL.
• Нет ли внутренних ссылок на неосновной протокол.

Порядок действий после исправлений:

1. Проверьте 5–10 типовых URL: главную, запись, рубрику, пагинацию, страницу вложения.
2. Запросите переобход ключевых страниц.
3. Обновите sitemap и отправьте её заново.
4. Через 1–3 недели сравните, как меняется число исключённых дублей.

Рекомендации по плагинам для управления индексацией в WordPress

Плагины упрощают управление индексацией WordPress, но именно они часто создают конфликт сигналов. Один плагин формирует canonical, другой — sitemap, третий добавляет noindex к архивам, а четвёртый принудительно переписывает ссылки на HTTPS. Поэтому выбирать нужно не по популярности, а по предсказуемости поведения и совместимости с вашей темой.

В узнайте как правильно подходить к выбору: чем меньше пересекающихся функций, тем лучше. Если SEO-плагин уже управляет canonical и мета-тегами, не стоит дублировать это отдельным модулем безопасности или оптимизации.

На что смотреть при выборе плагина:

• Можно ли задавать noindex для отдельных типов страниц.
• Как генерируется sitemap и можно ли принудительно оставить только HTTP URL.
• Есть ли фильтры или хуки для кастомного canonical.
• Не включает ли плагин автоматическое перенаправление на HTTPS.
• Совместим ли он с кешированием, CDN и вашим серверным стеком.

Практический подход:

1. Оставьте один основной SEO-плагин для canonical, noindex и sitemap.
2. Отключите дублирующие функции в других плагинах.
3. После каждого изменения проверяйте исходный код и XML-карту сайта.
4. Если есть кастомная логика, фиксируйте её в дочерней теме или mu-plugin, а не вручную в шаблоне родительской темы.

Если нужно быстро проверить технические сигналы после изменений, полезно пройтись по набору инструментов в инструментах Analito: отдельно проверить canonical, редиректы, robots.txt и карту сайта. Это снижает риск, что одна правка в плагине сломает другую часть SEO-конфигурации.

Заключение

Чтобы оставить в поиске только HTTP-страницы WordPress, недостаточно одной настройки. Нужна связка из правильных адресов сайта, canonical на HTTP, sitemap с HTTP URL, 301-редиректов с HTTPS на HTTP и аккуратного использования noindex там, где HTTPS уже успел попасть в индекс. Если хотя бы один из этих сигналов противоречит остальным, поисковик выберет свою версию — и обычно это заканчивается дублями и просадкой качества индексации.

Начните с проверки трёх вещей: какой canonical видит робот, что находится в sitemap и какой код ответа отдаёт HTTPS-версия. Затем проверьте весь сайт целиком, а не только главную страницу: Проверьте индексацию вашего сайта с помощью analito.ru и сразу увидите, где именно ломается логика индексации и какие ошибки стоит исправить в первую очередь.

Частые вопросы

Почему поисковые системы индексируют HTTPS-страницы вместо HTTP в WordPress?

Обычно это происходит потому, что поисковик получает более сильные сигналы в пользу HTTPS: код ответа 200, canonical на HTTPS, ссылки в sitemap или внутренние переходы из меню и шаблонов. Даже если в настройках WordPress указан HTTP, один SEO-плагин или серверное правило может переопределить поведение. Проверьте canonical, XML-карту сайта, редиректы и исходный код нескольких типов страниц, а не только главной.

Как правильно настроить robots.txt для индексации только HTTP-версии сайта?

Файл robots.txt должен разрешать обход нужных HTTP-разделов и указывать sitemap только с HTTP-адресами. Но важно помнить: robots.txt не удаляет URL из индекса, если они уже известны поисковику. Поэтому для HTTPS-страниц сначала используйте 301-редирект или noindex, а robots.txt применяйте как дополнительный инструмент управления обходом.

Можно ли использовать плагины для управления индексацией HTTP-страниц?

Да, но только если вы точно понимаете, какой плагин отвечает за canonical, sitemap и мета-теги robots. На WordPress частая проблема — дублирование функций несколькими расширениями, из-за чего один модуль ставит noindex, а другой продолжает продвигать HTTPS через canonical. Лучший подход — оставить один основной SEO-плагин и после каждой правки проверять фактический HTML и ответы сервера.

Как проверить, какие страницы индексируются поисковиками — HTTP или HTTPS?

Используйте Яндекс Вебмастер и Google Search Console: там можно посмотреть, какой URL выбран каноническим и находится ли страница в индексе. Дополнительно полезно делать выборочную проверку оператором site:, но полагаться только на него не стоит, потому что он показывает неполную картину. Для практики возьмите 10–20 URL разных типов и сравните их статус, canonical, код ответа и наличие в sitemap.

Источники

• Яндекс Вебмастер: помощь — общие принципы обхода, диагностики и индексирования страниц.
• Google Search Central — подтверждает роль canonical, индексирования и обработки дублей.
• MDN Web Docs — справочная база по мета-тегам, HTTP и базовым веб-стандартам.