HTTP till HTTPS: En SEO-guide för att säkra en webbplats. Trots de många fördelarna med att byta till HTTPS har många SEO:er och webbplatsägare inte gjort det. För dem som känner sig skrämda inför att byta till HTTPS, beskriver kolumnist Patrick Stox hur processen går till. Patrick Stox den 14 april 2016 klockan 11:25

Guide för att byta från HTTP till HTTPS

Jag har insett att det fortfarande finns ett stort hinder för både företagare och SEO:er: HTTPS. Det som är problemet med HTTP/2 är att de flesta webbläsare endast stöder detta nya protokoll via en säker anslutning, vilket innebär att du måste flytta din webbplats till HTTPS. Det borde inte komma som en chock för någon att Google och många andra vill att webben ska bli säkrare. Google hade sin HTTPS everywhere-kampanj, de tillkännagav HTTPS som en rankningssignal och de har börjat indexera säkra sidor framför osäkra sidor. De har till och med en egen guide, ”Securing Your Website With HTTPS”, som jag uppmuntrar alla att läsa tillsammans med den här artikeln.

Men trots alla dessa satsningar på en säkrare webb kvarstår faktumet: Mindre än 0,1 % av alla webbplatser är säkra.

Det verkar som om alla försöker göra det så enkelt som möjligt att byta genom att ta bort hinder för inträde, t.ex. kostnader. Let’s Encrypt erbjuder kostnadsfria certifikat (sidotext: Jag är mycket road av att Google Chrome har den enda nofollow på sin betalda sponsringslänk efter att ha blivit utpekad). Många webbplatsvärdar och CDN:er erbjuder också gratis säkerhetscertifikat för att uppmuntra människor att byta, men många människor är fortfarande inte på väg.

Varför gå över till HTTPS?

Google anger flera skäl till att byta till HTTPS i sin guide för flyttning av webbplatser: Data som skickas med HTTPS är säkrad via TLS-protokollet (Transport Layer Security), som ger tre viktiga skyddslager:

Kryptering. Kryptering av den utbytta datan för att hålla den säker mot tjuvlyssnare. Det innebär att medan användaren surfar på en webbplats kan ingen ”lyssna” på deras samtal, spåra deras aktiviteter över flera sidor eller stjäla deras information. Dataintegritet. Data kan inte ändras eller skadas under överföringen, avsiktligt eller på annat sätt, utan att upptäckas. Autentisering. Bevisar att dina användare kommunicerar med den avsedda webbplatsen. Det skyddar mot man-in-the-middle-attacker och bygger upp användarnas förtroende, vilket leder till andra affärsfördelar.

Det finns dock andra fördelar, bland annat den ökning av Google-rankningen som nämndes tidigare. Läs gärna min artikel om Sökmotoroptimering på Södermalm där jag bor.

Att övergå till HTTPS hjälper också till med förlusten av hänvisningsdata som sker när hänvisningsvärdet i rubriken faller bort när man byter från en säker webbplats till en osäker webbplats. Analysprogrammen tillskriver trafik utan hänvisningsvärde som direkt, vilket står för en stor del av det som kallas ”mörk trafik”. Växlingen förhindrar också en hel del dåliga saker, till exempel när AT&T injicerade annonser i sina hotspots. De skulle inte ha kunnat lägga in dessa annonser på en webbplats med HTTPS. Säkerställer HTTPS min webbplats?

Folk hör HTTPS nämnas som ett säkert protokoll, och de tror att detta skyddar deras webbplats. Faktum är att din webbplats inte är skyddad, och du kan fortfarande vara sårbar för ett eller flera av följande:

• Nedgraderingsattacker
• SSL/TLS-sårbarheter
• Heatbleed, Poodle, Logjam etc.
• Intrång på en webbplats, en server eller ett nätverk.
• Sårbarheter i programvara
• Brute force-attacker
• DDOS-attacker

Övergång från HTTP till HTTPS

Börja med en testserver. Detta är viktigt eftersom det gör att du kan göra allting rätt och testa utan att förstöra det i realtid. Även om du gör bytet utan en testserver finns det nästan ingenting du kan göra som du inte kan återhämta dig från, men det är ändå bäst att ha en plan och att testa allting i förväg. Crawla den nuvarande webbplatsen så att du känner till webbplatsens nuvarande tillstånd och för att göra jämförelser. Läs all dokumentation om din server eller CDN för HTTPS. Jag stöter på många roliga CDN-problem, men det kan också vara okomplicerat. Skaffa ett säkerhetscertifikat och installera det på servern. Detta kommer att variera beroende på din värdmiljö och serveruppsättning för mycket för att jag ska gå in på detaljer, men processen är vanligtvis väldokumenterad.

Uppdatera referenser i innehållet. Detta kan vanligtvis göras med en sökning och ersättning i databasen. Du vill uppdatera alla referenser till interna länkar så att de använder HTTPS eller relativa sökvägar. Uppdatera referenser i mallar. Återigen, beroende på hur du distribuerar, kan detta göras med Git eller helt enkelt med Notepad++, men du vill se till att referenser till skript, bilder, länkar och så vidare antingen använder HTTPS eller relativa sökvägar. Uppdatera kanoniska taggar. De flesta CMS-system tar hand om detta när du byter, men dubbelkolla, för det är inte alltid fallet.

Uppdatera hreflang-taggar om din webbplats använder dem, eller andra taggar som OG-taggar för den delen. Återigen tar de flesta CMS-system hand om detta, men det är bäst att kvalitetssäkra det för säkerhets skull. Uppdatera alla plugins/moduler/tillägg för att se till att inget går sönder och att inget innehåller osäkert innehåll. Jag ser ofta att intern sökning på webbplatsen och formulär missas. CMS-specifika inställningar kan behöva ändras. För större CMS-system är dessa vanligtvis väldokumenterade i migrationsguider. Crawla webbplatsen för att se till att du inte missat några länkar och att ingenting är trasigt. Du kan exportera eventuellt osäkert innehåll i en av Screaming Frog-rapporterna om det är den crawler du använder.

Kontrollera att alla externa skript som anropas stöder HTTPS.

Tvinga fram HTTPS med omdirigeringar. Detta beror på din server och konfiguration men är väldokumenterat för Apache, Nginx och IIS. Uppdatera gamla omdirigeringar som finns på plats (och när du ändå håller på, ta tillbaka dina förlorade länkar från omdirigeringar som inte har gjorts under åren). Jag nämnde under Q&A-delen av den tekniska SEO-panelen på SMX West att jag aldrig har haft en webbplats som tappat i ranking eller trafik när jag bytte till HTTPS, och många frågade mig om detta. Noggrannhet när det gäller omdirigeringar och omdirigeringskedjor är troligen skillnaden, eftersom det är detta som jag ser mest fel när jag felsöker migreringar.

Crawla de gamla webbadresserna för att hitta eventuella trasiga omdirigeringar eller omdirigeringskedjor, vilket du kan hitta i en rapport med Screaming Frog. Uppdatera sitemaps för att använda HTTPS-versioner av webbadresserna. Uppdatera din robots.txt-fil så att den inkluderar din nya webbplatskarta. Aktivera HSTS. Detta talar om för webbläsaren att alltid använda HTTPS, vilket eliminerar en kontroll på serversidan och gör att din webbplats laddas snabbare. Detta kan också skapa förvirring ibland, eftersom omdirigeringen kommer att visas som 307. Den kan dock ha en 301 eller 302 bakom sig, och du kan behöva rensa webbläsarens cache för att se vilken. Aktivera OCSP-häftning. Detta gör det möjligt för en server att kontrollera om ett säkerhetscertifikat är återkallat i stället för en webbläsare, vilket gör att webbläsaren inte behöver ladda ner eller korsreferera med den utfärdande certifikatmyndigheten.

Lägg till HTTP/2-stöd.

Lägg till HTTPS-versionen av din webbplats i alla sökmotorversioner av webmasterverktyg som du använder och ladda den nya webbplatskartan med HTTPS till dem. Detta är viktigt, eftersom jag har sett trafikminskningar som feldiagnostiserats eftersom de såg att trafiken i HTTP-profilen minskade, när trafiken i själva verket flyttades till HTTPS-profilen. En annan notering för detta är att du inte behöver använda verktyget för adressändring när du byter från HTTP till HTTPS. Uppdatera din disavow-fil om du hade en sådan för HTTPS-versionen. Uppdatera dina inställningar för URL-parametrar om du hade dessa konfigurerade. Sätt igång!

I din analysplattform ska du se till att uppdatera standard-URL:n om en sådan krävs för att se till att du spårar HTTPS korrekt, och lägg till anteckningar om ändringen så att du vet när den inträffade för framtida referens. Uppdatera dina sociala delningsräkningar. Det finns en hel del problem med detta, eftersom vissa nätverk överför räkningarna via sina API:er, medan andra inte gör det. Det finns redan guider för detta runtomkring om du är intresserad av att behålla dina delningsräkningar. Uppdatera alla kampanjer för betalda medier, e-post eller automatiserad marknadsföring så att de använder HTTPS-versionerna av webbadresserna. Uppdatera alla andra verktyg, t.ex. programvara för A/B-testning, heatmaps och nyckelordsspårning, så att de använder HTTPS-versionerna av URL:erna. Övervaka allt under migreringen och kontrollera, dubbelkolla och trippelkolla för att se till att allt går smidigt. Det finns så många ställen där saker och ting kan gå fel, och det verkar som om det vanligtvis är flera problem som dyker upp vid varje övergång till HTTPS.

En fråga som jag ofta får är om inkommande länkar bör rensas upp. Detta är en enorm mängd uppsökande arbete och ansträngningar. Om du har tid, javisst, men du är troligen upptagen med andra saker och jag anser inte att det är absolut nödvändigt. Däremot bör du uppdatera länkarna på alla egenskaper som du kontrollerar, till exempel sociala profiler.

Vanliga problem med HTTPS-migreringar

Saker som kan gå fel är bland annat följande:

1. Att hindra Google från att crawla HTTP-versionen av webbplatsen, eller att hindra webbplatsens crawls i allmänhet (det händer vanligtvis på grund av att testservern inte uppdateras för att tillåta botar); Problem med duplicering av innehåll, med både HTTPS- och HTTP-versioner av sidorna som visas. Olika versioner av sidan visas på HTTP och HTTPS.
2. De flesta av de vanliga problemen med HTTPS-migreringar är resultatet av felaktigt implementerade omdirigeringar. (Jag har också haft roligt att städa upp webbplatser som ändrat hela sin struktur/design när de övergått till HTTPS). Omdirigeringar förtjänar ett eget avsnitt.
3. Som nämnts ovan har de största problemen jag ser med övergången till HTTPS att göra med omdirigeringar. Det hjälper inte att ändringen kan göras på registrarnivå, i serverkonfigurationen eller till och med i en .htaccess-fil; alla har sina egna ”gotchas”.
4. Misslyckade omdirigeringar och omdirigeringskedjor är nästan alltid problem. Se till att kontrollera undersidor och startsidan; beroende på hur reglerna är skrivna och var de är placerade kan de påverkas på olika sätt. Du måste också faktiskt titta på vad som händer med dessa när det gäller statuskoder och hopp, inte bara om de tar dig till rätt sida. Det hjälper definitivt inte när Apaches dokumentation för detta inte inkluderar en 301 och Apache som standard anger en 302. Koden nedan bör uppdateras till R=301.

RewriteEngine På
# Detta kommer att aktivera Rewrite-funktionerna

RewriteCond %{HTTPS} !=on
# Detta kontrollerar att anslutningen inte redan är HTTPS.

RewriteRule ^/??(.*) https://%{SERVER_NAME}/$1 [R,L]
# Den här regeln omdirigerar användare från deras ursprungliga plats till samma plats men med HTTPS.
# dvs. http://www.example.com/foo/ till https://www.example.com/foo/
# Det inledande snedstrecket är frivilligt så att detta fungerar antingen i httpd.conf
# eller i .htaccess-sammanhang

Jag har sett webbplatser återhämta sig från detta misstag vid byte, men det verkar ske först flera månader senare, när Google kommer på vad som hänt och rättar till misstaget i deras ställe.

Även de bästa av oss misslyckas ibland:
Google 302-omdirigeringar för Google Webmaster Tools vid byte till HTTPS. Jag använder verktyg som Screaming Frog och Ayima Redirect Path för att göra snabba kontroller av några av de gamla webbadresserna – eller, med lite Excel-manipulation, för att göra bulkkontroller av stora mängder webbadresser och äldre omdirigeringar. Detta hjälper till att se till att allt omdirigeras korrekt och utan flera hopp.

Avslutande tankar om HTTPS

HTTPS kommer helt enkelt inte att försvinna. HTTP/2, Google AMP och Googles QUIC-protokoll (som troligen snart kommer att standardiseras) kräver alla säkra anslutningar för att webbläsare ska kunna använda dem. Faktum kvarstår att HTTPS pressas hårt av makthavarna och det är dags att byta till HTTPS. De flesta problem som jag ser beror på dålig planering, dåligt genomförande eller dålig uppföljning. Om du följer de steg som jag har beskrivit bör du ha små eller inga problem när du övergår från HTTP till HTTPS.