H1-rubriken brukade vara det viktigaste elementet på en sida. Det var den starkaste signalen till Google om vad som var sidans huvudord. Men allt eftersom HTML5 håller på att bli en verklighet, och en sida kan ha flera h1-rubriker, ja där varje enskilt område på en sida kan ha sin egen h1-rubrik (och efterföljande rubrikhirarki), så har vikten hos h1-rubriken sjunkit, till förmån för title-taggen.
Det har, på intet sätt, gjort det mindre viktigt att sätta en bra rubrik på en sida. Det är nämligen så att alla de vanligare publiceringssystem använder samma element för att sätta h1, title-text, namnet på sidan, breadcrumbs och menylänkar . I WordPress kallas detta element rubrik på svenska och title på engelska. I EPiServer kallas elementet page name eller sidnamn. I SiteVision kallas elementet kort och gott rubrik. I Drupal, som jag faktiskt har både minst och sämst erfarenheter av, talas det om title och rubrik ungefär på samma sätt som i WordPress.
Allt detta är egentligen av godo. Rubriken är oftast det bästa elementet att använda som förvald text i alla de övriga, men bara som förval. I ett riktigt bra CMS bör man även kunna anpassa användningen. Det bör vara möjligt att ha en annan title-text än h1-rubrik, man bör kunna sätta en annan text för menyalternativ, och man borde också kunna specialskriva länktexten för breadcrumb-länkar.
Stora krav på rubriken
Det fakutm att samma CMS-element återanvänds till så många olika html-element gör det ännu viktigare att sätta rätt rubrik på en sida och gör det ju samtidigt så mycket mer komplext. Utan anpassningar som gör att man kan differentiera texten i olika element ställs det lite väl höga krav på rubriken.
Vi vill sätta intresseväckande rubriker för att generera klick inom sajten, vi vill göra dem deskreptiva för att kunna fånga sökplaceringarna, vi kan inte skriva längre rubriker än 45 tecken om vi vill att de ska rymmas i title-taggen tillsammans med sajtens namn.
I mitt arbete med olika typer av kunder möter jag olika typer av felanvändning av h1-rubriker. Tidningar skriver ofta för innehållsfattiga h1-texter, offentlig förvaltning skriver ofta ingresser snarare än egentliga rubriker och många företagsbloggare har en vana att återanvända samma rubrik om och om igen, vilket gör det svårare för Google att förstå vilken som är den viktigaste sidan för en sökfras.
H1-rubriken på kategori och tagg-sidor.
Samlingsidor som kategori- och taggsidor är de mest misshandlade när det kommer till korrekta h1-rubriker. Ofta saknas de helt på dessa, ofta väldigt viktiga sidor, och lika ofta har man inte anpassat rubriken så att den skrivs ut som ”Arkiv för [kategori]/[tagg]”. Dessutom sätts den ofta ut som en h2- eller h3-rubrik.
Men h2 och h3 då?
När man har styrt upp sina h1-rubriker så är det lika viktigt att se till att h2- och h3-rubrikerna är fokuserade. Och det är de ällan. Alltför många sajter använder slentrianmässigt h2- och h3-rubriker för fasta formelement istället för som underrburiker som stärker sidan. En tumregel är att h-rubriker aldrig bör användas för text som inte fokuserar på sidans innehåll. Det är direkt förstörande att använda h2 för rubriker som visas snart nog varje sida på sajten (tänk Kontakt, Nyheter, Relaterade poster).
Viktigt att anpassa sajten för uppgiften
Alla dessa olika krav på rubriken gör det alltmer viktigt att bygga in anpassningar i våra publiceringssystem.
I WordPress, som är det CMS som jag kan bäst, kan man, med hjälp av ett SEO-plugin som All in One SEO sätta title-texten. Eller så använder man ett framework (som t.ex Genesis) som bygger in det i WordPress utan behov av ett SEO-plugin. Men jag har fortfarande inte sett någon lösning som gör det riktigt smidigt att använda två olika rubriker och automatiskt använda en alternativ text som indragare för puffar från andra sidor.
Jag har också sett denna typ av anpassningar fungera fint i EPiServer, men det verkar vara svårast att åstadkomma på ett bra sätt i SiteVision och i Drupal går det förvisso att åstadkomma denna typ av anpassningar, men det är samtidigt det CMS där det oftast blir fel när utvecklarna inte riktigt vet vad de gör.
