I denna del av inlägget kommer jag att hänvisa till en mycket användbar och bra webb-referenssida hos learn.shayhowe.com som i detalj går igenom viktiga saker värda att ha koll på för HTML(5) semantik.

När vi pratar blockelement och en webbsidas struktur så kom HTML5’s kod-standard med en del nya tillskott som ni redan fått se som hastigast i tidigare inlägg, men som kanske inte diskuterats i detalj med fokus på deras semantiska sida.

Varför nya element med HTML5?

Utvecklarna av den nya HTML5 standarden gjorde som sagt undersökningar för att ta reda på vilka som var de vanligaste klasserna och ID som användes för strukturella element som t  ex. <div> på webbsidor över hela internet. Detta ledde till att man hittade ett antal klasser och ID som återkom oftare än andra, och man beslutade därför att förenkla genom att skapa nya element för dessa typer av blockelement så att man slipper ständigt ange samma klasser och ID för massa olika webbsidor.

Då skapades:

  • <header></header> som ersättare till <div id="header"></div> t ex. för sidhuvud
  • <footer></footer> som ersättare till <div id="footer"></div> för sidfot
  • <aside></aside> som ersättare till <div id="aside"></div> (sidebar/sidospalt)
  • <article></article> som ersättare till <div id="article"></div>
  • <section></section> som ersättare till <div></div> eller <div id="section"></div> eller <div class="section"></div> (sektionsavdelare)
  • <nav></nav> som ersättare till <div id="nav"></div> (navigations område)

De nya elementen (tycker jag iaf.) är betydligt mer utvecklar-vänliga och sparar en hel del tid, såväl som förser webbdokument i allmänhet med en bättre arsenal av strukturella element. De förmedlar också på ett bättre sätt för både utvecklare, såväl som indexeringsrobotar vad elementet är till för på webbsidan (indexeringsrobotarna kunde inte läsa och förstå ID och klass attribut, däremot kan de läsa och ”förstå” taggnamn).

Därför säger jag att vi får nu ta vara på att vi äntligen fått bättre semantiskt bestyckade element att märka upp våra webbsidor med, dissa <div> taggar och extra- nu överflödiga: ID och klasser, som inte längre behövs nu när vi har våra nya element ;)

Översikt av de nya HTML5-elementen

HTML5Doctor är en bra referenssida om ni vill ha en översikt av de nya taggarna och ni kan även besöka deras HTML5-Element Index för uppsökande av specifika, eller generell översikt av samtliga nya taggar – de står listade i bokstavsordning.

Uppgradera er utdaterade element-arsenal med nya fräscha semantiska HTML5-element!

Läs gärna på lite på HTML5-Element indexet som HTML5Doctor erbjuder och fyll på ert HTML-taggs förråd med de senaste nya taggarna och börja använda de så ofta ni får möjligheten för bättre semantisk och sökmotoroptimerings anpassad HTML5-kodning.

Det finns alldeles för många nya tillskott för att hinna gå igenom i detta inlägg, dock kommer jag som jag nämnde ovan hänvisa till några väldigt användbara punkter som jag själv haft stor användning för som learn.shayhowe.com HTML5-semantics hjälpte till att förtydliga för mig.

Tips: Då HTML5 fortfarande är relativt nytt och saknar stöd i vissa webbläsare, kolla vad som funkar vart

Ett tips också innan jag går igenom det så kan jag rekommendera er att kolla upp webbläsarstöd för de nya HTML5-element ni tänker använda via antingen CanIUse.com eller QuirksMode.org Browser Compatibility Tables då vissa av de nya HTML5-elementen är bättre implementerade i somliga webbläsarna än andra!

Och nu för att gå vidare och kolla på textspecifika semantiska inline-element som kan vara användbart att känna till:

Förklaring och uppvisning av semantiska skillnader i HTML5-element

Två alternativ för att få fetstil på sin webbsidas text, med olika semantiska betydelser!

De två HTML(5)-element vi har att jobba med är <strong><b>. Dock skiljer dessa sig åt ganska mycket i mån av semantisk betydelse.

<strong> används för att markera ”Stark viktighet” / ”Strong Importance” på engelska. Medan <b> istället används för att avse en ”stilistisk fetstil” utan direkt innebörd.

Nedan kan ni se citat från hur learn.shayhowe.com förklarar detta i kod:

<!-- Strong importance -->
<strong>Caution:</strong> Falling rocks.

<!-- Stylistically offset -->
This recipe calls for <b>bacon</b> and <b>baconnaise</b>.

Två sätt för att få kursiverad text på sin webbsida, med olika semantiska betydelser!

De två HTML(5)-element vi har att jobba med för detta är istället <em><i>. Dessa skiljer sig på liknande sätt som ovan två valsalternativ för fetstils text-märkning.

<em> används för att markera något av ”stressad vikt/betydelse” / ”Stressed Importance” på engelska. Medan <i> hellre avser att markera en annorlunda/alternativ ”röst/ton” och används mer i dialog-sammanhang & talspråk för innehåll.

Nedan kan ni se citat från hur learn.shayhowe.com förklarade detta i kod:

<!-- Stressed emphasis -->
I <em>love</em> Chicago!

<!-- Alternative voice or tone -->
The name <i>Shay</i> means a gift.

För att läsa på mer om olika semantiska skillnader mellan liknande funktionella HTML(5)-taggar så kolla gärna vidare på learn.shayhowe.com’s genomgång av HTML5-semantik då den artikeln även går igenom saker som: Understrykning av text, Genomstrykning av text, Upplysning/Highlightning av text, Förkortnings markering i text, Upphöjning (superscript) av text och Nedsänkning (subscript) av text – t ex. nedsänkning vid representation av H2O hade blivit: H2O, medan en upphöjning istället t ex. vid användning av kvadratmeter (m2) hade kunnat se ut som: m2. Sedan går artikeln även igenom saker som: Framstegsmätare (progress-meter), semantisk uppmärkning av tid & datum, hur man presenterar kod på webben, såväl som linje- och ord-brytningar (<wbr> & <br>), Citering, m.m.

Genomgång av Semantisk märkning av textinnehåll med <h1>-rubriker och <p>-paragrafer för textstycken:

När man skriver texter så är ovan visade genomgångar av kursivering och fetstil väldigt användbara och viktiga, men det är även simplare och mer direkt semantisk uppmärkning som Rubriker (via <h1>, <h2>, <h3>, osv.), såväl som paragrafer/textstycken (<p>), sektions-avdelare/skiljestreck (<hr />) för att distinkt markera brytstället där en del av sidan övergår till en helt annan del av sidan, m.fl. andra.

Dock så tänkte jag bara snabbt gå igenom vikten av Rubriktexter och deras innehåll då även detta är en Väldigt viktig del inom On-page sökmotoroptimering!

Den ”första” rubriktexten tillgänglig är <h1> och är då den som är av störst vikt och sedan dalar viktigheten för resterande rubriktexter tillgängliga för varje steg man går – notera dock! att <h2> t ex. är en typ av underrubrik till <h1> och bör användas som sådan!

Ett praktiskt exempel – skulle ni ha en <h1> rubrik för er logotype om ni valt att köra den ”textbaserad” som jag själv brukar göra då detta är lättare att sökmotoroptimera jämfört med en bild som praktiskt taget inte går att indexera för sökmotor-bottarna så skulle <h2>-taggarna kunna användas för sid-innehållets första rubriker då de är underrubriker till sidan – men detta är lite av en tolkningsfråga och är helt upp till er hur ni väljer att tolka sidans struktur – tänk bara på att den struktur ni väljer att köra sidan utefter – är även den struktur indexeringsrobotarna kommer att uppfatta!

Men jag skulle nog annars vilja påstå att <h1>-taggen och dessa rubriktexts-elementen kommer någonstans efter <title>-taggen i vikt när det gäller On-page sökmotoroptimering!

HTML5-bildtaggen (<img>) har ett attribut som krävs för att få en sida validerad enligt HTML5-kodstandard, som är: ”alt”-attributet.

Detta är bra att ha med för att dels få sidan validerad – men även för två andra syften, nämligen: talsyntes och sökmotoroptimering.

Bilddata för indexeringsrobotar

För bilder på webbsidor så gäller samma sak för indexeringsrobotar såväl som blinda personer i stort sett (nästan) – de är väldigt intet-sägande såvida du inte specifikt får dina bilder att tala om för de personer utan möjlighet att se dem – just vad bilderna föreställer. Och detta kan man då göra med hjälp av ”alt”-attributet som låter dig som utvecklare ange en alternativ text till bilden utifall den inte skulle kunna laddas in, visas eller om besökaren på sidan använder talsyntes t ex.

Om ni har möjlighet och SEO är av vikt – föredra ren text över bilder med text!

När du skriver värdena till dina ”alt”-attribut för bilderna så kan det vara värt att hålla detta i åtanke. Detta är också en av anledningarna att jag själv har börjat föredra att använda HTML-Text + CSS för mina logotyper på mina webbplatser, för sökmotoroptimeringsskäl, då ”alt”-attributet är enda möjligheten att sökmotoroptimera en bild. Jag brukar sätta mina textlogotyper i sådana fall som <h1> taggar för att ge störst ”rubriktexts-vikt” sökmotormässigt på sidan. Alla andra rubriker efter logotype-rubriken följer sen med <h2> som ”underrubriker” till själva sidans logotype. Vissa kanske anser detta fel, andra kanske tycker det är OK, det funkar för mig så jag kör på det tills någon annan ger mig anledning att överväga annat tillvägagångssätt :)

Alternativ text visas vid misslyckad laddning av bild

Ni kan själva testa detta genom att med vilje, ange en felaktig src-url för bilden på er sida, har ni angett bredd och höjd då, så kommer ni i vissa webbläsare att kunna se en ruta med en tunn kantlinje med just de dimensionerna ni hade angivit för bilden, tillsammans med er ”alt”-attributs textvärde inuti rutan där bilden egentligen skulle visats.

Alternativ text hjälper blinda bilda sig en uppfattning om bilder på webben

Alternativ texten som anges till bilder är det enda hjälpmedlet blinda personer har för att förstå vad bilden ni visar på er webbsida föreställer. Utan alternativ texts attributvärdet så har de lika mycket att gå på, som om bilden inte existerat överhuvudtaget.

Alternativ text för bilder läses av indexeringsrobotar som innehåll

Alternativ texten som ni angivit till era bilder används som sagt inte bara för att visa ”fallback-innehåll” för utifall bild inte kunde visas, eller bidra med talsyntes kontext för blinda som besöker ens webbsida, utan även indexeringsrobotarna som crawlar igenom er sida i jakt på innehåll att indexera till sökmotorjättarna kommer att läsa och indexera alternativ texten för bilderna – då även indexeringsrobotarna har svårt för att tolka bilddata.

Sammanfattning – Alt text värt att ha i åtanke av många anledningar

Detta innebär att du bör skriva din alternativ-text (alt-attribut) med alla dessa 3 faktorerna i åtanke(!) – texten skall vara anpassad att beskriva bilden för blinda personer och deras talsyntes som då kommer att läsa upp bild-alternativ-texten (speciellt viktigt om du vet att din sida kommer ha blinda besökare, kan anses vara minst lika viktigt trots att ni siktar in ert innehåll på seende individer – som en artighetsgest till alla som är blinda och surfar nätet som alla andra, det är trots allt inte så mycket jobb att lägga till en alt text), såväl som för indexerings robotarna så de får ytterligare innehåll som kan indexeras till sökmotorerna och ytterligare förbättra sökmotoroptimeringen av din sida. Samt anpassa texten som substitut utifall bild skulle misslyckas att laddas in på din webbsida.

För några år sedan (i skrivande stund) så var det betydligt populärare än vad det är idag med taggar som meta-keyword. Idag fokuserar indexerings robotarna mer och mer på själva innehållet som finns skrivet på en webbsida – därav den stora vikt som kom med HTML5-semantiska uppmärkningen av innehållet så indexeringsrobotarna förstår innehållet betydligt bättre och kan samla in ytterligare mer data än vad bara innehållet består av som t ex. även beskrivning av innehållet på ett språk bottarna själva kan förstå.

Men låt oss börja gå igenom de tre mest kända meta-data taggarna och se lite mer detaljerat på hur dessa fungerar och hur man kan nyttja de på ett bra sätt:

Meta-data taggen för: keywords – för nyckelord för ens webbsida till sökmotorerna

Denna meta-data tagg var betydligt populärare förr, dock på grund av att många missbrukade den på sätt som att ”spamma” alla möjliga ord, oavsett hur irrelevanta orden/termerna var för deras egna sidas faktiska innehåll – i hopp om att snappa upp trafik på sökningar på andra populära ord och termer, så tappade sökmotorer intresset. Många missförstod också hur meta-data taggen för keywords var tänkt att användas, vilket resulterade i att folk skriv flera instanser av samma ord, fast med olika variation på versaler och gemener för ordet – t ex. SmAk och smak och SMAK – för att göra- vad de förmdodligen trodde var- att täcka alla möjliga sökningar för ordet – utifall sökningarna var s.k. ”case-sensitive” och kunde ge olika sökresultat baserat på stora och små bokstäver.

Där var till och med tillfällen då någon hörde talas om ett rykte att så länge ordet ”existerade” på sidan, så blev det helt plötsligt ”tyngre” sökmotoroptimeringsmässigt, vilket ibland ledde till att folk som försökte fuska med sökmotoroptimeringen skrev in text på sin webbsida, och gav sedan texten stilar för att ”verka osynlig” för besökare på sidan, men som fortfarande kunde snappas upp av indexeringsrobotarna.

Efter ett tag blev bl. a. Google så trött på allt missbruk så de beslutade sig för att straffa folk som försökte fuska genom att sänka deras ranking (har jag för mig ;p).

Men för dem som faktiskt använde meta-data taggen för keywords på ett korrekt sätt, så kunde den användas för att tagga innehåll som fanns på sidan, såväl som inte fanns på sidan för att indikera vad sidan handlade om, även om just sidan inte specifikt berättade det i innehållet på sidan själv.

Detta tyckte jag själv var oerhört bra och användbart att ha tillgång till, men numera verkar det som meta-data taggen för keywords mer eller mindre slopas helt och hållet för indexeringsprocessen.

Att ha möjlighet till en metod för att in-direkt kunna deklarera vad ens sida handlade om för sökmotoroptimering tycker jag själv hade varit riktigt awesome!

Jag använde själv meta-data taggen för keywords ganska aktivt ända tills jag såg en diskussionstråd på MOZ.com som gav mig en tankeställare och fick mig att inse att det kanske inte gjorde så mycket längre som jag trodde/hade hoppats på: Moz.com diskussionstråd

Dock på den ljusa sidan innebär detta mindre tid till att komma på klyftiga nyckelord, och mer tid och fokus att lägga på faktiska webbsidan och det som verkligen spelar roll idag – såsom innehållet.

Meta-data taggen för: description – för beskrivning av ens webbsida till sökmotorerna

Meta-data taggen för description är en bra tagg att använda. Google visar t ex. meta-data taggen för description under länken till sidan för sökresultatet. Detta är användbart och bra då en beskrivning av specifika sidor och undersidor kan visas genom att ge dessa beskrivningar till meta-data taggen för description, som sedan visas för besökare på Googles egna sökresultats sida – som ni kan se nedan:

Meta-description visad både i kod såväl som resultat i sökmotor

Enligt vår SEO-referenssida (Moz.com) så är en rekommenderad längd på 155 tecken att föredra för vår Meta-description.

Tänk på att texten skall locka in besökare på din webbsida när de får upp din sida som ett av sökresultaten hos t ex. Google, och därför bör skriva texten så marknadsförande och lockande som möjligt på 155 tecken (inkluderar mellanslag).

Exempel på hur Meta-description skrivs kan ses nedan:

<meta name="description" content="Här placerar vi vår beskrivning av denna undersida" />

Meta-data taggen för: robots – för instruktion om hur en webbsida skall sökmotorindexeras

Meta-data taggen för robots används för att bestämma vilken typ av åtkomst som indexeringsrobotar är tillåtna att ha på din webbsida när de skall indexera denvart de får lov att indexera, såväl som vad för något de får lov att indexera.

För meta-data taggar som finns tillgängliga finns en väldigt bra referenssida på nätet kallad Metatags.info, kolla gärna in den sidan för mer information om ni skulle vara intresserade, finns även tillgänglig på vår Länkar-sida.

De vanligaste värdena jag själv har använt för meta-data taggen för robots har varit "noindex, nofollow" när jag önskat att en viss undersida eller webbsida inte skulle bli indexerad, såväl som "index, follow" om jag vill att undersidan/sidan ska indexeras, såväl som att följa länkar på sidan och även indexera de sidorna, se kodexempel nedan:

<meta name="robots" content="index, follow" /> <!-- För indexering av hela hemsidan -->

<meta name="robots" content="noindex, nofollow" /> <!-- För ingen indexering -->

Och för mer information om Meta-robots taggen kan ni kolla referenssidan Metatags.info för mer detaljer ;)

Man lär sig av sina misstag brukar man ju säga, och i det här fallet lärde jag något nytt om WordPress…

Tydligen så formateras inte rubriktexterna för inlägg som man publicerar (märkligt med tanke på att inläggets själva innehåll formateras), och jag hade tidsinställt publicering av mitt senaste sökmotoroptimeringsinlägg till kl: 10:00 idag, och när det då publicerades, så verkar det som att <title> taggen jag har i rubriktexten, inte blev formaterad som jag trodde att den skulle bli, därmed sabbade detta stora delar av webbsidan och gjorde den praktiskt taget oläslig för alla besökare.

Så nu kan ni se också hur mycket skada ett litet misstag med taggar verkligen kan göra i praktiken! :) Bra praktiskt exempel, och för er som missade bloggens lidande när en <title> tagg i rå kod introducerades mitt inuti en <body> tagg utan att stängas(!), så kan jag meddela att den i stort sett förstörde efterföljande kod från rubriken och nedåt genom att agera som ”o-stängd tagg” (se goda praktiker från XML inlägget) och dessutom en <head>-specifik tagg (<title> ska bara vara i <head>).

Låt detta även agera varning för alla er andra som funderar på- eller redan bloggar om kod osv. Jag valde nu för detta inlägget att använda <title> tagg i rubriktexten för att vara så ”korrekt” och lättförståeligt som möjligt, men har aldrig tidigare stött på bevis som skulle indikera att rubriktexter inte skulle formateras i WordPress.

Inte så lätt att veta kan jag tycka då resten av inläggens innehåll formateras…

Hursomhelst, nu vet även ni att man bör undvika detta, eller göra som jag nyss gjorde för att åtgärda felet – formatera taggen (om man tvunget vill ha en tagg i rubriktexten som jag ville) manuellt med &lt; för <-tecknet, och &gt; för >-tecknet (lt = less-than, gt = greater-than – hjälper att komma ihåg tycker jag själv när man förstår varför det heter just LT resp. GT i specialtecken koden för HTML för specifika tecken :) ).

Jag ska inom kort skriva ett inlägg som mer i detalj förklarar och går igenom HTML-specialtecken och kodning av dessa (formatering) där vi bland annat kommer ta upp ovan som användes för att lösa problemet vi fick av vår <title> tagg i rubriken :)

Ville bara informera och meddela så ni vet vad det var som hände, och varför, såg det som ett ypperligt tillfälle att styrka varför man bör vara noga med hur man utvecklar sina webbsidor :)

Tills nästa inlägg- :)

 

 

<title> taggen är viktig av ett flertal anledningar, dels då den kan användas som stöd för dina besökare om de skulle tappa bort sig på din webbsida då <title>-taggen’s text placeras i webbläsarramen– eller för er som surfar med flikar i webbläsaren – så blir det en typ av ”titeltext” för fliken där webbsidan visas (Större behov/populärare förr i tiden).

Numera har <title> taggen mer övergått till ett annat viktigt syfte och funktion att fylla – nämligen för On-page sökmotoroptimering.

Hur funkar då detta? Jo, eftersom <title> taggen är så högt värderad av sökmotorerna för att ”fiska”/leverera information om vad din sida handlar om, så kan det vara smart att inkludera lite nyckelord vad just din webbsida handlar om såväl som kanske ditt företagsnamn eller namn på webbsidan, eller liknande.

För tidigare webbsidor jag själv tagit fram så brukar mina <title> taggs-texter se ut som följer:

Webbsida/Företags-namn (- Tel: XXX-XX XX XX, E-post: Dummy@email.com) @ Startsidan - Nyckelord1, Nyckelord2, Nyckelord3, osv.

Som ni ser ovan brukar jag alltid först ha med webbsidan eller företagsnamnet, följt av (ibland) de viktigaste kontaktdetaljerna – dock bros detta på lite hur viktigt kontakt är och om det är mer värdefullt än t ex. att få med fler nyckelord för att representera sidan och dess syfte. Man måste nämligen tänka på att längden av <title> taggen inte är oändlig, och alla sökmotorer tillåter ”x” antal tecken att visas på deras sidor från <title> taggen, vilket man kanske bör anpassa sig efter om man vill att allt i ens <title> tagg skall synas på sökresultat sidorna.

Ett praktiskt exempel för att se hur indexerade webbsidors <title> tagg presenteras

Ni bör tänka på att det ni skriver som er <title>-text är det som kommer att synas på Google på följande sätt (se bild nedan):

interconnected title-tag search on google result page

Med detta så förstår ni säkert hur SEO-viktigt innehållet i en <title>-tagg verkligen är – då detta är det allra första (och största) som besökare som Googlar för att hitta saker får se på Googles sökresultats sida!

Så tänk noggrant igenom vad just er webbsida bör marknadsföras med såväl som vad ni anser vara viktigt att ha med i er <title>-text :)

Praktiskt exempel och rekommendation från grym SEO-blogg: MOZ.com

För att hjälpa er på traven med hur en <title> tagg kan skrivas så ska jag här nedan citera ett förslag från en grymt bra sökmotoroptimerings blogg på nätet på vilken form man kan skriva för ett bra resultat:

Primary Keyword – Secondary Keyword | Brand Name

Sist men inte minst, tänkte jag även nämna en ”guideline”/måttstock som ni kanske vill överväga att följa när det gäller hur många tecken en <title>-text bör bestå utav för att synas på bästa möjliga sätt hos diverse sökmotorer – även detta inspirerat från ovan SEO-blogg.

MOZ.com rekommenderar alltså 55 tecken för att vara på säkra sidan då detta tydligen presenterar <title>-texten på bästa möjliga sätt i 95% av fallen (se länk ovan), annars säger de även att 50-60 tecken brukar vara rekommenderade mängden tecken för en <title>-text.

Undantag till rekommendationen och vad det kan leda till

Dock så anser jag själv att det är OK att överskida denna gräns Om* du anser att du kanske fått med det allra viktigaste på de första 55 tecknen, men ändå vill fortsätta fylla ut med innehåll – det utfyllda innehållet kommer dock inte att hjälpa mycket med sökmotorernas indexering av din sida – däremot kanske det kan hjälpa besökare om de skulle kolla på din <title>-text för att få mer information om sidan som alltid finns tillgängligt.

För vad som händer om du skulle överskida säg 55 tecken i din <title>-text hos sökmotorerna är egentligen bara att de ”skär av” överskottet så att det inte syns med i sökresultats rubriktexten på Google. Och då ersätts helt enkelt ditt överskott av 3 st. ”punkter” (), istället för resten av <title>-texten <- som jag visat här till vänster inom parenteserna.

Testa själva – med hjälp av <title> text emulator

Om ni vill testa hur potentiella <title>-texter ser ut och fungerar så kan ni kolla ovan angivna länk där MOZ.com även delar med sig av en <title>-text emulator verktyg för att testa <title>-texter och se hur de blir. Kanske kan vara användbart, roligt och intressant :)

Värt att tänka på när ni skräddarsyr just er <title> text

En annan grej värd att tänka på(!) är att även dina mellanslag räknas in i de 55 tecknen man bör hålla sig till!

Slutkläm

Då tror jag vi kan anses vara klar-informerade om vår <title>-text och hur man skriver denne för bästa möjliga sökmotoroptimerings resultat på sidan, i nästa inlägg kommer jag att gå igenom meta-taggar och vad de används till och hur de fungerar :)

Vi kommer där titta närmare mer specifikt på meta-taggarna för: keywords/nyckelord på sidan, description/beskrivning för sidan, såväl som regler för hur indexeringsrobotar som ”crawlar sig in”/besöker sidan skall/får lov att indexera den- och dess sammanlagda innehåll via: meta-robots taggen.