HTTP to HTTPS: руководство по SEO для защиты сайта

1. Зачем переходить на HTTPS?
2. Защищает ли HTTPS мой сайт?
3. Переключение с HTTP на HTTPS
4. Общие проблемы с миграциями HTTPS
5. Редиректы заслуживают отдельного раздела
6. Заключительные мысли по HTTPS

Назад, когда я написал статью: Почему все должны переходить на HTTP / 2 «Это было сделано для того, чтобы привлечь внимание к удивительному обновлению протокола, которое, как я думал, было легкой победой, чтобы сделать сайт быстрее.

С тех пор я говорил с сотнями владельцев бизнеса и SEO-специалистов об обновлении, выполнил десятки обновлений и решил еще десятки проблем. Я понял, что для владельцев бизнеса и для SEO все еще есть одно большое препятствие: HTTPS. Суть HTTP / 2 в том, что большинство браузеров поддерживают этот новый протокол только через безопасное соединение, что означает, что вам нужно перенести свой сайт на HTTPS.

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

Тем не менее, несмотря на все эти усилия по созданию более безопасной сети, факт остается фактом: Менее 0,1% сайтов защищены ,

Кажется, что все пытаются максимально упростить переключение, устранив препятствия для входа, такие как стоимость. Давайте зашифруем предлагает бесплатные сертификаты (Sidenote: я очень удивлен, что в Google Chrome есть единственная nofollow на их платной спонсорской ссылке после вызова .) Многие хосты веб-сайтов и CDN также предлагают бесплатные сертификаты безопасности, чтобы поощрять людей к переходу, но многие все еще не двигаются.

Зачем переходить на HTTPS?

Google определяет несколько причин для перехода на HTTPS в своем руководстве по миграции веб-сайтов:

Данные, отправляемые с использованием HTTPS, защищены с помощью протокола безопасности транспортного уровня (TLS), который обеспечивает три ключевых уровня защиты:

1. Шифрование. Шифрование обмениваемых данных, чтобы защитить их от перехватчиков. Это означает, что пока пользователь просматривает веб-сайт, никто не может «слушать» их разговоры, отслеживать их действия на нескольких страницах или красть их информацию.
2. Целостность данных. Данные не могут быть изменены или повреждены во время передачи, преднамеренно или иным образом, без обнаружения.
3. Аутентификация. Доказывает, что ваши пользователи общаются с предполагаемым веб-сайтом. Он защищает от атак «человек посередине» и повышает доверие пользователей, что приводит к другим бизнес-преимуществам.

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

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

Переключатель также предотвращает много плохих вещей, например, когда AT & T внедряла рекламу в свои горячие точки , Они не смогли бы внедрить эти объявления на веб-сайте с HTTPS.

Защищает ли HTTPS мой сайт?

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

• Понижение атаки
• Уязвимости SSL / TLS
• Раскаленный, Пудель, Ложа и др.
• Взлом сайта, сервера или сети
• Программные уязвимости
• Атаки грубой силой
• DDOS атаки

Переключение с HTTP на HTTPS

1. Начните с тестового сервера . Это важно, потому что это позволяет вам все сделать правильно и тестировать, не облажаясь в реальном времени. Даже если вы выполняете переключение без тестового сервера, вы почти ничего не можете сделать, с которым вы не сможете восстановиться, но все же лучше иметь план и заранее проверить все.
2. Просканируйте текущий веб-сайт, чтобы вы знали текущее состояние веб-сайта и в целях сравнения.
3. Прочитайте любую документацию относительно вашего сервера или CDN для HTTPS . Я сталкиваюсь со многими забавными проблемами CDN, но это также может быть простым.
4. Получить сертификат безопасности и установить на сервер. Это будет варьироваться в зависимости от вашей среды хостинга и настроек сервера, поэтому я не буду вдаваться в подробности, но этот процесс обычно хорошо документирован.
5. Обновить ссылки в содержании . Обычно это можно сделать с помощью поиска и замены в базе данных. Вы захотите обновить все ссылки на внутренние ссылки, чтобы использовать HTTPS или относительные пути.
6. Обновить ссылки в шаблонах . Опять же, в зависимости от того, как вы развертываете, это может быть сделано с помощью Git или просто Notepad ++, но вы должны убедиться, что ссылки на скрипты, изображения, ссылки и т. Д. Используют либо HTTPS, либо относительные пути.
7. Обновить канонические теги . Большинство систем CMS позаботятся об этом при переключении, но дважды проверьте, потому что это не всегда так.
8. Обновите теги hreflang, если они используются на вашем веб-сайте, или любые другие теги, такие как теги OG. Опять же, большинство систем CMS позаботятся об этом, но лучше всего проверить это на всякий случай.
9. Обновите все плагины / модули / дополнения, чтобы убедиться, что ничего не сломано и что в нем нет небезопасного содержимого. Я обычно вижу внутренний поиск по сайту и пропущенные формы.
10. Специфичные для CMS настройки, возможно, придется изменить . Для основных систем CMS они обычно хорошо документированы в руководствах по миграции.
11. Просканируйте сайт, чтобы убедиться, что вы не пропустили ни одной ссылки и ничего не сломано. Вы можете экспортировать любой незащищенный контент в один из отчетов Screaming Frog, если вы используете этот сканер.
12. Убедитесь, что все внешние скрипты, которые называются, поддерживают HTTPS .
13. Принудительно HTTPS с перенаправлениями . Это будет зависеть от вашего сервера и конфигурации, но хорошо документировано для Apache, Nginx и IIS.
14. Обновите старые перенаправления в настоящее время на месте (и пока вы на нем, вернуть ваши потерянные ссылки от перенаправлений, которые не были сделаны за эти годы). Я упомянул во время части вопросов и ответов Технической панели SEO на SMX West, что у меня никогда не было падения рейтинга сайта или трафика при переходе на HTTPS, и многие люди спрашивали меня об этом. Должна быть должная осмотрительность в отношении перенаправлений и цепочек перенаправлений, поскольку, как я вижу, это наиболее запутано при устранении неполадок при миграции.
15. Просканируйте старые URL-адреса для всех сломанных перенаправлений или цепочек перенаправления, которые вы можете найти в отчете с Screaming Frog.
16. Обновите карты сайта, чтобы использовать HTTPS-версии URL-адресов.
17. Обновите файл robots.txt, включив в него новую карту сайта.
18. Включить HSTS . Это говорит браузеру всегда использовать HTTPS, что исключает проверку на стороне сервера и ускоряет загрузку вашего сайта. Это также может иногда приводить к путанице, поскольку перенаправление будет отображаться как 307. Однако оно может иметь 301 или 302 позади, и вам может потребоваться очистить кеш браузера, чтобы увидеть, какой именно.
19. Включите сшивание OCSP . Это позволяет серверу проверять, отозван ли сертификат безопасности вместо браузера, что не позволяет браузеру загружать или создавать перекрестные ссылки с выдающим центром сертификации.
20. Добавить поддержку HTTP / 2 .
21. Добавьте HTTPS-версию своего сайта ко всем версиям поисковых инструментов для веб-мастеров, которые вы используете, и загрузите в них новую карту сайта с HTTPS. Это важно, поскольку я видел, что сбой трафика неправильно диагностировался, потому что он видел трафик в отбрасывании профиля HTTP, когда трафик в действительности переместился в профиль HTTPS. Еще одно замечание: вам не нужно использовать инструмент смены адреса при переключении с HTTP на HTTPS.
22. Обновите файл отключения, если он у вас был для версии HTTPS.
23. Обновите настройки параметров URL, если они были настроены.
24. Иди живи!
25. В своей аналитической платформе убедитесь, что вы обновляете URL-адрес по умолчанию, если он необходим для обеспечения правильного отслеживания HTTPS, и добавляете примечания об изменениях, чтобы вы знали, когда они произошли, для дальнейшего использования.
26. Обновите ваши социальные доли . В этом есть много моментов: некоторые сети будут передавать счетчики через свои API, а другие - нет. Для этого уже есть руководства, если вы заинтересованы в том, чтобы сохранить ваши доли.
27. Обновите любые платные медиа, электронные письма или кампании по автоматизации маркетинга, чтобы использовать HTTPS-версии URL-адресов.
28. Обновите любые другие инструменты, такие как программное обеспечение A / B-тестирования, тепловые карты и отслеживание ключевых слов, чтобы использовать HTTPS-версии URL-адресов.
29. Контролируйте все во время миграции и проверяйте, перепроверяйте и перепроверяйте, чтобы убедиться, что все идет гладко. Есть так много мест, где что-то может пойти не так, и кажется, что обычно есть несколько проблем, которые возникают при любом переключении на HTTPS.

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

Общие проблемы с миграциями HTTPS

Вот что может пойти не так:

• запрет Google сканировать HTTP-версию сайта или общий обход сайтов (обычно это происходит из-за невозможности обновить тестовый сервер, чтобы разрешить ботов);
• проблемы дублирования контента, с отображением версий HTTPS и HTTP; а также
• разные версии страницы, показывающие по HTTP и HTTPS.

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

Редиректы заслуживают отдельного раздела

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

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

Это определенно не помогает, когда Документация Apache поскольку это не включает 301 и Apache по умолчанию 302. Код ниже должен быть обновлен до R = 301.

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

Иногда даже лучшие из нас терпят неудачу:

Доверяй, но проверяй. Я использую такие инструменты, как Кричащая лягушка а также Ayima Redirect Path проводить быстрые проверки некоторых старых URL-адресов или, с некоторыми манипуляциями Excel, выполнять массовые проверки большого количества URL-адресов и более старых перенаправлений. Это помогает гарантировать, что все перенаправляется правильно и без многократных прыжков.

(См. Раздел «Проверка нашей работы» в « Вернуть потерянные ссылки ”За помощь в воссоздании URL для сканирования.)

Заключительные мысли по HTTPS

Проще говоря, HTTPS не уходит. HTTP / 2, Google AMP и протокол QUIC от Google (который, скорее всего, скоро будет стандартизирован) требует использования браузерами защищенных соединений. Факт остается фактом, что HTTPS сильно продвигается существующими силами, и пришло время переключиться.

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

Мой любимый комментарий на эту тему от Гари Иллиеса, аналитика трендов Google для веб-мастеров:

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

- Гари Иллис (@methode) 18 августа 2015 г.

Мнения, выраженные в этой статье, принадлежат автору гостя и не обязательно относятся к Search Engine Land. Штатные авторы перечислены Вот ,

Об авторе