Stäng ut Google från testmiljön
Publicerad 29 januari 2010, senast uppdaterad 2023-05-19
Ett väldigt vanligt problem som vi stöter på ofta i vårt arbete är att sajters testmiljöer blir indexerade av sökmotorer. Det stora problemet med detta är duplicerat innehåll (duplicate content). Helt plötsligt finns det två (ofta helt identiska) kopior av samma sajt. Duplicerat innehåll ogillas mer och mer av sökmotorer och det är inte sällan man blir straffad för det.
Det blir både problem om testmiljön ligger på ens egen domän (ofta som en subdomän) t ex:
test.sajt123.se
eller om testmiljön ligger på en annan domän (ofta hos ens leverantör) t ex:
sajt123.webbyggarna123.se
I det senare fallet blir problemet extra stort om ens leverantör har en stark domän i sökmotorernas ögon och man själv har en helt ny domän. I så fall kan Google i värsta fall välja att indexera testmiljön hos din leverantör istället för din egen domän, vilket inte är en så kul start på din internetsatsning.
Hur stänger man ut Google och andra sökmotorer från ens testmiljö?
1. Robots.txt
Robots.txt är en enkel textfil som man lägger i roten på sin domän. Denna filen används bara av sökmotorer och i denna fil kan man ange att visa delar av ens sajt inte ska spindlas, t ex kan du säga till sökmotorerna att inte spindla test.sajt123.se
Teoretisk låter detta som en perfekt lösning. Tyvärr har vi dock i praktiken sett flertal exempel på att testmiljöer blir indexerad trots en korrekt Robots.txt fil
2. Noindex
Det går även att sätta Noindex på alla ens webbsidor i testmiljön. Med detta säger du till sökmotorerna att inte indexera sidorna.
Tyvärr har denna lösning samma brist som Robots.txt, det vill säga att det inte är säkert att det kommer fungera även om man gjort helt rätt.
3. Inloggningsskydd
Det absolut säkraste sättet att stänga ute Google från din testmiljö och den metod som vi absolut rekommenderar är att inloggningsskydda din testmiljö. Genom att kräva ett lösenord för att komma åt testmiljlön blir det tvärstopp för Google och andra sökmotorer. Detta är ofta en väldigt enkel lösning att implementera och som även har fördelen att inga konkurrenter kan komma in och snoka i din testmiljö.
Ett alternativ till att kräva just lösenord är att endast ge vissa utvalda IP åtkomst åt testmiljön. Det ger samma önskad effekt.
Vad gör man om man fått sin testmiljö indexerad?
Om ”olyckan” varit framme och din testmiljö blivit indexerad så är det bästa att göra en 301 redirect från din testmiljö till den riktiga sajten. Detta innebär att man inte kan använda samma domän för testmiljön längre. Om man gör en 301 redirect från test.sajt123.se till sajt123.se så behöver man använda en ny subdomän för testmiljö framöver, t ex test2.sajt123.se.
Om man av någon anledning inte kan göra en 301 redirect är den näst bästa lösningen att göra någon av punkterna 2 eller 3 ovan (vi rekommenderar som sagt punkt 3). Att inte göra en 301 redirect kommer innebära att det tar längre tid innan Google väljer att avindexera och bortse från testmiljön och det duplicerade innehåll som skapats.
Hur hittar Google testmiljön?
Om man på något sätt publikt länkar till sin testmiljö kan du vara säker på att Google hittar och indexerar din testmiljö. Men vi har även sett flera exempel på när en testmiljö blir indexerad utan några publika inlänkar, t ex kan det räcka om du skickar URL:en till testmiljön via Gmail för att Google ska snappa upp det och senare indexera det.
11 kommentarer på "Stäng ut Google från testmiljön"
Kommentarsfältet är stängt.
Tja
Det är ganska stor skillnad på att använda robots.txt och META-noindex. I robots.txt säger du till Google att inte läsa filen, dvs de läser inte innehållet – men de indexerar den (dock inte sagt att den tas med i serpen) och den kan få pagerank som vilken sida som helst (källa: Matt Cutts)
Använder du META-noindex så måste t.ex. Google först kunna läsa filen för att hämta noindex-taggen – när de gjort de ser de taggen och kommer inte indexera innehållet och inte heller indexera sidan.
Många känner inte till detta och kör ”hängslen och livrem” och det är då det blir som mest fel, t.ex. använda både robots.txt + noindex när de vill ha bort filer från serpen (t.ex. affiliatelänkar, pagineringar etc) men det enda som händer är att Google ser robots.txt där de står att de inte ska läsa filen, vilket medför att de aldrig ser meta-noindex taggen eftersom den ligger i innehållet vilket medför att sidan kommer ligga kvar i serpen 🙂
Sen det vanligaste i en testmiljö är väl att man ändrar i sin hosts-fil så att ingen annan ens kan komma åt den?
Mvh Jonas
Tack för din kommentar, Jonas.
Ja, vid användande av Robots.txt så vet Google om att sidan finns men de spindlar aldrig sidan så det blir aldrig ett problem med duplicerat innehåll. Däremot är det precis som du säger att sidan ända kan hamna i SERP:en, ofta pga att sidan i fråga har inlänkar.
För er som inte sett vad Matt Cutts berättar om robots.txt rekommenderar jag videon som finns på följande sida:
http://www.mattcutts.com/blog/robots-txt-remove-url/
Håller med om att det inte är bra att använda både robots.txt och No Index.
Att använda sig av en host-fil lösning funkar såklart lika bra, men vår erfarenhet är många väljer en lösenordsskyddslösning.
Hej,
Jag undrar en sak om just ”duplicate content” som du kanske kan svara på. Om man citerar (blockquote) känner sökmotorerna av det så man inte blir straffad för det?
Tack på förhand.
Google förstår helt klart när man använder blockquote men det ger dig inget skydd. Det är helt klart ok att citera texter men taggen gör ju varken till eller ifrån huruvida Google ska visa sidan eller inte. De vill ju inte visa upp en kopia på texten oavsett hur man taggar upp den.
Vid citat är mitt förslag att citera bara det allra nödvändigaste och se till att tillföra något eget. Dessutom tycker jag att det är rimligt att länka till källan och inte bara ange i text var citatet kommer från.
Den stora grejen här är att inte bara ha ett citat, om du t ex skrivit en bloggpost där du citerar en annan bloggare men gör en analys eller liknande är det inget som Google kommer straffa dig för. Om du bara publicerar en citerad text kan du räkna med duplicate content-filter däremot.
Precis detta felet jag gjorde för något år sedan. Var inte så roligt när byggarbetsplatsen började synas på Google. Nu har man dock lärt sig en läxa! Gör numera med inloggningsskydd.
Tur att man läste detta. Inge jätteproblem för min del. Men har en preview sida på min blog så jag lätt kan visa det nyaste jag tänkt lägga ut för vänner osv. Händer sen att man glömmer tömma preview sidan tills nästa gång och på så vis en kort period har 2 lika dana sidor.
Ska nog testa noindex och se hur det funkar.
Om ”olyckan” är framme och lagt in 301 hur försvinner man då från serpen så snabbt som möjligt? Kan man deleta sidor i webmaster tools eller liknande.
301 ska nog vara snabbaste, kom ihåg att inte samtidigt blocka Google utan låt spindlarna hitta 301:orna. Annars kan sidorna ligga och skräpa i index länge.
Ett annat smidigt sätt, som du också nämner, att låsa ute sökmotorer är att sätta upp regler i webbservern för IP-nummer på miljöer som jag behöver exponera utåt av någon anledning under test/utveckling.
Då gör jag som så att jag blacklistar all trafik till den aktuella subdomänen eller porten och är explicit i vilka IP-nummer jag låter komma åt webbservern. På det sättet så får man bra kontroll över vilka som kommer åt servern men utan att påtvinga inloggning, vilket är smidigt för användaren/utvecklaren.
Enkelt att sätta upp i både Apache och nginx. Ett kanske bättre alternativ om det är en stor och viktig webbplats man jobbar med kan ju ett VPN vara en lösning, grundtesen är väl att man inte ska göra sin utvecklingswebb tillgänglig externt om det inte finns absoluta krav på det.
Gissar att risken med just detta är störst när man har beta och alfamiljöer med riktiga användare och att man då riskerar att inte ha justerat enligt de tips du pekar på i artikeln.
Mattias,
Tack för bra kommentar. Att blocka via IP är en smidig lösning. Många upplever ju det lite krångligt att behöva logga in, även om personligen själv inte tycker att det är en stor sak.