Как убрать дубли WordPress из-за HTTP и HTTPS

Если один и тот же сайт открывается и по http://, и по https://, поисковик может считать это двумя разными версиями страниц. Для WordPress это типичная причина дублей: главная, записи, рубрики и даже изображения доступны по двум протоколам, а в индексе появляются лишние URL. Решается это не одной галочкой, а связкой из редиректа на один протокол, правильного адреса сайта в WordPress и корректных канонических ссылок.

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

Что именно нужно исправить

Проблема возникает, когда:

• сайт открывается по http://example.com и по https://example.com без принудительного перенаправления;
• внутренние ссылки в шаблоне или контенте ведут на разные протоколы;
• в WordPress в настройках указан один адрес, а фактически сайт работает на другом;
• канонический URL в HTML указывает не на ту версию страницы;
• внешние ссылки, карта сайта или кэш отдают смешанные адреса.

Для поисковика это не «одна страница с разными способами открытия», а несколько URL с одинаковым содержимым. В лучшем случае он выберет одну версию сам. В худшем — начнет индексировать обе, а сигналы ранжирования будут размазываться между дублями.

Сначала проверьте, какая версия должна быть основной

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

Проверять нужно не только главную страницу, но и несколько типовых URL: запись, рубрику, страницу с пагинацией, изображение из медиатеки. Если редирект настроен только на главную, а внутренние страницы продолжают открываться по HTTP, дубль останется.

Настройте редирект с HTTP на HTTPS на уровне сервера

Это основной шаг. Редирект должен срабатывать до загрузки WordPress, иначе вы получите лишнюю нагрузку и риск циклов перенаправления. Способ зависит от веб-сервера.

Если сайт работает на Apache

Обычно редирект добавляют в файл .htaccess в корне сайта. Перед изменением сделайте резервную копию: ошибка в этом файле может уронить сайт или создать бесконечный редирект.

Для принудительного перехода на HTTPS можно использовать такой вариант:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Если сайт работает на поддомене с отдельным сертификатом или за прокси, условия могут отличаться. В некоторых конфигурациях Apache видит HTTPS не напрямую, а через заголовки прокси, и тогда правило нужно адаптировать под окружение хостинга.

Если сайт работает на Nginx

Редирект обычно настраивают в конфигурации виртуального хоста. Пример для отдельного сервера, который должен отдавать только HTTPS:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Если у вас есть и www, и без www, лучше сразу выбрать одну каноническую форму домена и редиректить на нее вместе с переходом на HTTPS. Иначе можно получить цепочку из двух редиректов: сначала с HTTP на HTTPS, потом с www на без www, или наоборот.

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

Проверьте настройки WordPress

В админке откройте Настройки → Общие и убедитесь, что оба адреса сайта указаны с HTTPS:

• Адрес WordPress (URL);
• Адрес сайта (URL).

Оба значения должны совпадать по протоколу и, как правило, по домену. Если один адрес остался на HTTP, WordPress может генерировать смешанные ссылки, а часть страниц будет отдавать старые URL в меню, хлебных крошках и шаблонах.

Если доступ в админку уже потерян из-за неверного адреса, правку можно сделать через wp-config.php. Это рабочий способ, но использовать его стоит аккуратно: после фиксации адресов в файле они перестают редактироваться из админки.

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

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

Убедитесь, что канонический URL указывает на HTTPS

Даже при правильном редиректе поисковику полезно явно показать основную версию страницы через тег rel="canonical". В WordPress многие SEO-плагины и сама тема формируют его автоматически. На странице должен быть один канонический адрес, и он должен вести на HTTPS-версию.

Проверить это можно в исходном коде страницы или через инструменты для анализа URL. Ищите строку вида:

<link rel="canonical" href="https://example.com/stranica/" />

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

Проверьте внутренние ссылки и карту сайта

Редирект решает проблему входа на старый URL, но не убирает сам источник дублей. Если в контенте, меню, виджетах или шаблонах остались ссылки на HTTP, поисковый робот будет постоянно натыкаться на них.

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

• ссылки в записях и страницах;
• логотип и кнопки в шапке;
• ссылки в подвале;
• URL в XML-карте сайта;
• адреса изображений, если они вставлялись вручную;
• ссылки в старых шаблонах и пользовательских полях.

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

Как быстро проверить, что дубли действительно убраны

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

Для проверки с консоли можно использовать curl:

curl -I http://example.com/stranica/
curl -I https://example.com/stranica/

В первом случае вы должны увидеть 301 и заголовок Location с HTTPS-адресом. Во втором — ответ 200 без дальнейших перенаправлений. Если HTTP-версия тоже отдает 200, редирект не работает. Если HTTPS-версия тоже редиректит, значит есть лишняя цепочка или ошибка в настройке домена.

Дополнительно проверьте:

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

Что делать, если дубли остались после редиректа

Если редирект уже есть, а дубли все равно видны, обычно причина одна из трех:

• канонический тег не обновился и указывает на HTTP;
• внутренние ссылки продолжают вести на старый протокол;
• поисковик еще не переобошел старые URL и держит их в индексе по инерции.

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

Иногда мешает кэш: серверный, плагина или CDN. После изменения протокола очистите все уровни кэширования, иначе часть пользователей и роботов может еще какое-то время видеть старые ответы.

Короткий порядок действий, если нужно сделать все без лишних кругов

1. Выберите основную версию сайта — обычно https://.
2. Настройте постоянный редирект 301 с HTTP на HTTPS на уровне сервера.
3. Проверьте оба адреса в настройках WordPress.
4. Убедитесь, что canonical на страницах указывает на HTTPS.
5. Исправьте внутренние ссылки, меню, карту сайта и старые URL в контенте.
6. Очистите кэш и проверьте несколько страниц через curl или браузер.

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