10 распространенных ошибок SEO при переключении на HTTPS

1. Использование перенаправления 302
2. Не обновляет старые перенаправления
3. Не обновляет канонические теги
4. Неспособность обновить внутренние ссылки
5. Не ожидая, как ваш провайдер SSL развернет
6. Конфликты с CMS
7. Ошибка обновления CDN
8. Не удается обновить важные сторонние ресурсы. (например, карты сайта XML)
9. Не придерживается существующих канонических URL-адресов в перенаправлениях.
10. Только защищенная часть сайта.
11. Вывод: спланируйте и протестируйте все.

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

Большая часть риска SEO, связанного с переключением на HTTPS, является результатом ошибок, допущенных во время процесса перенаправления. Это верно для изменения любой структуры URL, однако, особые препятствия часто возникают при изменении на уровне протокола. Ниже приведены 10 распространенных ошибок, которые я видел в течение многих лет, помогая клиентам внести эти изменения и исправить их ошибки. Вы должны помнить обо всех ниже перечисленных возможных проблемах. А также тщательно протестируйте свою реализацию перед запуском.

Использование перенаправления 302

Перенаправление 302 означает временное перенаправление. Где 301 означает постоянное перенаправление. При перенаправлении URL важно использовать 301, иначе Google и другие поисковые системы могут не следовать или применять те же сигналы к новым URL. Это распространенная ошибка людей, которые не практикуют SEO. Однако сделать эту ошибку очень легко, если вы опытный SEO. Это связано с тем, что директивы htaccess и другие функции сервера чрезвычайно похожи друг на друга. Я сам сделал эту ошибку до того, как занялся SEO около 8 лет. Всегда дважды проверяйте правила перенаправления htaccess, чтобы убедиться, что вы применяете правильные перенаправления.

Не обновляет старые перенаправления

Предположим, что когда ваш сайт впервые запустился, в структуру вашего URL-адреса входило «www». Однако, возможно, через год вы, возможно, решили удалить «www». Для этого вы могли использовать перенаправление 301 в состояние без www. Теперь вы решили переключиться на https и настроить перенаправления на версию HTTPS. Если вам не удастся обновить исходные перенаправления с версии «www», то вы случайно создали цепочку перенаправления из структуры URL, с которой первоначально был запущен сайт. Это означает, что любые входящие ссылки, которые были приобретены в течение первого года запуска сайта, вероятно, теряют значительную долю ссылок, потому что эти ссылки должны пройти через второе перенаправление, чтобы добраться до версии HTTPS.

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

Однажды я нашел клиента, который потерял около 80% своего профиля обратной ссылки из-за этого сценария.

Не обновляет канонические теги

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

Неспособность обновить внутренние ссылки

Многие SEO-разработчики и веб-разработчики предполагают, что при наличии перенаправлений им не нужно обновлять внутренние ссылки, указывающие на новые URL-адреса HTTPS. Это проблематично, поскольку большинство современных веб-браузеров обнаруживают, что на странице есть ссылки на незащищенные страницы в одном домене, и могут выдавать ошибку при посещении страницы. Неспособность обновить внутренние ссылки также создает перенаправления по всему сайту по всем URL-адресам, по которым сканер попадает на каждую страницу. Несмотря на то, что Google утверждает, что перенаправления 301 не влияют на равенство ссылок, вполне вероятно, что если тысячи ссылок не будут обновлены в масштабе, это повлияет не только на потерю равенства ссылок, но и усугубит и, возможно, приведет к сокращению бюджета сканирования Google для домена. из-за дополнительной работы по обработке перенаправлений. Все внутренние ссылки должны указывать непосредственно на HTTPS-версию сайта.

Не ожидая, как ваш провайдер SSL развернет

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

Конфликты с CMS

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

Ошибка обновления CDN

Многие сайты с высоким трафиком используют сети доставки контента для размещения изображений и других сторонних ресурсов. Эти URL-адреса должны быть обновлены до версий HTTPS, чтобы обеспечить безопасный просмотр страниц, а также для обеспечения правильных сигналов для Google и любых канонических URL-адресов. Это особенно важно для CDN, которые используют маску субдомена, например cdn.example.com

Не удается обновить важные сторонние ресурсы. (например, карты сайта XML)

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

Не придерживается существующих канонических URL-адресов в перенаправлениях.

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

Только защищенная часть сайта.

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

Вывод: спланируйте и протестируйте все.

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

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

[ кредит изображения ]

Похожие

Комментарии