Одит и критика на уебсайта: Преглед на уебсайт № 10 (5 броя)

Помислете за страница, http://example.com, които могат да бъдат разглеждани както публично, така и когато потребителят се удостоверява. Сега да предположим, че активирате HTTPS за всяка страница, когато потребителят влезе във вашия уебсайт, но само когато е влязъл. Вашата страница, http://example.com сега става https://example.com за всички влезли потребители. Ако влезлият потребител хареса страницата ви и реши да се свърже с нея чрез публикация в блог или уебсайт в социална медия, има голяма вероятност те да използват HTTPS версията на URL адреса.

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

Какво трябва да се случи, ако потребител стигне до HTTPS URL адреса, но не е влязъл или няма акаунт? Трябва ли да има пренасочване към HTTP версията? Ако да, как бихте се справили?

Моят инстинкт е, че за всички страници, които могат да се разглеждат както публично, така и докато са влезли, страницата първо трябва да открие дали потребителят е влязъл. Ако е влязъл, той остава HTTPS или използва 302 пренасочване от HTTP версията към HTTPS. Ако потребителят не е влязъл и той пристигне до HTTPS версията на URL адреса, той използва 301 пренасочване към HTTP версията. Бих приветствал обаче по-елегантно или ефективно решение.

редактиране: Предполагах, че ако даден потребител е влязъл, всеки URL трябва да бъде HTTPS (или поне това трябва да е опция), но тъй като направих малко повече изследвания, може би това предположение е грешно. Начинът, по който виждам хората, които го прилагат, е, че те активират HTTPS само за страници, които изпращат и получават чувствителни данни: влизане, плащане в количката, управление на потребителския профил и др.

Очевидно Google Mail дава възможност на потребителите дали да използват HTTPS на всяка страница чрез настройка в потребителския профил. Това със сигурност е опция, но все пак ще трябва да разгледам поведението на публично достъпните страници за всички състояния на удостоверяване.

Тъй като изграждам система за управление на съдържанието, която ще се използва от други хора, трябва да се уверя, че съм я направил правилно. Какви настройки трябва да са на разположение на собственика на сайта? На този етап мисля да разгледам подробно контрола върху всяка страница (независимо дали е защитена със SSL или не), а след това и върху целия сайт. Даването на това ниво на контрол обаче може да е грешка, ако хората не разбират всички проблеми и в крайна сметка могат да причинят проблеми със сигурността. Това може би е първият брой. Какви са подходящите нива на контрол и какви са интелигентните настройки по подразбиране? Второто е как страниците трябва да се държат за потребителя. От гледна точка на SEO мисля, че или процесът, който описах по-горе, или използването на rel='canonical' (както jmb предлага) би работило, но от съществено значение е и заковаването на поведението на страницата, така че тя да е сигурна и безпроблемна.

Може да искате да разгледате <link rel='canonical' />. Вижте http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html. В коментарите някой от Google казва, че може да се използва за http / https въпроси.

Предупреждение: Не съм сигурен дали и до каква степен <link rel='canonical' /> се поддържа от търсачки, различни от Google, Yahoo и Bing. Ако други двигатели са важни за вашия сайт, трябва да проверите техните често задавани въпроси.

От гледна точка на потребителя: Пренасочването на потребител, който е влязъл от http на https, е несигурно (ако разбирам правилно, че искате да създадете безпроблемен процес). В момента, в който той пристига на сайта (преди пренасочването), той ще прехвърли сесийната си бисквитка чрез http, което го прави уязвим за отвличане на сесия. Такъв потребител трябва да влезе отново от https страница.

В случай, че потребителят пристигне чрез https и не е влязъл в системата: В зависимост от обстоятелствата (размер на сайта, очакван обем на трафика, очакван брой пъти това ще се случи), можете просто да го задържите на https. Вижте също HTTPS за целия сайт и https://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https за дискусии относно пускането на сайт в https (отчасти във вашия случай).

Актуализация:

Какви са подходящите нива на контрол и какви са интелигентните настройки по подразбиране?

Подходящи нива на контрол:

  • Сигурно (https включен, включително страницата за влизане и всичко от там нататък)

и

  • Несигурен (без https).

Няма средно положение, ако искате да го „разберете правилно“. Вижте също http://paulmakowski.wordpress.com/2009/07/20/http-post-https-bad-idea/ и https://stackoverflow.com/questions/274274/is-it-secure-to-submit -от-a-http-форма-до-https

По подразбиране: Зависи кои са вашите клиенти.

  • Мислех и за това като опция. Причината, поради която не бях сигурен в това, е, че макар да се занимава с проблема със SEO, той не се отнася до това как страницата трябва да се държи за потребителя. някакви мисли?
  • Добра точка, актуализирах отговора си.
  • Регенерирането на сесията при всяко зареждане на страница би ли решило проблема с отвличането на сесията?
  • Благодаря. Още един въпрос: Как мислите, че хората биха разгледали CMS, която изисква SSL сертификат, ако приемат регистрация на потребител?
  • Мисля, че много зависи от целевата аудитория. Банките биха възприели това като изискване, дори в несъществени области, които не включват финансова информация. Една организация с нестопанска цел вероятно ще се намръщи на разходите и допълнителната сложност.

Няма 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 Имате ме там. Bludgeon търсачката с тъп обект може би?

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

301 може да променя дефинициите на отметки, не бих искал постоянно 301 моите потребители наоколо.

Също така се уверете, че http версията включва формуляр за вход, така че потребителят може бързо да се върне към https версията.

Сега големите въпроси са - ако данните са видими през http, защо имате https версия? какви данни криете с https криптирането, което още не е там?

Можете да създадете зона за членство в https или да публикувате формуляри на https url от http страницата или много други опции, които не включват наличието на целия сайт както в http, така и в https.

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

  • Предполагам, че предполагах, че ако даден потребител е влязъл, всеки URL трябва да бъде https, но тъй като направих малко повече изследвания, може би това предположение е грешно. Начинът, по който виждам хората, които го прилагат, е, че те активират https само за страници, които изпращат и получават поверителни данни: влизане, плащане в количката, управление на потребителския профил и др. Тъй като изграждам система за управление на съдържанието, която ще се използва от други хора, трябва да се уверя, че съм я направил правилно.

е работил за вас: Charles Robertson | Искате ли да се свържете с нас?