HTTPS лучшие практики для SEO и юзабилити

8

Рассмотрим страницу, http://example.comкоторую можно просматривать как публично, так и при аутентификации пользователя. Теперь предположим, что вы включаете HTTPS для каждой страницы, когда пользователь заходит на ваш сайт, но только тогда, когда они вошли в систему. http://example.comТеперь ваша страница становится https://example.comдля всех вошедших в систему пользователей. Если этому вошедшему в систему пользователю нравится ваша страница, и он решает дать ссылку на нее через сообщение в блоге или на веб-сайте социальной сети, есть большая вероятность, что он будет использовать HTTPS-версию URL-адреса.

С точки зрения SEO, какова ваша стратегия, чтобы избежать проблем с дублированием контента между двумя URL-адресами?

Что должно произойти, если пользователь заходит по URL-адресу HTTPS, но не вошел в систему или не имеет учетной записи? Должен ли быть редирект на версию HTTP? Если так, как бы вы справились?

Мой инстинкт заключается в том, что для всех страниц, которые можно просматривать как публично, так и во время входа в систему, страница должна сначала определить, вошел ли пользователь в систему. В случае входа она остается HTTPS или использует перенаправление 302 из версии HTTP в HTTPS. Если пользователь не вошел в систему и пришел к URL-версии HTTPS, он использует перенаправление 301 на версию HTTP. Однако я бы приветствовал более элегантное или эффективное решение.

Изменить : я предполагал, что если пользователь вошел в систему, каждый URL должен быть HTTPS (или, по крайней мере, это должен быть вариант), но, как я сделал немного больше исследований, возможно, это предположение было неверным. Я вижу, что люди, реализующие его, используют HTTPS только для страниц, которые отправляют и получают конфиденциальные данные: вход в систему, проверка корзины покупок, управление профилями пользователей и т. Д. Я пытаюсь выяснить, какая модель лучше.

Судя по всему, Google Mail дает пользователям возможность использовать HTTPS на каждой странице с помощью параметра в профиле пользователя. Это, конечно, вариант, но мне все равно нужно учитывать поведение общедоступных страниц для всех состояний аутентификации.

Поскольку я создаю систему управления контентом, которая будет использоваться другими людьми, мне нужно убедиться, что я правильно понял. Какие настройки должны быть доступны владельцу сайта? На данный момент я думаю о гранулярном контроле над каждой страницей (независимо от того, защищена ли она с помощью SSL), а также для всего сайта. Однако предоставление такого уровня контроля может быть ошибкой, если люди не понимают всех проблем и могут в конечном итоге вызвать проблемы с безопасностью. Это, пожалуй, первая проблема. Каковы соответствующие уровни контроля и каковы интеллектуальные значения по умолчанию? Второй - как страницы должны вести себя для пользователя. С точки зрения SEO, я думаю, что либо процесс, который я описал выше, либо использованиеrel="canonical" (как предположил jmb) будет работать, но важно также следить за поведением страницы, чтобы она была безопасной и цельной.

Виртуозы Медиа
источник

Ответы:

6

Вы можете захотеть посмотреть <link rel="canonical" />. См. Http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html . В комментариях кто-то из Google говорит, что его можно использовать для решения проблем http / https.

Предостережение: я не уверен, <link rel="canonical" />поддерживаются ли и в какой степени поисковые системы, кроме Google, Yahoo и Bing. Если другие движки важны для вашего сайта, вы должны проверить их часто задаваемые вопросы.

С точки зрения пользователя: перенаправление пользователя, вошедшего в систему с http на https, небезопасно (если я правильно понимаю, что вы хотите создать цельный процесс). В тот момент, когда он попадает на сайт (до перенаправления), он передает свой файл cookie сеанса через http, что делает его уязвимым для перехвата сеанса. Такой пользователь должен войти снова со страницы https.

В случае, если пользователь приходит по https и не вошел в систему: в зависимости от обстоятельств (размер сайта, ожидаемый объем трафика, ожидаемое количество раз, когда это произойдет) вы можете просто оставить его на https. Также см. HTTPS для всего сайта и /programming/174348/will-web-browsers-cache-content-over-https для обсуждения работы сайта на https (частично в вашем случае).

Обновить:

Каковы соответствующие уровни контроля и каковы интеллектуальные значения по умолчанию?

Соответствующие уровни контроля:

  • Безопасный (https включен, включая страницу входа и все с этого момента)

а также

  • Небезопасно (без https).

Там нет никакого среднего уровня, если вы хотите "сделать это правильно". Также см. Http://paulmakowski.wordpress.com/2009/07/20/http-post-https-bad-idea/ и /programming/274274/is-it-secure-to-submit. -из-а-клиент формы-к-протокол HTTPS

По умолчанию: зависит от того, кто ваши клиенты.

JMB
источник
Я думал об этом как вариант, а. Причина, по которой я не был уверен в этом, заключается в том, что, хотя в нем рассматривается проблема SEO, в нем не рассматривается, как страница должна вести себя для пользователя. Какие-нибудь мысли?
Virtuosi Media
Хороший вопрос, я обновил свой ответ.
JMB
Будет ли восстановление сеанса при каждой загрузке страницы решить проблему перехвата сеанса?
Виртуозы Медиа
Спасибо. Еще один вопрос: как вы думаете, как люди будут просматривать CMS, для которой требуется сертификат SSL, если они примут регистрацию пользователя?
Virtuosi Media
Я думаю, что очень многое зависит от целевой аудитории. Банки будут рассматривать это как требование, даже в непрофильных областях, не связанных с финансовой информацией. Некоммерческая смета, вероятно, будет хмуриться из-за стоимости и дополнительной сложности.
JMB
2

Не существует стратегии SEO для страниц SSL. Часть определения кэширования такова:

If the request is authenticated or secure (i.e., HTTPS), it won’t be cached.

см. учебник по кэшированию

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

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

Талви Ватиа
источник
1
Спасибо, Талви, но я думаю, что вы, возможно, неправильно поняли мой вопрос, который не касался кеширования в браузере. Поскольку поисковые системы сканируют и индексируют страницы https, это означает, что вы сталкиваетесь с проблемами дублирующегося контента, если кто-то ссылается на версию https. Изменение URL не помогает, потому что http и https уже являются двумя разными URL в глазах поисковой системы. С разными URL вы эффективно разделяете свой PageRank. Суть моего вопроса заключалась в том, как можно разработать стратегию, чтобы избежать проблемы дублированного контента. К сожалению, я не думаю, что ссылка на кеширование помогает решить эту проблему.
Виртуозы Медиа
Я согласен с Virtuosi Media - У поисковых систем обычно нет проблем с https: // - URL.
Джон Мюллер
1
@virtuosi Вы меня там нашли. Может, забить поисковик тупым предметом?
Талви Ватиа
2

Редирект 302 не переносит поисковый рейтинг - поэтому вы можете потерять поисковый рейтинг, если наберете 302 своего сайта.

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

Кроме того, убедитесь, что версия http включает в себя форму входа, чтобы пользователь мог быстро вернуться к версии https.

Теперь большие вопросы - если данные доступны для просмотра через http, почему у вас версия https? какие данные вы скрываете с помощью шифрования https, которого еще нет?

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

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

Nir
источник
Я предполагаю, что предполагал, что если пользователь вошел в систему, каждый URL должен быть https, но, поскольку я провел немного больше исследований, возможно, это предположение было неверным. Я вижу людей, которые его реализуют, так как они включают https только для страниц, которые отправляют и получают конфиденциальные данные: вход в систему, проверка корзины покупок, управление профилями пользователей и т. Д. Я пытаюсь выяснить, какая модель лучше. Поскольку я создаю систему управления контентом, которая будет использоваться другими людьми, мне нужно убедиться, что я правильно понял.
Виртуозы Медиа