Følg SEO standarderne … for helvede!

SEO er på langt fra alle punkter en eksakt videnskab. Men der er dog efterhånden en del veletablerede standarder, som der er bred enighed om bør følges.

Derfor undrer det mig meget, at alt for mange udviklere og webbureauer ikke overholder disse udemarkedet standarder. Ikke mindst set i lyset af, at udviklere normalt er store fortaler for netop åbne standarder. Nu er de her – så brug dem da for helvede!

Helt egoistisk kunne jeg naturligvis skide det en høstblomst. Jeg tjener masser af penge på at hjælpe danske virksomheder med at rette op på deres mangelfulde websites.

Men jeg synes bare det er en smule latterligt at skulle blive ved med det. Jeg ville hellere bruge kræfterne på at øge synligheden og effekten af nogle grundlæggende gode websites, frem for at skulle rette banale fejl.

Og jeg er helt sikker på at kunderne faktisk har en forventning om at de sites de får leveret lever op til gældende standarder- også i forhold til SEO. Det gør de bare (som regel) ikke.

I dette indlæg vil jeg se lidt nærmere på nogle af de standarder jeg synes du med rette kan forvente, at dit website skal leve op til.

Mobilvenlighed, AMP og PWA

De fleste websites laves heldigvis i dag i Responsivt Webdesign. So far so good. Men det er bare ikke nok i dag.

Det er langt de færreste der som standard får AMP med i deres løsning og det er dumt. AMP burde være en helt naturlig option på ethvert nyt website – og ikke en meget kostbar tilføjelse efterfølgende.

Mange virksomheder hænger også fast i en – for mange, forældet tanke om at de skal have en mobil app. I dag findes der et alternativ, som for de fleste er langt bedre i form af Progressive Web Apps (PWA).

Jeg oplever bare stadig – trods det at denne standard har været på markedet i snart et stykke tid, at næsten ingen udviklere og webbureauer forslår det til fordel for apps.

En kombination af et godt mobiloptimeret og responsivt website, AMP og PWA – hvis man har brug for app-lignende funktioner, er efter min mening den bedste løsning i dag, alle elementer er veldokumenteret – så hvad venter I på?

Et website kan aldrig blive for hurtigt

Jeg har stadig til gode at møde nogle der synes mit website var godt, men at det baaaare lige var en anelse for hurtigt. Det sker bare aldrig :-)

Hurtige websites er bedre. Google kan bedre lide dem og de giver højere konverteringer. Punktum.

Hvor hurtige de så skal være og hvordan man vælger at måle, det kan man så naturligvis diskutere. Men det bør i alle fald ikke overlades til tilfældighederne.

Google har, ligesom de besøgende på dit website, mest fokus på hvor hurtigt det første indhold – above the fold, vises. Om indholdet lidt længere nede på siden indlæses en anelse langsommere gør knap så meget.

Jeg ved godt at render blocking elementer kan være lidt besværlige at deale med som udvikler, men det er altså ikke umuligt. Tuff shit. Tag nu fat i det og løs det! Med de, i øvrigt mange virkelig dygtige webudviklere vi har i Danmark, burde det altså være muligt at få på plads.

I alle fald synes jeg det ville tjene alle bedst hvis der hver gang et nyt website blev lavet blev snakket lidt mere konkret om hastighed og aftalt hvilke standarder og mål der skulle følges.

Schema data er et must

Jeg må indrømme at jeg heller ikke forstår, hvorfor så mange websites i dag fødes uden Schema-data. Nogle har lidt, mange har intet med de fleste har langt fra så fyldestgørende Schema-data som ethvert website burde have i dag. Og mange har banale fejl.

Schema er efterhånden en gammel og meget veldokumenteret standard. Der findes både generelle objekter, som alle bør have med – som virksomhedsinformationer, indholdstyper, ratings, breadcrumb navigation osv. – og mere specialiserede objekter til f.eks. bøger, koncerter, opskriftssamlinger og data om bestemte brancher.

Det burde være helt standard i dag, at i hvert fald alle de generelle Schema-data blev medtaget, samt at man lige tog sig den lille ulejlighed at tjekke om der var nogle vigtige Schema objekter for lige ens branche og virke som det ville være klogt at tage med.

Men jeg oplever desværre at Schema stort set aldrig er oppe at vende, når nye websites skal laves. Hvor er den faglige stolthed?

Og så er det i øvrigt med Schema, som så meget andet på nettet, en standard der udvikler sig. Nye objekter kommer hele tiden til og du bør hver gang vurdere om du skal opdatere.

Lige nu er der f.eks. (stadig pending) ”Speakable” objektet, som bliver meget vigtigt i forhold til Voice Search.

Social META-data mangler

I forlængelse af den manglende Schema-data undrer det mig mindst ligeså meget, at Social META-data håndteres så lemfældigt som det er tilfældet.

Schema, Facebook Open Graph og Twitter cards bør som standard implementeres på alle websites. Det er veldokumenterede standarder, som har eksisteret i flere år.

Mange websites har slet ingen Social META-data. Nogle har lidt men ofte meget mangelfuld data, og de fleste håndterer slet ikke social images korrekt – hvilket måske er det vigtigste Social META-objekt.  

Det er mildt sagt for åndssvagt.

Basale kodefejl koster dyrt

Jeg oplever dagligt helt basale kodefejl og mangler som koster de virksomheder der er ramt af det dyrt. Det er i sandhed pinligt.

Som blot et par eksempler implementerer de færreste danske virksomheder Hreflang-standarden på websites der findes på flere sprog. Det er dumt ikke at udnytte de åbenlyse fordele det giver.

CANONICAL-tags implementeres også alt for ofte forkert. F.eks. henviser CANONICAL-tags ofte til sider, der er udelukket fra crawling eller indeksering, CANONICAL-tags peger på sig selv – selv når der er tale om produktvarianter, der netop ikke skal gøre det, eller der er flere CANONICAL-tags på samme side, så søgemaskinerne naturligvis ikke aner hvad de skal stille op.

Et andet eksempel på kode-fejl jeg ofte oplever er ved paginering. Her bruger mange webudviklere CANONICAL-tags eller NOINDEX på undersiderne, selvom den nyere og bedre standard: REL-propertien NEXT/PREV er langt at foretrække.

Man kan ikke forvente at almindelige kunder skal kunne gennemskue sådanne fejl. Men jeg synes godt, at man kan forvente at webbureauer og webudviklere implementerer de her ting – og gør det rigtigt!

Duplicate Content skader

Der kan naturligvis være mange årsager til duplikeret indhold på et website og man kan altid diskutere hvis skyld det er. Men hvad man ikke kan diskutere er, at det er noget lort at have det.

Noget Duplicate Content skyldes at indhold bruges på tværs af sites og sider – og det er naturligvis ultimativt kundens eget ansvar. Men rigtig mange Duplicate Content problemer opstår også fordi, der er grundlæggende webarkitektur problemer som jeg mener udviklerne burde have løst.

Uanset hvad det er og hvis skyld det er, så er det i hvert fald problematisk at så mange websites har så alvorlige problemer med Duplicate Content, som det faktisk er tilfældet.

For faktum er, at det hele kan løses hvis ellers man bare er opmærksom på det og tager problemet alvorligt.

En blind tro på Google skader ofte mere end det gavner

Nu startede jeg med at skrive, at der er en masse standarder, som har indflydelse på SEO og som jeg mener udviklere og webbureauer generelt bør overholde.

Men med til historien hører også det lidt besværlige faktum, at der også er en del forhold som der ikke er ordentlig veletablerede standarder for. Og værst af alt, der er nogle ret vigtige detaljer som Google desværre har det med at misinformere lidt om.

Et af de mest alvorlige problemer i den kategori er JavaScript og rendering af indhold.

Mange udvikler er, sådan set forståeligt nok, glade for de nye JavaScript baserede frameworks som Angular, Vue og React. Og i princippet kan disse godt implementeres på en søgemaskinevenlig måde. Det sker bare alt for tit ikke – nok mest af alt fordi, udviklerne tror lidt for meget på Googles evner til at fortolke JavaScript.

Resultatet er, at alt for mange ender med et website der i praksis stort set ikke kan indekseres – og så er alt det andet arbejde der laves med SEO spildt.

Tag teknisk kyndige SEO folk med på råd når du laver nyt website

Jeg har fuld forståelse for, at webudviklere ikke kan følge med i alle detaljer omkring SEO. Jeg synes som sagt, at de bør følge de fornuftige standarder der nu engang eksisterer, men tilbage står der alligevel ofte en række udfordringer, som de ikke lige ved er et problem – og endnu mindre hvordan de lige løses bedst.

Fair nok.

Den eneste gode løsning på det er, at du inddrager teknisk kyndige SEO-folk så tidligt i processen som muligt. På den måde kan alle de forhold der spiller ind på SEO afdækkes og de bedste løsninger på samtlige udfordringer vendes med udviklerne.

Så får du et godt website, der fungerer optimalt i Google. Og udviklerne undgår at blive konfronteret med alle mulige forstyrrende detaljer undervejs i arbejdet.

Stil krav til dit webbureau

Uanset om du tager en SEO-teknisk kyndig person med på råd inden du planlægger et nyt website eller ej, så ligger aben hos dig.

Du har ansvar for at stille de rette krav til dit webbureau. Det ville være dejligt hvis de selv forstod vigtigheden af alle ovenstående ting (og meget mere), men min bitre erfaring er, at det gør de sjældent.

Så DU må stille de nødvendige krav. Så skal dit webbureau nok også leve op til dem. De laver trods alt, i reglen det man beder dem om.