SEO руководство по миграции HTTPS

1. Защитите веб-сайт своей компании без потери рейтинга или трафика Цели: Сделайте ваш сайт безопасным...
2. Твоя компания
3. Сколько времени нужно, чтобы защитить свой сайт и увидеть результаты в Google?
4. Сроки обеспечения безопасности вашего сайта
5. Ваши действия:
6. Действия Google:
7. Защита вашего сайта: процесс
8. 1. Оценка того, как Google в настоящее время понимает ваш сайт
9. 2. Подготовка вашего сайта
10. Смешанный контент
11. Есть ли ярлыки?
12. Настройка и тестирование сертификата безопасности
13. Выбор и получение сертификата безопасности
14. Выделенный IP-адрес или нет
15. Установка сертификата
16. Тестирование сертификата
17. Проверка работоспособности сертификата
18. Тестовый сертификат на совместимость и прочность
19. Доступ к разработке
20. 4. Перенаправления
21. Где находятся настройки перенаправления?
22. Какие перенаправления следует использовать?
23. 301 перенаправление
24. Apache / .htaccess
25. NGINX
26. Как только ваши перенаправления станут доступны, ваш сайт будет в безопасности
27. 5. Проверка
28. Кэширование
29. Переключатель
30. 6. Мониторинг реакции Google
31. Действия Google
32. Открытие Google
33. Goolgebot Deep Crawl
34. Google индексация
35. 7. Оптимизация
36. Производительность (насколько быстро загружаются ваши веб-страницы)
37. Цепочки перенаправления
38. Веб сервер
39. Обновление программного обеспечения сервера
40. Использование Cipher Suite
41. Улучшение безопасности с помощью HSTS
42. Безопасность
43. Спектакль
44. HSTS решает обе проблемы
45. Внедрение HSTS
46. Использование заголовков безопасности

Защитите веб-сайт своей компании без потери рейтинга или трафика

Цели:

• Сделайте ваш сайт безопасным
• Улучшите восприятие вашего сайта Google
• Не теряйте рейтинг в Google
• Не теряйте деньги или трафик

Большинство руководств по HTTPS не учитывают бюджет SEO, пот и слезы, которые попали на веб-сайты.

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

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

Как выглядит успешная миграция HTTPS?

Успешная защита веб-сайта вашей компании - это не только физические действия, которые вы предпринимаете для защиты своего сайта, но и то, как пользователи видят ваш сайт и как Google реагирует на ваши изменения .

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

Твоя компания

• Получил и установил сертификат безопасности.
• Перенаправил трафик с http на https.
• Нашел и исправил любые ошибки в контенте, которые влияют на состояние безопасности ваших веб-страниц в браузерах.

Ваши пользователи

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

Google

• В курсе ваших изменений.
• Просканировал весь ваш сайт.
• Отображает «https» версии ваших URL-адресов в веб-поиске.

Поэтому, когда мы используем фразу «успешная миграция HTTPS», мы имеем в виду весь процесс.

То, как вы защищаете свой сайт, напрямую влияет на то, как ваши пользователи видят ваш сайт и как Google отреагирует на него.

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

Сколько времени нужно, чтобы защитить свой сайт и увидеть результаты в Google?

• От двух недель до нескольких месяцев.

Шаги, необходимые для технической безопасности веб-сайта, могут произойти всего за час или около того, но если вы предпримете эти шаги без предварительной подготовки сайта, это может повредить тому, как пользователи и Google видят ваш сайт. Пытаясь понять, сколько времени требуется, чтобы «защитить свой сайт», нужно понимать, что есть шаги, которые вы предпримете, и есть шаги, которые предпримет Google.

Сроки обеспечения безопасности вашего сайта

Когда вы защищаете свой сайт, происходят две разные сроки.

1. Ваши действия
2. Действия Google

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

Ваши действия:

• подготовка
• HTTPS-переключатель
• верификация
• оптимизация

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

• Размер вашего сайта: веб-сайт на десять страниц будет гораздо легче подготовить, чем веб-сайт на миллион страниц.
• Если (или какой тип) используется CMS: Системы управления контентом, такие как WordPress, обычно структурированы таким образом, что многие проблемы по всему сайту могут быть решены довольно быстро, тогда как, если сайт не имеет CMS (или имеет (менее эффективная CMS), может потребоваться гораздо больше времени для внесения ручных изменений, необходимых для миграции HTTPS.
• Если ваш сайт использует консоль Google для веб-мастеров: сайт, использующий консоль Google для веб-мастеров, получит преимущество на тех сайтах, которые его не используют. Если сайт в настоящее время не использует консоль поиска Google, может потребоваться некоторое время для настройки и запуска данных.
• Техническое состояние SEO вашего сайта: веб-сайт, имеющий стандартную и унифицированную политику ссылок, стандартную политику метаданных и стандартные чистые перенаправления, будет подготовлен быстрее, чем сайт, который не уделял много внимания техническому SEO.

Действия Google:

• открытие
• Глубокий ползать
• Обновить индекс

Время, необходимое Google для реагирования на ваш недавно защищенный сайт, зависит от нескольких переменных.

• Размер вашего сайта: веб-сайт на десять страниц будет работать намного быстрее, чем веб-сайт на миллион страниц.
• Способ реализации HTTPS: веб-сайт, который надлежащим образом информировал Google о своих изменениях с помощью консоли поиска Google и карт сайта, будет работать намного быстрее, чем веб-сайт, который должен ждать, пока Google самостоятельно обнаружит каждую страницу самостоятельно.
• Если ваш сайт использует файлы Sitemap: Сайт, на котором есть существующие карты сайта, поможет Google сканировать и понять ваши настройки быстрее, чем сайт, не использующий карты сайта (особенно для крупных сайтов).
• Насколько ваш веб-сайт доступен для Goolgebot: веб-сайт, который не ограничивает Goolgebot от просмотра ресурсов и контента страниц, будет работать намного быстрее, чем веб-сайт, блокирующий страницы и ресурсы.

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

Защита вашего сайта: процесс

Основные шаги:

1. Оценка того, как Google в настоящее время понимает ваш сайт
2. Подготовка вашего сайта
3. Настройка и тестирование
4. Перенаправление
5. проверка
6. Мониторинг реакции Google
7. Оптимизация

1. Оценка того, как Google в настоящее время понимает ваш сайт

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

Самый идеальный способ выяснить, как Google видит ваш сайт, - использовать Google Search Console. Консоль поиска Google определит проблемы, которые она видит на вашем сайте. Хитрость заключается в том, чтобы знать, что искать.

Мы создали Контрольный список Google Search Console для HTTPS и мы определенно предлагаем вам взглянуть, но в двух словах следующие вещи должны быть рассмотрены в консоли поиска:

• Убедитесь, что все версии URL заявлены - подробности
• Отметьте, как Goolgebot взаимодействует с вашим сайтом - подробности
• Убедитесь, что ресурсы страницы не заблокированы - подробности
• Убедитесь, что в отчете robots.txt нет проблем или предупреждений - подробности
• Проверьте, предлагает ли Google улучшения HTML
• Проверьте статус ваших карт сайта - подробности

Проверка этих вещей (и внесение исправлений в случае необходимости) поможет вам избежать некоторых худших последствий. Это также поможет обеспечить быструю переиндексацию вашего сайта в результатах поиска Google.

Я не могу не подчеркнуть, что Google будет переиндексировать каждую веб-страницу вашего сайта в рамках этого процесса.

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

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

2. Подготовка вашего сайта

Информация о веб-хостинге

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

• Ваша хостинговая компания (Rackspace, Bluehost и др.)
• Программное обеспечение вашего веб-сервера (Apache, NGINX и т. Д.)
• Ваша CMS (WordPress, Ghost и т. Д.)

Веб-хостинг, который вы используете, программное обеспечение веб-сервера, на котором работает ваш сайт, и ваша CMS (система управления контентом) определит ваши параметры и процесс, который вам необходимо будет выполнить для обеспечения безопасности вашего сайта.

Нанимаете ли вы кого-нибудь на помощь или просто ищете учебное пособие в Интернете, знание этих основ облегчит задачу.

Например, вы найдете более качественную информацию в Интернете, если будете искать «Как защитить мой сайт NGINX WordPress, размещенный на Bluehost», чем если вы будете искать только «Как обезопасить мой сайт».

Смешанный контент

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

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

Смешанный контент может быть определен как «контент на защищенной в противном случае веб-странице, который не вызывается из безопасного источника». Если у вас есть смешанный контент на странице, эта страница не будет безопасной. Если у вас есть смешанный контент на вашем сайте (как на боковой панели), то весь ваш сайт не будет в безопасности.

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

Общими областями смешанного контента, на которые стоит обратить внимание, являются изображения и ресурсы страницы, такие как CSS и Javascript.

Есть две основные причины, по которым вы найдете смешанный контент на своих веб-страницах.

• Ресурс, на который вы звоните, находится на незащищенном веб-сайте или сервере.
• Ресурс, который вы вызываете, доступен как по HTTP, так и по HTTPS, но код, который вы используете, вызывает ресурс, используя версию HTTP.

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

Если ресурс доступен через HTTP и HTTPS, вы можете просто изменить способ вызова с вашего сайта.

По сути, при каждом обращении к ресурсу страницы на всем сайте должен использоваться «https: //» вместо «http: //».

Если это кажется большой работой, вы правы. Это потребует кого-то, кто знаком с тем, как ваш сайт использует ресурсы.

Есть ли ярлыки?

Существует способ, который может помочь вам через это в большинстве случаев в большинстве браузеров. Это называется «Обновление небезопасных запросов».

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

Настройка и тестирование сертификата безопасности

Настройка вашего веб-сервера для использования HTTPS различна для разных хостов и серверов. Все настройки делятся на основные этапы:

• Выбор и получение сертификата безопасности (часто называемого «сертификат SSL»)
• Установка сертификата
• тестирование

Выбор и получение сертификата безопасности

Сертификаты безопасности могут быть бесплатными или платными. Либо все в порядке, если сертификатам доверяют веб-браузеры (Chrome, Firefox и т. Д.), И для большинства этот процесс примерно одинаков.

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

• Проверка домена: это подтверждает, что пользователь сертификата имеет контроль над доменом.
• Проверка организации. Это подтверждает, что пользователь сертификата имеет контроль над доменом, а базовая информация об организации (бизнесе) является правильной, как указано в сертификате.
• Расширенная проверка: это подтверждает, что пользователь сертификата имеет контроль над доменом, информацией об организации, физическим местоположением и что организация легально существует.

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

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

• Сертификаты с одним именем: это может использовать компания, использующая только одно доменное имя (это наиболее распространенный тип). Он охватывает одно доменное имя (example.com), но не охватывает субдомены, кроме www
• Сертификаты с подстановочными знаками. Компания, использующая одно доменное имя, которое также использует субдомены, будет нуждаться в таком типе сертификата безопасности (example.com, location.example.com, payment.example.com, login.example.com).
• Унифицированные / Многодоменные сертификаты (SAN): у некоторых компаний есть несколько различных доменных имен из-за брендов, местоположений или языков. Этот сертификат позволит одной компании вести список проверенных доменов, а не иметь отдельные сертификаты для каждого веб-сайта. (example.com, example.org, example.co.uk, otherexample.com)

Выделенный IP-адрес или нет

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

Установка сертификата

Процесс установки сертификатов безопасности будет варьироваться в зависимости от нескольких факторов (хост, программное обеспечение веб-сервера и т. Д.). Команда, которая обслуживает сервер, должна профессионально установить сертификат. Если вы делаете это самостоятельно, процесс довольно прост, но может быть пугающим:

• Создать запрос на подпись сертификата (CSR)
• Запросить актуальный сертификат
• Установить сертификат на сервер

Тестирование сертификата

Обеспечение сертификата и установки прошло на самом деле довольно просто.

Проверка работоспособности сертификата

После правильной установки сертификата вы сможете перейти на одну из своих веб-страниц и перейти к нему, используя «https: //» и «http: //». Если ваша веб-страница - example.com, вы должны иметь возможность перейти к «https://example.com» в веб-браузере, и адрес должен работать. В веб-браузере должно отображаться указание, например зеленый замок, который означает, что веб-страница защищена. Он не должен давать никаких предупреждений, таких как «небезопасно».

Если это работает, это здорово! Это, однако, не означает, что ваш сайт теперь в безопасности. Это только означает, что ваш сайт теперь может быть безопасным.

Тестовый сертификат на совместимость и прочность

То, что вы можете видеть свои страницы без ошибок, не означает, что вы находитесь в открытом виде. Протестируйте свой сертификат для всех типов сценариев, и ситуации можно выполнить с помощью Инструмент Qualsys Это бесплатный инструмент тестирования ваших сертификатов / настроек сервера, который оценивает ваше решение (попробуйте получить A +).

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

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

Доступ к разработке

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

Команда разработчиков или кто-то, кто позаботится об этом, или ваш сервер будут знать об этом с надеждой. На всякий случай, вопрос, чтобы задать это ...

«Как мы можем протестировать сертификат до перенаправления трафика?»

Ответ на этот вопрос будет либо:

• Мы сможем протестировать его вживую, используя наши текущие настройки
• Нам нужно настроить сервер разработки, чтобы протестировать его

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

4. Перенаправления

Редирект перемещает посетителя с одной страницы на другую. При посещении первой страницы перенаправления сообщают всем посетителям, что существует новая страница, на которую можно перейти.

В случае обеспечения безопасности веб-сайта перенаправление перейдет с версии страницы «http: //» на версию страницы «https: //».

После установки сертификата безопасности ваш веб-сайт, вероятно, будет доступен с использованием «http» и https », но версия, о которой Google знает, - это« https ». Это означает, что весь ваш трафик Google направляется на текущие адреса.

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

Где находятся настройки перенаправления?

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

• Apache - файл конфигурации или файл .htaccess
• NGINX - запись блока файлового сервера конфигурации
• Litespeed - файл конфигурации, файл .htaccess или панель администратора

Какие перенаправления следует использовать?

В идеале весь трафик должен перенаправляться с небезопасных адресов http на защищенные адреса https. Часто это достигается одной инструкцией по перенаправлению.

Инструкция в основном гласит: «Весь трафик на http должен идти на защищенные версии страницы».

301 перенаправление

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

Вот примеры общих кодов перенаправления 301 для перенаправления страниц http для использования https…

Apache / .htaccess

RewriteEngine On
RewriteCond% {HTTPS} off
RewriteRule ^ (. *) $ Https: //% {HTTP_HOST}% {REQUEST_URI} [L, R = 301]

NGINX

сервер {
слушать 80;
имя_сервера domain.com www.domain.com;
return 301 https: //domain.com$request_uri;
}

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

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

Ваш сайт считается «безопасным», когда эти три вещи верны:

• Ваш сервер способен обслуживать безопасный трафик (адреса https)
• Ваш веб-трафик перенаправляется на эти защищенные адреса
• Ресурсы на этих страницах вызываются из безопасного источника (нет смешанный контент )

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

5. Проверка

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

Одной из самых больших проблем, с которыми мы столкнулись, были проблемы с кэшированием, которые могут действительно испортить то, что, по вашему мнению, произойдет, когда вы «щелкнете по переключателю» (сделайте так, чтобы ваши перенаправления включались).

Кэширование

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

Если ваш сайт использует систему кеширования, важно знать процесс «очистки кеша».

Иногда решение для кэширования также будет кэшировать инструкции по перенаправлению, и если эти кэши не очищены, вы можете столкнуться с неожиданным поведением, которое может повлиять на вас и, вероятно, сбить вас с толку.

При экспериментировании с кешем настоятельно рекомендуется посмотреть заголовки http с помощью инструмента или среды тестирования и протестировать некоторые страницы. Убедитесь, что вы видите перенаправления, а не предыдущие версии.

Это будет важным шагом для обеспечения того, чтобы все ваши перенаправления были просмотрены Goolgebot в том виде, в каком вы хотите, чтобы они выглядели (почти во всех ситуациях перенаправления будут 301 перенаправлениями с http на https версию страницы).

Переключатель

Когда перенаправления активны, трафик на ваш сайт будет перенаправлен на защищенную (https) версию ваших страниц, и ваш сайт теперь будет в безопасности.

На данный момент вы завершили технические шаги, необходимые для защиты вашего сайта, но важные вопросы для SEO еще впереди.

6. Мониторинг реакции Google

Действия Google

Теперь это часть, где Google начинает реагировать на ваши изменения. Это включает:

• открытие
• Глубокий ползать
• индексирование

Открытие Google

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

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

Это на самом деле начинает большую активность. Когда Goolgebot обнаружит, что некоторые из ваших страниц изменены, он начнет интенсивно сканировать ваш сайт. На самом деле это можно контролировать, посмотрев на Отчет по статистике сканирования в поисковой консоли Google.

По мере того как Google обнаруживает все больше и больше страниц, он будет сканировать ваши страницы снова и снова, что приведет к резкому увеличению активности.

Goolgebot Deep Crawl

Поскольку Goolgebot начинает интенсивно сканировать ваш сайт, вы можете ожидать несколько дней высокой активности, а затем (надеюсь) постепенного снижения активности, что в двух словах означает, что Google имеет:

1. Видел изменения (открытие)
2. Изучил изменения (глубокий обход)
3. Сейчас находит все меньше и меньше неоткрытых изменений
4. Вернулся к нормальной деятельности

Это хорошо. Потому что скорость, с которой вы начнете видеть свои URL-адреса «https» в результатах поиска Google, начнется уже сейчас.

Google индексация

Индекс Google - это то, что заполняет результаты поиска Google. Когда вы думаете о странице результатов поиска Google, вы видите список заголовков, описаний и URL веб-страниц, которые, по мнению Google, имеют отношение к вашему поиску.

Последний этап успешной миграции HTTPS с точки зрения SEO заключается в том, чтобы URL-адреса в результатах поиска Google отражали безопасность ваших страниц. Это указывает на то, что в URL-адресах результатов поиска Google используется «https: //», а не «http: //».

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

Короче говоря, SEO и ранжирование не принесут пользы, пока вы не увидите результаты безопасного поиска в Google.

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

Разница между успехом и неудачей здесь может быть месяцами ожидания, чтобы это произошло.

7. Оптимизация

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

В этом руководстве будут кратко рассмотрены следующие оптимизации:

• Спектакль
• Перенаправление
• Веб сервер
• HSTS

Производительность (насколько быстро загружаются ваши веб-страницы)

Обеспечение безопасности вашего сайта добавляет задач и времени к тому, что делает ваш веб-сервер для отображения ваших веб-страниц.

В большинстве случаев эти дополнительные задачи не сильно влияют на производительность, но есть действительно хороший способ узнать, есть ли у вашего сервера проблемы. В отчете Crawl Stats о поисковой консоли Google, о котором мы упоминали выше, есть три аспекта сканирования, представленные с использованием трех разных графиков. Последний график отчета (с зеленой линией) показывает, сколько времени требуется Goolgebot для извлечения ваших страниц.

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

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

Если у вас возникают проблемы с производительностью, вам может потребоваться более сильный пакет хостинга, или вашему веб-серверу могут потребоваться некоторые обновления и настройки (см. Веб-сервер ниже).

Цепочки перенаправления

Одна из наиболее распространенных проблем, обнаруживаемых компаниями после перехода по HTTPS, - странные цепочки перенаправления. Цепочка перенаправления - это, по сути, веб-страница, которая перенаправляется более одного раза без необходимости.

Пример: посетитель переходит на http://example.com, но затем перенаправляется на http://www.example.com, но эта страница перенаправляется на https://example.com, который, к сожалению, затем перенаправляется на https: / /www.example.com, и хотя эти перенаправления происходят в мгновение ока, они могут иметь негативные последствия для производительности, индексации и SEO.

Настоятельно рекомендуется обеспечить, чтобы такие цепочки перенаправления не появлялись на ваших веб-страницах.

Веб сервер

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

• Убедитесь, что ваше программное обеспечение обновлено
• Убедитесь, что вы правильно выбрали, какие наборы шифров используются

Обновление программного обеспечения сервера

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

Использование Cipher Suite

Наборы шифров являются важной частью взаимодействия между веб-браузером и вашим веб-сервером.

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

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

Улучшение безопасности с помощью HSTS

HSTS расшифровывается как «HTTP Strict Transport Security». HSTS - это способ сообщить браузерам, что доступ к вашим веб-страницам возможен только с использованием HTTPS.

Причину важности этого можно проиллюстрировать на общем примере старых ссылок. Прежде чем ваш сайт был защищен, у вас были ссылки в Интернете, которые указывали на ваши веб-страницы. Эти ссылки использовали «http: //», и поэтому, когда пользователь нажимает одну из этих ссылок, веб-браузеры переходят на этот небезопасный URL-адрес, а затем следуют перенаправлением на защищенную страницу.

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

Безопасность

Чтобы попасть на ваши защищенные страницы, пользователь должен получить доступ к небезопасной странице перенаправления (чтобы увидеть перенаправление), прежде чем попасть на защищенную страницу.

Спектакль

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

HSTS решает обе проблемы

Правильно настроив HSTS, вы сможете избежать этих проблем. По сути, он удалит перенаправление из уравнения, потому что вы явно указали браузеру никогда не обращаться к вашему домену, используя «HTTP». Это означает, что в описанной выше ситуации со старой ссылкой веб-браузеры никогда не получат доступ к «http: //» версии страницы, чтобы увидеть перенаправление. Вместо этого он просто перейдет прямо к «https: //» версии URL-адреса без необходимости перенаправления, чтобы сказать это.

Внедрение HSTS

Есть два основных шага, необходимых для полного получения выгоды от HSTS.

• Добавление заголовка HSTS (Strict-Transport-Security)
• Добавление вашего домена в список предварительной загрузки

Первый шаг - добавление заголовка. Заголовок выглядит так:

Строгая транспортная безопасность: максимальный возраст = 63072000; IncludeSubdomains; предварительная нагрузка

В заголовке указывается период времени, в течение которого инструкция действительна не менее года (max-age = 63072000), и что домен и любые поддомены должны быть предварительно загружены.

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

Страница списка предварительной загрузки Вот , Подробности, которые ваша команда разработчиков должна реализовать с умом, также можно найти на этой странице.

Использование заголовков безопасности

Мы только что упомянули HSTS, выше которого один пример заголовка безопасности (Strict-Transport-Security). Есть еще несколько вариантов на выбор.

• Content-Security-Policy
  Защищает сайты от XSS-атак. Добавив в белый список источники утвержденного контента, вы можете запретить браузеру загружать вредоносные объекты.
• X-XSS-Protection
  Настраивает межсайтовый скриптинг.
• X-Frame-Options
  Защищает от перехвата кликов, не позволяя вашим веб-страницам «подставляться» или использоваться на других доменах.
• Referrer-Полис
  Политика реферера позволяет сайту контролировать, сколько информации браузер включает в себя в плане отслеживания.
• X-Content-Type-Options
  Останавливает браузеру попытку MIME-прослушивания содержимого.

Похожие

Комментарии