Как перевести сайт на HTTPS: SSL, 301 и mixed content

Что нужно сделать для перехода сайта на HTTPS

Чтобы правильно перевести работающий сайт с HTTP на HTTPS, недостаточно просто установить SSL-сертификат. После установки сертификата нужно проверить настройки CMS, заменить внутренние HTTP-ссылки, устранить mixed content, настроить постоянный редирект с HTTP на HTTPS и обновить SEO-сигналы сайта.

Правильная последовательность выглядит примерно так:

Создать резервную копию сайта и базы данных.
Получить SSL/TLS-сертификат.
Установить сертификат на сервере или включить его в панели хостинга.
Проверить работу сайта непосредственно по HTTPS.
Изменить основной адрес сайта в CMS, если это требуется.
Заменить внутренние абсолютные URL с HTTP на HTTPS.
Исправить mixed content.
Обновить canonical и другие URL в HTML.
Обновить sitemap.xml.
Проверить robots.txt.
Настроить постоянный редирект HTTP → HTTPS.
Проверить коды ответа и отсутствие циклических редиректов.
Проверить сайт в поисковых системах и сервисах аналитики.
Только после полной проверки рассматривать включение HSTS.

Важно. Не начинайте с принудительного редиректа и тем более HSTS. Сначала HTTPS-версия сайта должна полностью работать сама по себе. Иначе можно перенаправить всех посетителей на неисправную версию сайта.

Что такое HTTPS и SSL-сертификат

HTTPS — это HTTP, работающий через защищённое TLS-соединение. Оно шифрует обмен данными между браузером посетителя и сервером сайта.

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

В разговорной речи такие сертификаты до сих пор обычно называют SSL-сертификатами, хотя современные сайты используют TLS.

Шаг 1. Сделайте резервную копию

Перед изменением URL работающего сайта сохраните:

файлы сайта;
базу данных;
текущую конфигурацию веб-сервера;
файл .htaccess, если используется Apache или совместимый сервер;
файлы конфигурации CMS;
при возможности — настройки DNS и панели хостинга.

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

Для работающего коммерческого сайта. Желательно выполнять переход в период минимальной посещаемости и заранее иметь понятный способ отката.

Шаг 2. Выберите SSL-сертификат

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

Бесплатный сертификат Let's Encrypt

Для обычного сайта, блога, интернет-магазина или корпоративного сайта чаще всего достаточно бесплатного сертификата Let's Encrypt.

Let's Encrypt — бесплатный автоматизированный удостоверяющий центр. На обычном виртуальном хостинге выпуск и продление сертификата часто автоматизирует сам провайдер.

На собственном VPS сертификат можно получать через ACME-клиент, например Certbot или другой поддерживаемый сервером инструмент.

На момент подготовки статьи стандартные сертификаты Let's Encrypt обычно выдаются на 90 дней, поэтому нормальная схема эксплуатации предполагает автоматическое продление.

Wildcard-сертификат

Wildcard используется, когда одним сертификатом нужно покрыть множество поддоменов:

*.example.com

Например:

shop.example.com
blog.example.com
mail.example.com

При этом wildcard для *.example.com сам по себе не означает автоматическое покрытие корневого example.com: это имя также должно присутствовать в сертификате.

Коммерческий сертификат

Хостеры и удостоверяющие центры могут предлагать платные сертификаты с различными условиями выпуска, поддержки и проверки владельца.

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

Что выбрать новичку. Если хостинг предлагает автоматический Let's Encrypt для вашего домена и автоматически его продлевает, обычно это самый простой вариант.

Шаг 3. Установите сертификат

На виртуальном хостинге это часто делается в панели управления.

Раздел может называться:

SSL;
SSL/TLS;
HTTPS;
Сертификаты;
Let's Encrypt;
Безопасность сайта.

Обычно нужно выбрать домен, заказать или активировать сертификат и дождаться завершения установки.

На VPS порядок зависит от веб-сервера, операционной системы, ACME-клиента и используемой панели администрирования.

Не копируйте команды для чужого сервера вслепую. Инструкция для Apache на Ubuntu может не подходить Nginx, LiteSpeed, IIS, контейнеру Docker или серверу под управлением хостинговой панели.

Шаг 4. Проверьте HTTPS до включения редиректа

Откройте сайт вручную:

https://example.com/

Затем проверьте несколько разных типов страниц:

главную;
статью;
категорию;
страницу поиска;
форму обратной связи;
авторизацию;
корзину и оформление заказа, если это магазин;
страницы с изображениями и видео;
административную часть CMS.

На этом этапе HTTP ещё удобно оставить доступным, потому что в случае ошибки вы сможете сравнить две версии.

Что проверить у сертификата

сертификат действителен;
домен указан правильно;
вариант с www покрыт сертификатом, если используется;
нет ошибки цепочки сертификатов;
сертификат не просрочен;
настроено автоматическое продление.

Шаг 5. Измените адрес сайта в CMS

На этом этапе инструкция зависит от CMS.

Нельзя дать один путь меню, который будет одинаково работать в WordPress, Joomla, Drupal, OpenCart, Bitrix и самописном проекте.

Нужно найти настройки, отвечающие за основной URL сайта, и при необходимости заменить:

http://example.com

на:

https://example.com

WordPress

В стандартной установке WordPress проверьте:

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

Обычно они находятся в разделе «Настройки → Общие».

После перехода оба адреса должны использовать HTTPS.

Однако значения могут быть принудительно определены в wp-config.php через:

WP_HOME
WP_SITEURL

В такой конфигурации поля в административной панели могут быть недоступны для редактирования.

Важно для WordPress. Изменение двух основных адресов не обязательно заменит старые HTTP-ссылки во всём содержимом базы данных.

Шаг 6. Найдите старые HTTP-адреса

После изменения основного URL необходимо проверить все места, где старый адрес мог быть сохранён вручную.

CMS и база данных

Проверьте:

текст страниц и записей;
URL изображений;
поля настроек CMS;
настройки плагинов и модулей;
виджеты;
меню;
пользовательские поля;
SEO-метаданные;
настройки конструктора страниц.

Шаблон

Ищите жёстко прописанные адреса вида:

http://example.com/...

в:

HTML;
PHP;
CSS;
JavaScript;
шаблонах header и footer;
файлах подключения ресурсов.

Файлы конфигурации

Проверьте:

.htaccess;
конфигурацию Nginx;
wp-config.php для WordPress;
конфигурационные файлы используемой CMS;
переменные окружения;
настройки CDN и reverse proxy.

База данных WordPress

Здесь нельзя бездумно выполнять обычный SQL REPLACE() по всей базе.

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

Используйте инструмент поиска и замены, который корректно обрабатывает структуру данных WordPress, и перед операцией обязательно сделайте резервную копию базы.

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

Шаг 7. Исправьте mixed content

Mixed content возникает, когда сама страница открывается по HTTPS, но пытается загрузить один или несколько ресурсов по HTTP.

Например:

https://example.com/article/

загружает:

http://example.com/wp-content/uploads/photo.jpg

или:

http://cdn.example.com/style.css

Где чаще всего остаётся HTTP

изображения в старых статьях;
фоновые изображения в CSS;
CSS-файлы;
JavaScript;
веб-шрифты;
iframe;
видео;
виджеты сторонних сервисов;
счётчики;
рекламные скрипты;
URL, записанные непосредственно в теме;
URL из настроек плагинов;
ресурсы внешнего CDN.

Современные браузеры часть небезопасного контента пытаются автоматически перевести на HTTPS, а опасные типы mixed content могут полностью блокировать. Поэтому рассчитывать на то, что браузер «сам всё исправит», нельзя.

Как найти mixed content

Откройте страницу в браузере.
Нажмите F12.
Откройте вкладку Console.
Перезагрузите страницу.
Найдите сообщения Mixed Content.

Для большого сайта дополнительно стоит выполнить обход страниц краулером, который умеет искать HTTP-ресурсы внутри HTTPS-страниц.

Как исправлять

Лучший вариант — изменить источник URL так, чтобы ресурс изначально запрашивался через HTTPS.

Например:

http://example.com/image.jpg

заменить на:

https://example.com/image.jpg

Но сначала убедитесь, что ресурс действительно доступен по HTTPS.

Особенно внимательно проверяйте сторонние ресурсы. Если внешний сервис вообще не поддерживает HTTPS, простой заменой протокола проблему не решить. Ресурс придётся заменить, убрать или перенести на безопасный источник.

Шаг 8. Проверьте внутренние ссылки

После перехода внутренние ссылки желательно сразу вести на HTTPS-версию:

https://example.com/page/

а не:

http://example.com/page/

Редирект всё равно отправит пользователя на HTTPS, но лишний переход увеличивает количество запросов и создаёт ненужную цепочку.

Проверьте:

главное меню;
хлебные крошки;
ссылки внутри статей;
логотип;
пагинацию;
похожие материалы;
кнопки;
формы;
ссылки в подвале.

Шаг 9. Обновите canonical

После запуска HTTPS canonical на HTTPS-странице должен указывать на выбранный канонический HTTPS-адрес.

Например:

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

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

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

иначе сайт одновременно сообщает поисковой системе, что постоянной версией является HTTPS, и указывает старую HTTP-страницу как canonical.

Шаг 10. Обновите sitemap.xml

После перехода карта сайта должна содержать HTTPS-адреса.

Например:

<loc>https://example.com/article/</loc>

а не:

<loc>http://example.com/article/</loc>

Если sitemap создаётся CMS или SEO-плагином автоматически, после изменения основного URL она часто обновляется самостоятельно. Всё равно откройте файл и проверьте несколько URL вручную.

Шаг 11. Проверьте robots.txt

Сам файл robots.txt не нужно переписывать только ради замены протокола, если внутри нет абсолютных HTTP-адресов.

Но обязательно проверьте строку Sitemap.

Было:

Sitemap: http://example.com/sitemap.xml

Должно стать:

Sitemap: https://example.com/sitemap.xml

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

Опасная ошибка. На тестовой HTTPS-версии иногда временно закрывают сайт от роботов, а после запуска забывают убрать ограничение.

Шаг 12. Настройте 301-редирект HTTP → HTTPS

Когда HTTPS-версия полностью проверена, необходимо настроить постоянное перенаправление.

Задача проста:

http://example.com/page/

должен возвращать постоянный редирект на:

https://example.com/page/

Важно сохранять путь страницы, а не отправлять весь старый сайт на главную.

Apache

На сервере Apache перенаправление часто настраивается через .htaccess. Один из распространённых вариантов:

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

Но эту конфигурацию нельзя считать универсальной. Если сайт находится за CDN, балансировщиком или reverse proxy, сервер может получать запрос уже после завершения TLS на прокси, и проверка %{HTTPS} потребует другой логики.

Nginx

Для Nginx обычно создаётся отдельный HTTP-блок сервера:

server {
    listen 80;
    server_name example.com www.example.com;

    return 301 https://$host$request_uri;
}

Конкретная конфигурация зависит от выбранной основной версии домена. Например, если каноническим вариантом является только https://example.com, может быть разумнее сразу отправлять и HTTP, и www на него без лишней цепочки.

Панель хостинга

Многие провайдеры позволяют включить перенаправление одной настройкой вроде:

«Принудительный HTTPS»;
«Перенаправлять HTTP на HTTPS»;
«Force HTTPS»;
«HTTPS redirect».

Если такая функция есть, обычно предпочтительнее использовать штатный механизм хостинга, а не одновременно создавать ещё один редирект в CMS и .htaccess.

Не включайте сразу несколько одинаковых механизмов. Редирект в панели хостинга + .htaccess + плагин CMS + CDN может создать лишние цепочки или цикл перенаправлений.

Шаг 13. Проверьте 301-редиректы

После включения перенаправления проверьте несколько URL.

Например:

http://example.com/
http://example.com/article/
http://example.com/category/test/

Каждый старый адрес должен приводить к соответствующей HTTPS-странице.

Плохой вариант:

http://example.com/article/
→
http://www.example.com/article/
→
https://www.example.com/article/
→
https://example.com/article/

Здесь три перенаправления вместо одного.

Лучше:

http://example.com/article/
→ 301 →
https://example.com/article/

Проверка через curl

Если доступна командная строка:

curl -I http://example.com/article/

Нужно увидеть постоянный редирект и правильный заголовок Location.

Шаг 14. Проверьте SEO после перехода

После включения редиректа ещё раз проверьте:

canonical;
sitemap.xml;
robots.txt;
внутренние ссылки;
Open Graph URL;
структурированные данные, если там указаны абсолютные URL;
hreflang для мультиязычных сайтов;
URL изображений;
URL в RSS;
ссылки в профилях и рекламных кампаниях.

Google рассматривает переход HTTP → HTTPS как изменение URL. Для такого перехода рекомендуется использовать постоянные серверные редиректы и обновить внутренние ссылки, canonical и sitemap.

Нужно ли заново добавлять сайт в Google Search Console?

Для простого перехода HTTP → HTTPS Google не требует использовать инструмент Change of Address.

Однако HTTPS-версия должна быть доступна в Search Console. Если используется свойство уровня домена (Domain property), оно уже охватывает разные протоколы и поддомены соответствующего домена. При работе с URL-prefix properties убедитесь, что HTTPS-вариант добавлен и подтверждён.

После перехода полезно:

проверить несколько HTTPS-страниц через проверку URL;
отправить актуальный HTTPS sitemap;
следить за индексированием;
контролировать ошибки обхода;
проверить отчёты HTTPS, если они доступны для свойства.

Повторно «отправлять весь сайт на индексацию» вручную страницу за страницей не требуется.

А что делать с другими панелями вебмастеров?

Принцип тот же: проверьте, считает ли конкретный сервис HTTP и HTTPS отдельными свойствами, добавьте или подтвердите HTTPS-версию при необходимости и отправьте обновлённую карту сайта.

Интерфейсы и требования сервисов меняются, поэтому здесь нельзя давать одинаковую инструкцию для каждой поисковой системы.

Шаг 15. Проверьте внешние сервисы

После перехода на HTTPS часто забывают о системах, находящихся за пределами CMS.

Проверьте:

аналитику;
рекламные кабинеты;
платёжные системы;
webhook URL;
API callback URL;
OAuth redirect URL;
CDN;
системы резервного копирования;
почтовые шаблоны;
RSS;
сервисы мониторинга;
социальные профили.

Некоторые внешние сервисы требуют вручную зарегистрировать новый callback или redirect URI с HTTPS.

Нужно ли сразу включать HSTS?

Нет. Сначала сайт должен некоторое время стабильно работать только через HTTPS.

HSTS передаётся заголовком:

Strict-Transport-Security

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

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

Почему нельзя торопиться

После включения HSTS браузер может отказаться открывать сайт через HTTP до истечения max-age. При проблеме с сертификатом пользователь также не сможет просто проигнорировать предупреждение и продолжить работу так же, как на обычном сайте без HSTS.

Особенно осторожно используйте:

includeSubDomains

Эта директива распространяет политику на поддомены.

Если у вас есть:

mail.example.com
old.example.com
api.example.com
dev.example.com

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

А HSTS preload?

С preload нужно быть ещё осторожнее. Домен добавляется в список, используемый браузерами для принудительного HTTPS ещё до первого посещения сайта.

Не отправляйте рабочий домен в preload только потому, что какой-либо онлайн-тест рекомендует «усилить безопасность».

Правильный порядок. Сначала полностью переведите сайт и необходимые поддомены на HTTPS, проверьте сертификаты, автоматическое продление, редиректы и внешние сервисы. Затем можно постепенно вводить HSTS. includeSubDomains и особенно preload требуют отдельного осознанного решения.

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

Перед тем как считать миграцию законченной, пройдите этот список:

Проверка	Правильный результат
HTTPS главной страницы	Открывается без предупреждений
Сертификат	Действителен для нужных имён домена
Продление сертификата	Автоматизировано или контролируется
HTTP URL	301 на соответствующий HTTPS URL
Внутренние ссылки	Ведут непосредственно на HTTPS
Mixed content	Отсутствует
CSS и JavaScript	Загружаются по HTTPS
Изображения и шрифты	Загружаются по HTTPS
Canonical	HTTPS
sitemap.xml	Содержит HTTPS URL
robots.txt	Не блокирует сайт, Sitemap ведёт на HTTPS
Формы	Работают через HTTPS
API и webhook	Проверены
Search Console	HTTPS доступен для мониторинга, sitemap отправлен
HSTS	Пока выключен, если миграция ещё не проверена полностью

Типичные ошибки при переводе сайта на HTTPS

Установили сертификат и больше ничего не сделали

Сертификат — только первый этап. Без редиректов, исправления внутренних URL и SEO-настроек сайт фактически продолжает существовать сразу в двух вариантах.

Настроили 302 вместо 301

Для постоянного перехода HTTP → HTTPS используйте постоянный серверный редирект. Обычно это 301 или 308. В типовой миграции сайта чаще используют 301.

Все HTTP-страницы отправляются на главную

Так делать не нужно.

Старая страница:

http://example.com/catalog/product/

должна переходить на:

https://example.com/catalog/product/

а не на главную.

Остался старый canonical

HTTPS-страница не должна указывать HTTP-версию в качестве canonical после полноценного перехода.

В sitemap остались HTTP URL

Карта сайта должна сообщать поисковой системе о новых HTTPS-адресах.

Забыли старые изображения

Это одна из основных причин mixed content на старых CMS-сайтах.

Включили HSTS слишком рано

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

Использовали плагин как замену правильной конфигурации

Плагин может упростить миграцию CMS, но важно понимать, где реально выполняется HTTPS и редирект: на веб-сервере, CDN, reverse proxy, хостинге или внутри приложения.

FAQ

Нужно ли покупать SSL-сертификат?

Не обязательно. Для большинства обычных сайтов подходит бесплатный сертификат Let's Encrypt, если его поддерживает ваш хостинг или сервер.

HTTPS ухудшит позиции сайта?

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

Нужно ли менять все ссылки вручную?

Не обязательно. Для большого сайта можно использовать безопасный поиск и замену по базе данных или специализированные средства CMS. Но результат обязательно нужно проверить.

Можно ли просто включить Force HTTPS в панели?

Это настроит перенаправление у многих хостеров, но не исправит автоматически все HTTP-адреса внутри базы данных, шаблона, сторонних скриптов, canonical и других элементов сайта.

Нужно ли менять robots.txt?

Только если в нём присутствуют абсолютные HTTP-адреса или настройки, которые необходимо изменить после миграции. Особенно проверьте директиву Sitemap.

Нужно ли создавать новый sitemap.xml?

Он должен содержать HTTPS URL. Если CMS генерирует карту динамически, после изменения адреса сайта достаточно проверить, что она действительно обновилась.

Нужно ли использовать Change of Address в Google Search Console?

Нет, для простого перехода HTTP → HTTPS этот инструмент не требуется.

Нужно ли включать HSTS?

Это полезная дополнительная защита, но включать её стоит только после полного и стабильного перехода сайта и необходимых поддоменов на HTTPS.

Можно ли отключить HTTP полностью?

Не стоит просто закрывать порт 80 без перенаправления. Старые HTTP-ссылки должны продолжать принимать запрос и постоянно перенаправлять посетителей на HTTPS.

Заключение

Правильный переход на HTTPS — это не установка одного сертификата, а небольшая миграция URL всего сайта.

Сначала получите и проверьте сертификат. Затем настройте HTTPS в CMS, исправьте абсолютные URL и mixed content, обновите canonical, sitemap.xml и при необходимости robots.txt. Только после проверки HTTPS-версии включайте постоянный редирект с каждого HTTP URL на соответствующий HTTPS URL.

После запуска проверьте сайт краулером и вручную, отправьте актуальную карту сайта в используемые панели вебмастеров и следите за индексированием. HSTS оставьте на последний этап: сначала убедитесь, что HTTPS стабильно работает на основном домене и всех поддоменах, которых будет касаться политика.

Главное — не пытайтесь применить одну конфигурацию ко всем сайтам. Конкретная настройка зависит от CMS, веб-сервера, хостинга, CDN, reverse proxy и структуры проекта. Принципы миграции одинаковы, а техническая реализация может заметно отличаться.

:::writing{}

Проверил ключевые технические моменты по актуальной документации: Let's Encrypt по-прежнему использует 90-дневный срок по умолчанию и поддерживает wildcard; Google рекомендует постоянные серверные редиректы, HTTPS canonical и новый sitemap, причём Change of Address для HTTP→HTTPS не нужен; браузеры действительно блокируют или автоматически повышают mixed content; HSTS сохраняется браузером и с includeSubDomains затрагивает поддомены.

Полезная официальная документация: рекомендации Google по миграции сайта, документация Let's Encrypt и справка MDN по mixed content.

Войдите, чтобы ставить лайки и сохранять статьи Перейти в VK ↗

Обсуждение

Кудашев Дмитрий Витальевич

IT-специалист из Ростова-на-Дону. Делюсь практическим опытом, объясняю технологии понятным языком

Об авторе →

Что нужно сделать для перехода сайта на HTTPS

Что такое HTTPS и SSL-сертификат

Шаг 1. Сделайте резервную копию

Шаг 2. Выберите SSL-сертификат

Бесплатный сертификат Let's Encrypt

Wildcard-сертификат

Коммерческий сертификат

Шаг 3. Установите сертификат

Шаг 4. Проверьте HTTPS до включения редиректа

Что проверить у сертификата

Шаг 5. Измените адрес сайта в CMS

WordPress

Шаг 6. Найдите старые HTTP-адреса

CMS и база данных

Шаблон

Файлы конфигурации

База данных WordPress

Шаг 7. Исправьте mixed content

Где чаще всего остаётся HTTP

Как найти mixed content

Как исправлять

Шаг 8. Проверьте внутренние ссылки

Шаг 9. Обновите canonical

Шаг 10. Обновите sitemap.xml

Шаг 11. Проверьте robots.txt

Шаг 12. Настройте 301-редирект HTTP → HTTPS

Apache

Nginx

Панель хостинга

Шаг 13. Проверьте 301-редиректы

Проверка через curl

Шаг 14. Проверьте SEO после перехода

Нужно ли заново добавлять сайт в Google Search Console?

А что делать с другими панелями вебмастеров?

Шаг 15. Проверьте внешние сервисы

Нужно ли сразу включать HSTS?

Почему нельзя торопиться

А HSTS preload?

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

Типичные ошибки при переводе сайта на HTTPS

Установили сертификат и больше ничего не сделали

Настроили 302 вместо 301

Все HTTP-страницы отправляются на главную

Остался старый canonical

В sitemap остались HTTP URL

Забыли старые изображения

Включили HSTS слишком рано

Использовали плагин как замену правильной конфигурации

FAQ

Нужно ли покупать SSL-сертификат?

HTTPS ухудшит позиции сайта?

Нужно ли менять все ссылки вручную?

Можно ли просто включить Force HTTPS в панели?

Нужно ли менять robots.txt?

Нужно ли создавать новый sitemap.xml?

Нужно ли использовать Change of Address в Google Search Console?

Нужно ли включать HSTS?

Можно ли отключить HTTP полностью?

Заключение

Комментарии

Обсуждение доступно после входа

Кудашев Дмитрий Витальевич

Рекомендуем по теме

robots.txt и sitemap.xml для небольшого сайта: настройка без ошибок индексации