Meta-taggen används för att ange "metadata" för läsare, sökmotorer m.fl. som laddar ner sidan. Med metadata menas information om informationen d.v.s. ingenting som är direkt innehåll i bloggpostningar (eller annan html-sida) men som däremot kan användas för att tolka presentationen (t.ex. utseende) eller få information om författare, alternativa versioner, vilken tidsperiod dokumentet är aktuellt, en kort beskrivning av vad sidan handlar om och dyligt.
En meta-tagg man kan träffa på är verify-v1. Så här ser den t.ex. ut för SEOTaktik:
<meta content='xTIB7CpcHF2DEpm+QC0RbyvmayI4HKzWeQTflndobFU=' name='verify-v1'/>
Vad är verify-v1?
verify-v1 är resultatet av en metod för att verifiera för Google att man "äger" en webbplats. Tjänster Google har (t.ex. Google Webmaster Tools) kan generera en sträng med tecken som ligger i en meta-tagg:
Du placerar denna på din webbsajt (startsidan räcker).
Placera verify-v1 på Blogger
För Blogger gör du det genom att gå till Layout och lägga raden under head och om du har kvar <b:include data='blog' name='all-head-content'/> även efter denna:
I lösningen ovan dyker strängen upp på hela sajten. Det går att lösa som jag förklarade i:
Vilket som är bäst vet jag egentligen inte säkert. I det ena fallet får man en onödig meta-tagg i inlägg m.m. I det andra fallet kommer Blogger behöva göra en extra beräkning i form av en if-sats. Jag bedömer det dock som mycket troligare att det avseende prestanda är mycket bättre att välja att ha meta-taggen på hela bloggen.
Fler tips om Blogger och SEO hittar du här:
Vad kan du nu göra?
Tjänsten du verifierat webbplatsen tar när den hittar denna detta som ett bevis på att den som loggat in på deras tjänst har "rättigheter" till webbsajten. Därmed kan du få utökad information från Google, peka ut en sitemap m.m.
Har du verifierat flera webbsajter är det numera även möjligt att ha en sitemap för en sajt på en annan sajt vilket i flera fall är väldigt praktiskt (inte minst för Blogger där man i de flesta fall inte kan ladda upp filer).
Hur genererar Google strängen?
Exakt hur strängen genereras vet jag inte men jag gissar att man gör något motsvarande det sätt jag själv skulle göra det på:
H (S1 | S2 | ... | SN | R | P)
Där H är en funktion som genererar ett kryptologiskt säkert hashvärde. Att den är kryptologisk säker är nödvändigt för att risken för kollisioner där olika webbplatser får samma sträng reduceras till extremt otroligt. Skulle två eller flera webbplatser få samma sträng kan de verifiera ägerskap för varandra.
| är sträng concatation d.v.s. "ABCDE" | "DGD333" = "ABCDEDGD333". Det är vad man vanligen skapar indata med till kryptologiskt säkra hashfunktioner. Orsaken är nog numera delvis tradition men från början därför att det gick att göra med memcpy i C (string.h) vilket är väldigt snabbt.
S1, S2, ..., SN är ett antal indata som är specifika för den aktuella webbplatsen. Detta är nödvändigt för att undvika kollisioner för olika webbplatser. Mest självklar sådan är DNS-namn. Utan att motivera det tycker jag att det verkar mycket klokt att inte begränsa sig till det utan att använda något mer specifikt som inte är direkt beroende av DNS.
R är en sträng genererad med en kryptologisk säker slumpgenerator initierad med tillräckligt av slumpmässighet som seed. Det är en god vana att alltid lägga något slumpmässigt till indatat för den här typen av användning av kryptologiskt säkra hashfunktioner. Detta för flera typer av analys som är möjligliga eller kan visa sig möjliga försvåras samtidigt som det typiskt inte kostar något i prestanda (du kan generera stora mängder R i förväg).
P är något specifikt för användaren. Återigen är detta nödvändigt för att undvika kollisioner men nu (givet tidigare strängar) mellan olika "administratörer" för respektive webbplats.
Jag tror det här blir tillräckligt säkert men jag skulle inte implementera det i praktiken utan att tänka igenom det mer än jag gjorde nu.
Om den slumpmässiga strängen
När det kommer till det slumpmässiga värdet kan man möjligen ha hamnat i en situation där man kodat in sig så att denna inte går att använda. Om olika tjänster inte kan fråga en centraltjänst om verifiering mellan användare och webbsajt behöver de ju kunna generera verifieringssträngen själva. I så fall går det inte att de själva genererar R eftersom det inte blir entydigt.
Jag tror inte Google gjort den missen. En annan fråga är hur många bitar slump (eller psuedoslumptal genererade från en kryptologisk säkerhet pseudoslumptalsgenerator initierad med tillräckligt mycket riktig slumpmässighet). Själv skulle jag inte generera mindre än 80-bitar. Vidare för seed skulle jag inte ta mindre än 160 bitar.
Foto:
Kommentera