Перейти к содержимому 
WordPress HTTPS защищает данные для входа в систему, контактные формы и файлы cookie, а также помогает мне повысить рейтинг и конверсию. В этом руководстве я покажу вам полный переход с HTTP на HTTPS в WordPress - с сертификатом, преобразованием URL, 301 редиректом, исправлением смешанного контента и чистыми SEO-шагами.
Центральные пункты
- SSL Активируйте правильно и покройте домен
- URL-адреса конвертировать в WordPress
- 301 Принудительная переадресация
- Смешанное содержание Целенаправленное исправление
- SEO подтяните и проверьте
Почему HTTPS имеет значение для WordPress
Без шифрования злоумышленники могут перехватывать сеансы или читать формы, поэтому я защищаю весь Трансмиссия между браузером и сервером с помощью протокола TLS. HTTPS предотвращает появление предупреждений в браузере, повышает доверие и усиливает сигналы, которые поисковые системы оценивают положительно. Многие API, платежные сервисы и функции браузера в любом случае требуют защищенных соединений. Я также получаю выгоду от HTTP/2 и HTTP/3, которые загружаются быстрее под TLS и позволяют распараллелить работу. Чистый переход на HTTPS предотвращает дублирование контента, поскольку я могу ограничить все варианты уникальным Пушка (Канонический).
Подготовьте резервную копию и сертификат SSL
Прежде чем приступать к настройкам, я создаю полную резервную копию файлов и базы данных, чтобы иметь к ним доступ в любое время. Резервное копирование можно вернуть. Затем я заказываю или активирую сертификат - Let's Encrypt часто бывает достаточно без дополнительной платы, в качестве альтернативы я использую сертификат DV/OV/EV в зависимости от моих требований. Многие хостеры предоставляют мастер, который выпускает и обновляет сертификаты автоматически. Если вам нужна пошаговая помощь, воспользуйтесь этим руководством на сайте Установите бесплатный SSL. Затем я проверяю, является ли цепочка сертификатов полной и покрыты ли сертификатом домены www и apex (без www); я также учитываю поддомены, такие как staging или cdn, и сохраняю их Валидность с первого взгляда.
Выбор сертификата и управление ключами
Помимо первоначальной активации, я также отметил несколько деталей, которые отсутствуют во многих инструкциях: Нужен ли мне сертификат с подстановочным знаком (*.domain.tld) для многих поддоменов или достаточно сертификата SAN с несколькими явными именами хостов? Для повышения производительности я использую сертификаты ECDSA (эллиптические кривые) вместо классических ключей RSA, где это возможно - они меньше и ускоряют рукопожатие TLS. Я строго защищаю закрытый ключ (права на файлы 600, только пользователи сервера) и документирую Обновление-цепь: действительно ли автоматическое продление проходит, даже если CDN или обратный прокси подключены выше по течению? Для решения задач ACME я проверяю, не мешают ли проверке редиректы, ограничения тарифов или страницы обслуживания. Я также активирую сшивание OCSP и современные протоколы (TLS 1.2/1.3) непосредственно на веб-сервере, чтобы браузеры могли быстрее обрабатывать проверки сертификатов.
Изменение URL-адресов WordPress
Я вхожу в приборную панель и открываю Настройки → Общие, затем устанавливаю "Адрес WordPress (URL)" и "Адрес веб-сайта (URL)" на https://. После сохранения я снова вхожу в систему, если сессия возобновляется. Затем я удаляю кэш браузера и, если есть, кэш моего плагина кэширования, чтобы посетители сразу получали защищенную версию. Затем я просматриваю виджеты, меню и жесткие ссылки, поскольку они все еще могут содержать http-ссылки. Что касается медиа в постах, я редактирую отдельные материалы или планирую чистку Поиск в базе данных (см. ниже).
Безопасный вход и администрирование
Для области администратора я обеспечиваю TLS с помощью небольшого добавления в wp-config.php. Для этого над строкой "/* Это все, прекратите редактирование! */" и загружаю файл:
define('FORCE_SSL_ADMIN', true);
Это означает, что логин, куки и весь бэкэнд работают строго по HTTPS. Если обратный прокси-сервер или CDN-площадка подключены выше по течению, я убеждаюсь, что WordPress правильно интерпретирует заголовок "X-Forwarded-Proto: https". В противном случае приложение неправильно воспринимает соединение как небезопасное и устанавливает куки без Безопасный-флаг.
Более безопасные константы WordPress и обнаружение прокси-серверов
Если я не могу добраться до URL в бекенде (например, зацикливаясь на плагинах), я временно устанавливаю явные константы в wp-config.php и таким образом устраняю неправильные настройки:
define('WP_HOME', 'https://deinedomain.de');
define('WP_SITEURL', 'https://deinedomain.de');
Я также добавляю обнаружение за прокси-серверами, чтобы is_ssl() правильно:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
Это предотвращает неправильную генерацию смешанного содержимого в бэкенде и гарантирует, что cookie авторизации будут последовательно связаны с Безопасный-атрибут доставлен.
Настройте 301 редирект в .htaccess
Чтобы гарантировать, что все запросы будут постоянно направляться в безопасную версию, я установил Переадресация с http на https. В классической среде Apache я открываю .htaccess в корне WordPress и добавляю правила над блоком WordPress:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
В Nginx переадресация происходит в конфигурации сервера (server { listen 80; return 301 https://$host$request_uri; }). Для получения подробной информации, вариантов и устранения неполадок вы можете найти наглядное руководство Переадресация HTTPS. Важно: я делаю цепочку редиректов короткой, то есть http→https и, при необходимости, www→non-www или наоборот за один переход, чтобы не было лишних скачков в цепочке редиректов. Время загрузки увеличение.
Стратегия чистого перенаправления без циклов
В дополнение к основной переадресации я устанавливаю правила согласованности: Либо www, либо не www - никогда не оба. В Apache я решаю эту проблему за один шаг с помощью проверки хоста:
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^deinedomain\.de$ [NC]
RewriteRule ^ https://deinedomain.de%{REQUEST_URI} [L,R=301]
Я получаю строки запросов (параметры UTM) автоматически, сокращаю количество перенаправлений до одного хопа и избегаю циклов, не активируя никаких конкурирующих правил в плагине или CDN. Если пограничный прокси использует "Гибкий SSL" (браузер→CDN зашифрованный, CDN→Origin незашифрованный), я переключаюсь на "Полный (строгий)", чтобы TLS соблюдался как для посетителя, так и для источника - иначе есть риск возникновения проблем с зацикливанием и смешением протоколов.
Распознавание и устранение смешанного содержимого
После перенаправления я проверяю страницу с помощью инструментов браузера на наличие "смешанного содержимого", т. е. содержимого, к которому по-прежнему можно получить доступ через http загружаются. Часто страдают изображения, шрифты, скрипты или таблицы стилей в темах, конструкторах страниц и виджетах. Я исправляю жестко закодированные URL-адреса, меняя их на https в редакторе, в кастомайзере или в настройках плагина. Такие инструменты, как "Really Simple SSL", помогают в краткосрочной перспективе, но лучше постоянно чистить источники. Заблокированный контент вызывает ошибки стилизации или скрытые функции, поэтому я очищаю все, пока браузер не перестанет блокировать контент. Предупреждения показывает больше.
Профессиональный контрольный список смешанного содержания
- Я активирую директиву CSP в качестве теста
upgrade-insecure-requestsв режиме "только для отчетов", чтобы увидеть, что браузер автоматически переходит на https - затем я постоянно очищаю источники. - Шрифты и внешние стили часто требуют CORS-заголовков; без них
Access-Control-Allow-Originони выглядят как заблокированные. - Я распознаю фоновые изображения CSS с абсолютными ссылками http в инструментах разработчика и заменяю их на относительные пути или https.
- iframes (например, карты, видео) также должны говорить https, иначе браузер их скроет.
- В темах я избегаю жестко закодированных путей и использую такие функции, как
home_url(),site_url(),plugins_url()иcontent_url()чтобы WordPress предоставил правильный базовый URL.
Пошаговый обзор
В следующей таблице в компактном формате представлены все задачи, связанные с переходом на новое оборудование, и она помогает мне Последовательность должны быть соблюдены.
| Шаг | Рекомендация/объяснение |
|---|---|
| Создание резервной копии | Перед каждым изменением завершите Резервное копирование файлы и база данных |
| Установите SSL-сертификат | Активируйте Let's Encrypt или платную версию у хостера |
| Настройка URL-адресов | Установите https в бекенде в разделе Настройки → Общие |
| Установите перенаправления | Настройте .htaccess или блок сервера Nginx для 301 на HTTPS |
| Проверка смешанного содержимого | Замените жесткие http-ссылки в контенте, темах и плагинах |
| Заменить базу данных | Замените все http-случаи резервным копированием и авторитетным инструментом. |
| Обновление Google/SEO | Настройка свойств Search Console, карты сайта, аналитики и каноники |
Чистая замена URL-адресов баз данных
Иногда http-ссылки лежат без дела в виджетах, шорткодах или пользовательских полях, поэтому я использую проверенный и испытанный способ Инструмент например, "Лучшая поисковая замена". Я ищу "http://deinedomain.de" и заменяю его на "https://deinedomain.de", сначала в пробном варианте, затем в реальном с резервным копированием. Для последовательного переименования через WP-CLI я использую "wp search-replace", что гораздо быстрее для больших страниц. Сериализованные массивы и объекты должны обрабатываться корректно, поэтому я полагаюсь на инструменты, которые справляются с этим должным образом. После замены я проверяю случайные выборки во фронтенде и в важных Макеты.
База данных: что я не заменяю вслепую
Я трогаю столбец GUID в wp_posts только тогда, когда действительно меняю домен. Чистое изменение протокола на https обычно требует нет Изменение GUID, так как они в первую очередь служат уникальным идентификатором. Перед глобальной заменой я также проверяю, ссылаются ли плагины на внешние конечные точки (веб-хуки, API) с помощью http - я предпочитаю обновлять их специально и тестировать обратный канал. Для крупных проектов я планирую короткую фазу замораживания контента, чтобы во время поисковой замены не создавались новые посты со старыми схемами. Я использую WP-CLI для обеспечения скорости и воспроизводимости:
wp search-replace 'http://deinedomain.de' 'https://deinedomain.de' --all-tables-with-prefix --precise --dry-run
wp search-replace 'http://deinedomain.de' 'https://deinedomain.de' --all-tables-with-prefix --precise
SEO-проверка после перехода на новый уровень
После внесения изменений я создаю новое свойство с https в Search Console и отправляю обновленное сообщение Карта сайта на. Я проверяю внутренние ссылки, канонические теги, ссылки hreflang и теги open graph на наличие https. Сниппеты отслеживания (аналитика, менеджер тегов, пиксель) также должны использовать безопасный адрес. В SEO-плагинах я проверяю правила редиректа и убеждаюсь, что нет "мягких 404". Если важны счетчики социальных акций, я проверяю, как инструмент работает с новым Адрес ручки.
Тонкая настройка фидов, роботов и канонических файлов
Я проверяю, доступны ли RSS/Atom-каналы через https и передают ли они корректное содержимое. В статически поддерживаемом robots.txt я адаптирую пути к карте сайта для https, если это необходимо. Я устанавливаю абсолютные канонические URL, чтобы поисковые системы однозначно интерпретировали сигналы https. Пары hreflang (многоязычные сайты) не должны отличаться по протоколу, иначе возникает несогласованность.
Кэширование, CDN и производительность при использовании HTTPS
HTTPS также выгоден с точки зрения скорости, поскольку HTTP/2/3 позволяет мультиплексировать и сжимать заголовки с помощью Соединение. Я обращаю внимание на возобновление сеанса TLS, сшивание OCSP и современные наборы шифров, которые ускоряют рукопожатия. CDN доставляет статические активы ближе к посетителю, но при этом должна стабильно работать на https. В плагинах кэширования я активирую опцию "Кэш для HTTPS", если она доступна, и очищаю старые артефакты. Затем я делаю замеры с помощью таких инструментов, как Lighthouse, и сравниваю Times до и после изменения.
Возможности CDN/прокси
При использовании восходящей CDN я всегда устанавливаю "Full (strict)" для Origin, загружаю туда сертификат или использую сертификат Origin и разрешаю доставку только по протоколу https. Я проверяю, кэширует ли CDN редиректы (иначе я вижу старые состояния), и очищаю пограничные кэши после переключения. Сжатие Brotli, HTTP/3/QUIC и 0-RTT также могут помочь - но важно, чтобы правила на всей странице больше не вводили http-ресурсы. Наконец, я отправляю правильный IP-адрес клиента-заголовок (например, X-Forwarded-For) и настройте веб-сервер так, чтобы в журналах отображался реальный IP посетителя.
HSTS и другие заголовки безопасности
Если сайт полностью работает на HTTPS, я активирую HTTP Strict Transport Security (HSTS), чтобы браузеры использовали только HTTPS-вариант. Я устанавливаю заголовок, например, так: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload - но только если все поддомены действительно безопасно доступны. О возможностях и подводных камнях я рекомендую руководство Активировать HSTS. Кроме того, я установил такие заголовки безопасности, как X-Content-Type-Options, X-Frame-Options и жесткую политику безопасности контента, которая разрешает использование источников https. Эти заголовки усиливают уровни защиты от инъекций контента, перехвата кликов и MIME-Нюх.
Тонкая настройка заголовка безопасности
В дополнение к HSTS я добавляю прагматичную конфигурацию заголовков: Политика рефереров: strict-origin-when-cross-origin ограничивает передачу чувствительных путей, Политика разрешений ограничивает API браузера (например, камеру, микрофон), а умеренный CSP с default-src 'self' https: предотвращает появление нежелательных посторонних источников. Я начинаю с Только для отчетовЯ собираю информацию о нарушениях и затем ужесточаю правила. Так я предотвращаю непреднамеренное "разрушение" сайта заголовками безопасности.
Тестирование, мониторинг и устранение неисправностей
Я тестирую переход в закрытом окне и на мобильных устройствах, чтобы не было старых Cookies или кэша. В журнале консоли браузера быстро появляются предупреждения о смешанном содержимом и заблокированных ресурсах. Я использую "curl -I http://deinedomain.de", чтобы проверить, происходит ли переход 301 на версию https и возникают ли другие цепочки. Затем я отслеживаю журналы ошибок на сервере и отчеты 404 в плагине SEO или в Search Console. Если отдельные плагины больше не загружаются, я проверяю их внешние Зависимости и обновите его до последней версии.
Контроль при запуске и постоянный мониторинг
- Перед переключением я иногда включаю кратковременный режим обслуживания, чтобы установить последовательные редиректы и кэши.
- Я слежу за истечением срока действия сертификата (сигналы тревоги), чтобы не было неприятных сюрпризов.
- В первые несколько дней я слежу за показателем 404, кривыми ранжирования, статистикой переползания и Core Web Vitals, чтобы принять своевременные контрмеры.
- Для кампаний я проверяю, полностью ли сохраняются параметры UTM при 301-м перенаправлении.
Особенности многосайтовости, прокси и стейджинга
Для многосайтовости я меняю сетевой адрес на https и настраиваю сопоставления, чтобы все сайты имели стандартный Переадресация использование. За балансировщиками нагрузки или CDN веб-сервер должен соблюдать заголовок "X-Forwarded-Proto", иначе WordPress решит, что соединение небезопасно, и установит неправильные URL. Для систем staging я использую собственные сертификаты или защищаю их с помощью Basic Auth, чтобы поисковые системы их не индексировали. После внесения изменений я снова включаю кэши, прогреваю их и слежу за нагрузкой. В средах с собственными прокси-серверами или брандмауэрами я документирую все изменения, чтобы при последующих развертываниях можно было использовать Конфигурация взять на себя.
Многосайтовость и коммерция - детали, которые часто отсутствуют
В многосайтовых установках я обновляю на каждом сайте siteurl и дом значения, особенно если речь идет о сопоставлении доменов. Если sunrise.php или специальных плагинов отображения, я проверяю, поддерживают ли они https. В магазинах (например, WooCommerce) я последовательно устанавливаю "Оформление заказа" и "Мой аккаунт" на https, тестирую платежи и Webhook-возвратов и страниц благодарности. Платежные провайдеры и API доставки часто требуют обновления URL обратного вызова - я настраиваю их и проверяю подпись после изменения.
Распространенные подводные камни и быстрые решения
Некорректные сертификаты вызывают красные предупреждающие знаки - поэтому я проверяю период выпуска, цепочку и все ли домены включены в сертификат, чтобы Соединение работает без перебоев. Отсутствие 301 редиректа приводит к появлению дублированного контента; я регулирую это с помощью четких и коротких правил и избегаю многократных переходов. Смешанный контент часто возникает из-за жестко закодированных файлов тем; здесь я заменяю схемы http или использую URL без схем ("//...") в соответствующих местах. Внешние сервисы, которые по-прежнему ссылаются на http-запросы; здесь я обновляю веб-крючки, конечные точки и ключи. Если плагин не справляется с переходом, я тестирую обновление или заменяю его решением, которое полностью поддерживает HTTPS. Поддерживает.
Резюме: Безопасный переход на HTTPS
Я начинаю с полного резервного копирования, активирую СертификатЯ перевожу URL-адреса WordPress на https, обеспечиваю 301 редирект и последовательно очищаю смешанный контент. Затем я заменяю все оставшиеся http-записи в базе данных, обновляю настройки SEO и измеряю эффективность. HSTS и заголовки безопасности еще больше повышают безопасность, если все поддомены правильно реагируют на https. Что касается хостинга, то я полагаюсь на провайдеров с хорошей поддержкой, автоматическим продлением и быстрым предоставлением TLS, таких как webhoster.de, что значительно облегчает мою работу. Это обеспечивает безопасность, быстроту и видимость сайта - именно то, что я ожидаю от стабильного сайта. HTTPS-переход.
