Jak przejść na SSL bez wpływu na PageRank?


92

W Stack Exchange pracujemy nad przeniesieniem całego ruchu na SSL. Powodem, dla którego nie robimy tylko zalogowanych użytkowników, jest to, że jedna strona podziału logowania będzie za każdym razem przekierowywana przez Google. Dzieje się tak, ponieważ Google ma tylko wyniki http://lub https://wyniki, a nie oba. Oprócz budowy infrastruktury SSL ( szczegóły tutaj ), pozostaje nierozwiązane pytanie:
jak najlepiej przejść na SSL?

Oto odpowiednie fragmenty naszego planu (testowanie w małych witrynach, przejście do stackoverflow.com):

  1. Przygotuj SSL włączony / włączony (ale nie połączony z) we wszystkich domenach
  2. Zacznij renderowania tylko<link rel="canonical"> jakohttps://
  3. Zacznij wysyłać 301 dla wszystkich http://żądań do https://(z naszych domen ... oczywiście nie możemy nic zrobić z wszystkimi istniejącymi linkami do nas)
  4. Po okresie przejściowym ustaw wszystkie pliki cookie użytkownika jako secure

Tak więc w grze końcowej cała treść jest dostarczana za pośrednictwem protokołu SSL i wszystkie żądania HTTP są przekierowywane. Przede wszystkim zależy nam na tym, jak wpłynie to na PageRank w naszych witrynach. Bardzo zależy nam na ruchu pochodzącym z Google i chcemy się upewnić, że nie zanurkuje, ponieważ zaczynamy zapewniać większe bezpieczeństwo naszym użytkownikom.

Jedyne fragmenty, które tu znalazłem, które wydają się istotne, to komentarz pracownika Google na starsze pytanie o podobnej treści :

@Frank Tak, jestem pewien, że Google traktuje adresy URL HTTP i HTTPS jako osobne adresy URL do indeksowania, indeksowania i rankingu (współpracuję z zespołem wyszukiwarki Google tutaj). Dokonanie kanonizacji z przekierowaniem 301, jak wspomniałeś, to świetny sposób na rozwiązanie tego :) - John Mueller 23 października 2010

i jedyny film webmasterów, jaki udało mi się znaleźć: czy przejście na HTTPS może zaszkodzić rankingowi? Film nie ma solidnej odpowiedzi, nie na której i tak opieram przyszłość firmy.

Czy nasz plan przejścia jest najlepszym sposobem na przeniesienie SSL, przynajmniej z punktu widzenia SEO? Jeśli są jakieś nowsze lub konkretne porady dotyczące tego, jak taki ruch wpływa na ranking Google, chcielibyśmy o tym usłyszeć.


3
Czy warto migrować najpierw jedną z mniejszych witryn SE, aby ocenić wpływ na pozycję strony, zanim zrobisz to dla biggie?
Kirk Woll,

2
@Jeff albo pokazujemy, że użytkownicy http i authed zostali wyrzuceni do https (bolesne przekierowanie dla każdego trafienia z wyszukiwania) lub wyświetlamy https w wynikach wyszukiwania google, co oznacza, że ​​skutecznie przestawiliśmy wszystkich na https, tak jak i tak planujemy ( ale żadnych przekierowań, przynajmniej pochodzących z Google). Niezależnie od Google wyświetla będzie 95-99% przypadek ruchu, więc muszą iść pełne https uniknąć przekierowania w dłuższej perspektywie. Ponadto, zgodnie z logami, wygląda na to, że Google próbuje zaindeksować nas na https, niezależnie od tego, czy go reklamujemy, czy nie ...
Nick Craver

2
@Kirk Oczywiście, o to mi chodziło z testowaniem małych witryn w nawiasach. Plan polega na wypróbowaniu najpierw zestawu mniejszych witryn.
Nick Craver

2
@IlmariKaronen - Tak, nie jest dla nas bolesne ... bolesne dla użytkowników , w miejscach takich jak Australia, których czas ładowania strony może wynosić nawet dodatkową sekundę. Jest często znacznie wyższy niż na urządzeniach mobilnych, nawet tutaj, w USA. Nasze strony z pytaniami wyświetlają się w czasie krótszym niż 50 ms (przez większość czasu o połowę), więc każde rozwiązanie, które zwiększa opóźnienie, ma ogromny wpływ na czas ładowania strony. Procentowo, prawie całe opóźnienie ładowania, które zobaczysz przeglądając naszą sieć, to transmisja, więc znaczny wzrost podwoiłby liczbę żądań dla 95-99% obciążenia strony.
Nick Craver

1
@Nick: Czy naprawdę byłoby to 95% +? Widzę tę część wszystkich twoich próśb pochodzących od Google, ale na pewno odsetek musi być znacznie niższy dla zalogowanych użytkowników? To powiedziawszy, zgadzam się, że pełna sekunda dodatkowego opóźnienia zaczyna się kwalifikować jako „bolesna”. (Ty mógłby rozwiązać ten problem i poprawę opóźnienia w ogóle, poprzez kilka geograficznie rozproszonych serwerów proxy front-end, ale to może być dzieje się nieco poza zakres tego pytania tutaj ... nadal, to działa na Wikipedii. )
Ilmari Karonen,

Odpowiedzi:


34

Proponowane rozwiązanie jest najlepszym rozwiązaniem z punktu widzenia SEO. Unikasz powielania treści za pomocą kanonicznego adresu URL, a przekierowanie 301 przeniesie większość PageRank ( niewielka ilość zostanie utracona w przekierowaniu ). Dodatkowo dzięki sile stron stosu przepełnienia stosu w Google byłbym bardziej niż zaskoczony, gdybyś zauważył jakiekolwiek wahania w swoich rankingach. Mniejsze witryny widziały okres przejściowy w swoich rankingach, podczas gdy Google doganiało ich nowe adresy URL, ale nie przewiduję, że tak się stanie z przepełnieniem stosu.

Do Twojej wiadomości, John Meuller, pracownik Google, który zacytowałeś, jest tutaj aktywnym członkiem . Przy odrobinie szczęścia da nam swoje zdanie na ten temat.


16
Tak, myślę, że to całkiem rozsądne podejście. FWIW odbyła się podobna dyskusja w Google+, gdzie przeanalizowaliśmy niektóre szczegóły: plus.google.com/106413090159067280619/posts/ZZVAS65mmw4 . Rozdzielenie rel = kanoniczne i przekierowania w czasie prawdopodobnie nie jest konieczne, ale może ułatwić wcześniejsze wychwycenie problemów. Jedną z rzeczy, o których nie wspomniałeś, jest HSTS, co w pewnym momencie może być warte rozważenia.
John Mueller

Dzięki naszemu zespołowi dla was obojga jesteśmy teraz znacznie bardziej swobodnie w kwestii przejścia po stronie SEO. Zostało nam jeszcze kilka tygodni pracy, ale wciąż pracujemy nad zmianą HTTPS.
Nick Craver

11

Około rok temu wystąpił błąd w kodzie generującym bezpośredni link do mojej witryny WordPress, który generuje około 70% ruchu z Google. Tag kanoniczny zaczął używać formatu WP krótkiego adresu URL zamiast formatu zwykłego.

Dwa tygodnie później znalazłem błąd, gdy zauważyłem, że moje adresy URL pokazują się dziwnie w indeksie Google. Zamiast pełnego /999999/post-url-format-like-this/wyniku, pokazywał ?post_id=99999(lub coś podobnego).

Nie było żadnych zmian w ruchu drogowym.

Błąd został naprawiony, tag kanoniczny poprawnie ustawiony ponownie, a około tygodnia później Google dostosowało wszystkie indeksowane linki z powrotem do normalnego formatu. Naprawdę bezbolesne.

Tak więc, zgodnie z moim doświadczeniem, twój plan powinien być:

  1. Zamiast tego zmień znacznik kanoniczny, tak aby wskazywał adres URL HTTPS.
  2. Google automatycznie zaktualizuje wszystkie wyniki w indeksie. Może to potrwać kilka tygodni i nie wymaga przekierowań 301. I ... 95% twojego ruchu będzie korzystało z SSL.
  3. Przekieruj zalogowanych użytkowników, którzy klikają z innej witryny.

Ponieważ przekierowania 301 usuwają część stronicowania, nie widzę sensu w ich natychmiastowym użyciu, zwłaszcza że znacznik kanoniczny powinien zająć się indeksem Google.


5

Uważam, że Google plasuje pierwszy widziany adres URL, jeśli powinien to być krótki adres URL, HTTP lub nawet HTTPS, chyba że użyto linku kanonicznego, więc są to osobne pozycje w rankingu, więc przejście 301 spowoduje utratę części soku podczas przejścia.

Jednak, jak powiedział John, jego wątpliwość może zaszkodzić stosowi, ponieważ stos ma mnóstwo autorytetu i zaufania do Google.

Z tego, co wiemy, Google może nawet zwiększyć rankingi stosów do korzystania z protokołu SSL, ponieważ dzięki temu strona jest bezpieczniejsza dla użytkowników, co w efekcie zwiększa wygodę użytkowania, w którą Google mocno wierzy. Czy to spekulacja, ale czy warto mieć nadzieję? :)

Również:

Matt Cutts z Google powiedział w komentarzu Hackera, że ​​ci, którzy są zainteresowani przejściem całej witryny z HTTP na HTTPS, powinni to zrobić.


6
Nie sądzę, aby w ogóle pomocne było spekulowanie, że rankingi mogą wzrosnąć przy użyciu protokołu SSL, ponieważ nie masz żadnych zdalnie wiarygodnych informacji na ten temat.
DisgruntledGoat

Myślę, że Brains at Stack może ustalić, co oznaczają spekulacje, i rozważyć, co jest pomocne, a nie pomocne. Dzięki za wskazanie oczywistego;)
Simon Hayter

1
Chodzi mi o to, że są to spekulacje oparte na niczym. Równie dobrze możesz dodać do swojej odpowiedzi: „Z tego co wiemy, Google wyśle ​​ciężkie przedmioty do twojego centrum danych, aby je zniszczyć”.
DisgruntledGoat

2
To spekulacje oparte na przekonaniach, że a) strony SSL są lepsze dla użytkowników i b) Google ma historię promowania witryn, które są dobre dla użytkowników.
Spongeboy

5

Niedawno przeniosłem kilka moich stron na SSL i nie wpłynęło to pozytywnie ani negatywnie na PageRank. Postępowałem zgodnie ze wszystkimi wskazówkami Google, które są w zasadzie takie, jak opisano:

  1. Spraw, aby Twoja strona działała płynnie dzięki HTTPS. Moją największą potrzebną zmianą było używanie tylko odnośników względnych i względnych protokołu. Na przykład: href = "page.html", a jeśli to konieczne href = "// www.example.com/"
  2. Dodaj tagi rel = „canonical” i skieruj je na adres HTTPS strony
  3. Użyj przekierowań 301 dla wszystkich żądań HTTP, aby wysłać je do HTTPS

Skonfiguruj zarówno strony HTTP, jak i HTTPS w Google Webmaster, i dokładnie je monitoruj.


4

Byłem częścią podobnego przejścia na stronie o umiarkowanym ruchu, choć z tą różnicą: wszystkie adresy URL zostały zmienione i nie wprowadzono żadnych przekierowań 301.

Przez około miesiąc uważnie monitorowałem wpływ na ranking Google, a dla większości słów kluczowych uzyskano 2-3 pozycje, chociaż jestem całkiem pewien, że było to całkowicie spowodowane lepszym SEO.
Nie widziałem żadnych zmian, które można racjonalnie przypisać tylko HTTPS.

Twój plan wydaje się być na miejscu, chociaż jestem trochę rozdarty tym drugim krokiem, osobiście wybrałbym prosto za 301.

Dlaczego nie przetestować testu A / B z niewielką liczbą najlepiej fałszywych pytań i sprawdzić ich wpływ?


1
Rozważaliśmy podejście do testowania A / B, ale problem z ocenami jest zmienny z innych powodów, więc nadal nie widzimy zbyt wielu konkretnych danych z tak niekontrolowanego eksperymentu. Biorąc to pod uwagę, wydaje się, że lepiej jest przeprowadzać testy na poziomie witryny, ponieważ to jest faktyczna zmiana, którą i tak chcemy wprowadzić.
Nick Craver
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.