Den definitive guide til WordPress SEO

Subdomæne-redirects — med eller uden www?

Vi starter med en anbefaling til dem, der skal installere WordPress: beslut dig før installationen for, hvilken version af domænet du foretrækker, med www eller uden, for når du starter en WordPress-installation — for eksempel i CPANEL — får du mulighed for at køre hele installationen under den version, du foretrækker, så den version, du ikke valgte, bagefter bliver omdirigeret.

Har du sprunget det skridt over, skal du arbejde med htaccess-filen. Der findes plugins som WP HTACCESS EDITOR, der gør det lettere at redigere filen, men jeg anbefaler, at du beder om hjælp, hvis du ikke er sikker på, hvad du gør, for filen er helt grundlæggende for, at websitet fungerer.

Vælger du alligevel at arbejde med den mulighed, er her koden, du skal tilføje.

Omdiriger domæne uden www til med www

RewriteEngine On
RewriteCond %{HTTP_HOST} ^yourdomain.com [NC]
RewriteRule ^(.*)$ http://www.yourdomain.com/$1 [L,R=301]

Omdiriger domæne med www til uden www

RewriteEngine on
RewriteCond %{HTTP_HOST} ^*www.yourdomain.com*
RewriteRule ^(.*)$ http://yourdomain.com/$1 [R=301,L]

Alligevel vil jeg understrege igen, at redigering af htaccess-filen er noget, du skal være helt sikker på, så tag en backup først, hvis du går i gang.

Installation af WordPress: de første skridt i optimeringen

Først og fremmest skal du forstå, hvordan Google arbejder, og at enhver handling, du foretager, så vidt muligt skal gøre Googlebots arbejde lettere, når den besøger vores site.

Hvorfor siger jeg det?

Fordi netop dette punkt er en af de mest almindelige fejl, brugere begår — ikke kun WordPress-brugere, men alle webdesignere og webmastere.

Er dit indhold ikke færdigt, så lad ikke Googlebot få adgang til det, for du bremser rankingprocessen for dine URL'er.

Så hvis jeg skal anbefale noget, før du går i gang, er det »bed søgemaskiner om ikke at indeksere mit indhold«.

Indeksering af WordPress: hvornår bør jeg indeksere mit site?

Under installationen har vi mulighed for at blokere adgang fra søgemaskiner på opsætningsskærmen. Men har vi sprunget det over, kan vi gøre det fra Indstillinger > Læsning.

Mulighed for at blokere robotadgang

Dette »forbud« kan også laves fra den populære Robots.txt-fil. Er du en bruger med mere erfaring i webudvikling, kan du via en FTP-konto, der er oprettet eller udleveret af din hostingudbyder, lægge filen i den hovedsti, hvor dit site ligger.

Robots.txt-filen kan laves ganske enkelt med Notesblok (Windows) eller TextEdit (Mac), men husk, at det skal være en tekstfil; i den tilføjer vi disse to linjer:

*User-agent: **

Disallow: / I denne liste kan vi se de mest populære Google-crawlere (User-Agents)

Forskellige Google-user agents

I vores kode siger vi med User-agent: *, at vi mener alle bots — ingen af dem kan få adgang til vores website. Vi kan også henvise til en enkelt bot (Googlebot, Googlebot-Video osv.), men på dette tidspunkt anbefaler jeg det ikke. Så: alt blokeret.

URL-struktur og pæne URL'er

Når vi har gjort det klart, hvilket domæne vi foretrækker, og blokeret adgangen for robotter, går vi videre til URL-strukturen.

Det er et skridt, der skal tages før crawling og indeksering, for ellers skal vi ud i redirects, og det er ikke ideelt.

WordPress giver dig som standard muligheder, så du kan vælge den, der bedst strukturerer indholdet på dit site. Valget afhænger af projektet og af den enkelte; alle muligheder er brugbare, hvis projektet kræver det.

Lad mig forklare:

Inde i WordPress-dashboardet går vi til Indstillinger > Permalinks

Og vi finder denne skærm:

URL-struktur med permalinks

Som sagt afhænger valget af den enkelte, men taler vi SEO, er det bedre at arbejde med et mere pænt URL-format.

Hvad er pæne URL'er?

Vi kalder URL'er pæne, når de er forståelige for brugeren og med det samme giver en semantisk fortolkning af URL'ens indhold.

• ›Pæn URL: /blog/
• ›Ikke-pæn eller dynamisk URL:* https://seocrawl.com/?ref=13535?sfas

Den første URL giver dig information om det indhold, du vil finde, den anden gør ikke, men det betyder ikke, at Amazon gør noget forkert — den bruger snarere forskellige kontrolparametre til internt at identificere sine URL'er.

Husk, at med millioner af produkter og kategorier gør tal kontrollen lettere for dem.

Når den præcisering er på plads, og vi ser på mulighederne, har vi 3 typer URL'er:

• ›Med dato
• ›Med navnet på indlægget eller posten
• ›Tilpasselig via variabler.

Permalinks i WordPress

URL'er med dato

Mange SEO-konsulenter afviser disse URL'er, især fordi de afslører, hvornår indlægget er lavet, men denne type URL er meget nyttig, når du har en stor mængde indhold.

For eksempel nyhedsmedier. Kigger du på alle deres URL'er, har de datoen med. For et nyhedsmedie er en logisk struktur, så URL'erne kan gemmes i arkivet, helt afgørende, og den er også en identifikator, der er praktisk, når man vil vide, hvornår en historie er udgivet.

• ›https://elpais.com/tecnologia/2019/11/25/actualidad/1574676898_992149.html

El País bruger en blandet type URL, for den har semantisk information som kategorinavn, dato og underkategori og slutter med en nyhedsidentifikator.

Andre aviser tager ud over nyhedsidentifikatoren også ord fra nyhedens overskrift med i URL'en.

• ›https://www.levante-emv.com/sucesos/2019/12/12/marta-calvo-asesino-serie-valencia/1955157.html

Når man arbejder med URL-syntaks, er der en meget interessant mulighed, som ofte bliver filtreret: stopord.

Stopord er ord, vi vil undgå, når vi laver en ny URL. Det gøres gennem programmering — i vores WordPress-tilfælde gennem PHP.

Eksempler på stopord er: artikler, stedord, tal osv.

Rank Math har en mulighed, der lader dig undgå den slags ord.

Fjernelse af stopord, når URL'er laves

URL med navnet på indlægget eller siden

En enkel og meget udbredt mulighed. Vores URL'er dannes med navnet på indlægget eller med den slug, der er ændret.

Sluggen eller permalinket kan redigeres i indlæg, så vil vi ikke have den automatiske mulighed, WordPress giver os, ændrer vi URL'en manuelt (kun indlægget, ikke domænet).

Tilpasset URL med variabler

Som du kan se, kommer forskellige variabler i spil her til at bygge en URL, som vi vil have den.

Variabler giver mere information til brugeren. Vil du strukturere dit indhold på en måde, der kræver, at du tilføjer en variabel, så vælg den mulighed.

Jeg giver dig et eksempel: vi vil angive kategori, år, postens navn og identifikator i vores URL.

https://seocrawl.ai/%category%/%year%/%postname%/%post_id%/

Informationsarkitektur: kategorier, forældresider og tags

Vi skal forstå alle de muligheder, WordPress giver os til at arbejde med indhold, før vi går i gang med informationsarkitekturen.

Som du sikkert allerede ved, har WordPress sine særheder, og selvom et indlæg og en side kan se ens ud på overfladen, adskiller funktionaliteten og pluginsene dem.

At strukturere indhold er en grundlæggende del af SEO, når man skal arbejde med linkning og med at relatere beslægtet indhold — det, der kaldes indholdsklynger.

Til det kan vi arbejde med:

• ›Kategorier
• ›Tags
• ›Indlæg (posts)
• ›Sider
• ›Undersider

Kategorier, tags og indlæg (posts)

Der er to måder automatisk at gruppere indlæg i WordPress: med kategorier og med tags.

Hvornår bruger vi kategorier, og hvornår bruger vi tags?

Når vi forstår, at kategorier og tags hjælper os med at gruppere indhold, skal beslutningen om at bruge dem altid afhænge af, hvor meget indhold vi skal producere, for ellers kan vi ende med at duplikere indhold.

Både kategorier og tags hjælper os med intern linkning og med, at Google crawler alt vores indhold, men som sagt skal man vide, hvordan man bruger dem.

Mit råd er at bruge kategorier, når vi jævnligt skal lave indhold inden for vores sites tema.

Vi bruger tags, hvis der inden for bestemte emner er en stor mængde indhold, der har noget til fælles.

Jeg giver dig et eksempel:

Sport ville være en kategori, men Cristiano Ronaldo kunne være et tag — alligevel bør du spørge dig selv: hvor mange historier skal jeg lave om Cristiano Ronaldo?

Skal vi ikke lave nok indhold til, at vores sidegrupperinger reelt adskiller sig fra hinanden, har vi to muligheder: enten ikke at lave kategorien eller tagget eller ikke at indeksere dem.

Når vi arbejder med kategorier og tags, findes der andre tilføjelser, der hjælper vores indhold med at hænge sammen med beslægtet indhold.

Brødkrummer eller navigationssti

WordPress bygger navigationsstien ud fra det strukturerede indhold i kategori og post, så vil vi bruge brødkrummer for at sikre, at vores indhold er godt linket, bør vi vælge den type arkitektur.

Så vores post ville se sådan ud:

• ›URL : sitename.com/category/category-name/post-name
• ›Brødkrumme: Forside > Kategorinavn > Postnavn

Der findes plugins til at tilføje brødkrummer, men de trækker alle på den DB-struktur, vi har i vores WordPress; den dag i dag kender jeg ikke et plugin, der giver fleksibilitet i definitionen.

Som du sikkert allerede har bemærket, indfører URL'en på en post med en kategori ordet CATEGORY.

Det kommer som standard med WordPress, altså finder du det i alle WordPress, og den mulighed, du får i permalinks, lader dig kun bytte ét navn ud med et andet (category med et andet ord).

Vi har flere muligheder for at løse det — igen giver Rank Math os muligheden:

Og der findes også plugins, der hjælper dig med at fjerne ordet og efterlade en renere URL.

Plugins til at fjerne Category fra WordPress-URL'en

Forældreside og underside

Tilbage til indholdsstrukturen: der er en måde at arbejde på, som jeg godt kan lide, og det er med sider og undersider. Jeg bruger typisk den slags struktur til landingssider for services eller til hub-sider.

Forskellen ligger mest i den designfrihed, en side giver dig, og som en kategori ikke gør. Både kategorier og posts er styret af WordPress-temaet eller skabelonen, men sider kan designes, som du vil, ved hjælp af page buildere (plugin eller tilføjelse til at tilpasse sitet med blokke).

Hvornår bør vi bruge en side og en underside?

Det tydeligste eksempel, jeg kan komme i tanke om, er, når vi har en generel service og flere mere specifikke services. Vi laver en side til den generiske service og undersider til den specifikke service.

• ›Generisk landingsside: Design
• ›Specifik landingsside: Webdesign, grafisk design, produktdesign, industrielt design ...

URL-eksempel:

sitename.com/design/web/

sitename.com/design/graphic/

sitename.com/design/product/

Brødkrumme: *Forside > Design > Webdesign *

Til det skal vi i artikeleditoren (post eller indlæg) slå panelet Sideattributter til, som findes øverst.

Nu er der i højre side af vores side tilføjet et modul med sideattributterne.

Ved at vælge en af de eksisterende sider kommer den aktuelle side til at afhænge af den valgte og bliver dermed en underside til den.

SEO-plugin til WordPress: Rank Math, Yoast ...

Når vi har styr på vores URL-struktur og en del af informationsarkitekturen, ville jeg her tage installationen af SEO-pluginnet med (Rank Math, Yoast, All In One SEO ...). I dag gør de plugins dit liv lettere SEO-mæssigt, for de har de nødvendige værktøjer til at arbejde med SEO i dit indhold.

Når pluginnet er installeret, er det tid til at tilføje tracking- og verifikationskoden for det website, vi vil følge. Som analyseværktøjer findes der ikke bedre end Google Analytics og Search Console.

Trackingkode eller Google Analytics-kode

Som du vil se i WordPress — hvis du ikke allerede har det — er der altid flere måder at gøre en ting på.

For at indsætte Analytics-trackingkoden eller tracking-id'et kan vi gøre det via kode i sidens egen HTML, via skabelonen, der som regel giver plads til at indsætte kode i headeren, eller med et plugin.

Ved du ikke, hvordan du får fat i Analytics tracking-id'et, viser Googles supportside dig vejen https://support.google.com/sites/answer/97459?hl=en

Google har sit eget plugin til WordPress (Site Kit Google), hvor vi kan have hele analysedelen.

Vi har også enkle muligheder for at tilføje Google Analytics-trackingkoden.

I dag tager designere allerede højde for de webmasterbehov og tilbyder i skabelonopsætningen et felt til at indsætte koden i headeren.

Verificering af vores WordPress i Search Console

Der er forskellige måder at verificere et domæne i Search Console, jeg fortæller dig om 2: en med Googles verifikationsfil og en anden med det SEO-plugin, vi skal arbejde med.

• ›Google Search Console-verifikationsfil.
• ›Med ejendommens verifikationskode

Til nem verificering kan vi igen bruge Rank Math.

I det første felt kan vi direkte indsætte det id, vi finder i verifikationsdelen af Search Console (klikker vi på teksten i feltet, kommer vi direkte til den URL, der giver os den information).

Derefter skal vi bare tilføje det id, der er markeret med rødt nedenfor.

<meta name="google-site-verification" content="example code" />

Sådan laver du et sitemap i WordPress

Et andet punkt, der skaber debat i SEO-branchen, er sitemaps. Filen plejede at være vigtig, for at Google kunne få adgang til alle vores URL'er.

Det er rigtigt, at tingene har ændret sig, og at Google ikke har brug for en fil for at crawle dit site helt. Men det er lige så rigtigt, at du med Search Console og sitemaps får ekstra information, der kan hjælpe dig med at løse fremtidige URL-problemer.

Der er mange måder at lave et sitemap på, men det ideelle er, at det er en dynamisk fil, der opdateres med nye indlæg eller sider.

Uanset om vi bruger Yoast eller Rank Math eller en anden slags SEO-plugin, skal vi bare slå funktionen til for at få adgang til den.

For at forklare det bruger jeg værktøjet fra Rank Math, og vi går til Sitemap Settings.

Eksempel på sitemap-opsætning i Rank Math

Som vi ser på billedet, kan vi tilpasse forskellige indstillinger for den type URL, vi skal arbejde med.

• ›Links pr. sitemap: 1000 (vi lader den foruddefinerede mulighed stå; det handler om antallet af URL'er, vi vil have i vores fil)
• ›Billeder i sitemaps: jeg anbefaler at slå den til, hvis dine billeder er originale og giver information til artiklen.

Under alle omstændigheder crawler Google let dine billeder, hvis du bruger billeder i dit indhold.

De to første felter i denne del af opsætningen er til at udelukke indlæg eller sider, du ikke vil have med i sitemappet.

Det gøres via identifikatoren, og vi finder den sådan her.

Går vi til indlægs- eller sidesektionen og holder markøren over et indlæg uden at klikke, dukker URL'en op nederst.

Kigger vi nederst, i den røde boks, ser vi post=5745 — tallet er den identifikator, vi skal bruge for at forhindre siden i at dukke op i sitemappet.

Den næste mulighed er taksonomier, altså at gøre det samme med TAGS og kategorier.

Rank Math-muligheden er begrænset og kommer foruddefineret til at generere 5 typer sitemaps (indlæg, sider, medier, kategori og tags)

Det er op til dig at beslutte, hvilket sitemap du ikke vil have — mit råd er, at du ikke laver et sitemap over URL'er, du ikke vil have Google til at se (noindex eller blokeret af robots).

Når den første del er på plads, går vi videre til indholdsdelen og forklarer, hvilke faktorer du skal være opmærksom på, og hvordan WordPress fungerer, når indhold skal optimeres.

Optimering af indhold til WordPress

Når vi begynder at optimere en side eller et indlæg, skal vi vide, hvad vi skal tage højde for.

De vigtigste tags i indholdsoptimering er:

• ›Title <title> i HTML
• ›Description <meta name="description" content=" beskrivende tekst" >
• ›Overskriftshierarki <h1, h2, h3, h4… >
• ›ALT-tag <img src="billed-url" alt="billedbeskrivelse">

Optimering af sidehastighed i WordPress (WPO)

Nu bliver det alvor — det er en del, der virkelig giver enhver webmaster hovedpine, fordi mange variabler påvirker indlæsningen. Vi har forskellige værktøjer til at måle indlæsningshastighed — jeg fortæller dig om dem, jeg bruger, og hvordan jeg bruger dem.

Grundlæggende begreber

En WPO-analyse (Web Performance Optimization) laves for at forbedre dit sites indlæsning. Værktøjerne er ikke 100 % præcise, og hver bruger kan få forskellige indlæsningstider for sitet.

Derfor er vores mål, når vi optimerer et site, ikke at få den højest mulige score i de auditværktøjer, vi bruger, men at forbedre bestemte ting, så brugeren, uanset hvem det er, oplever en bedre indlæsning af vores site.

Når vi arbejder med WPO, forsøger vi at optimere det, der er inden for rækkevidde:

• ›Request: kald, som ressourcer sender til kilden (vores server eller en anden ekstern server)
• ›Total Page Size: størrelsen på de ressourcer, en side indlæser.
• ›Fully Loaded Time: den samlede indlæsningstid for siden.

Andre ting som serverens svartid kan vi godt arbejde på at forbedre, men de er ikke lige så tilgængelige for os.

Gtmetrix og Lighthouse

Vi tager fat med to tilgængelige og gratis værktøjer — altså, Gtmetrix har en betalt version, men funktionerne i den gratis er nok for os.

Til forklaringen bruger jeg et site, jeg selv ejer, hvor jeg har slået de plugins fra, der hjælper mig med optimering.

Jeg blev nødt til at bruge en ny cache-version, fordi værktøjet læste den gamle cachede version (med pluginsene slået til) og gav mig gode optimeringsresultater, hvilket ikke var det, jeg ville have til mit eksempel.

Husk: vil du have en ny cache-version, så tilføj ? til din URL efterfulgt af et hvilket som helst tegn, for eksempel url?version1

Som vi sagde før, er requests en af de grundlæggende faktorer, vi skal arbejde med. Til det analyserer vi det, der kaldes waterfall eller kaskaden af eksekveringstider.

Waterfall

Som vi ser i kaskaden, har vi 87 requests. Hvert af dem har et navn, en status, placeringen og størrelsen.

Hvordan går vi i gang?

Billeder

Kigger vi på et hvilket som helst WPO-analyseværktøj på et ikke-optimeret site, ser vi, at de anbefaler 4 typer handlinger på billedressourcer.

Reducer deres opløsning

Der findes millioner af værktøjer, både online og til PC eller MAC. Jeg kan godt lide at gøre det hele i Photoshop, men det afhænger selvfølgelig af, hvor mange billeder du skal optimere. Som onlineværktøj kan du bruge Kraken.io, men som sagt holder jeg mig til Photoshop, fordi det kan lave en mere præcis optimering.

Server billeder i den maksimale visningsstørrelse

Det er en meget almindelig fejl. At bruge et stockfoto-site, hente et 2800 x 1600-billede og bruge det på vores site i en opløsning på 900 x 400.

Min anbefaling er, at du bruger inspektøren med sidens maksimale størrelse og ser på den størrelse, der bliver brugt.

Vi ser, hvordan inspektøren fortæller os den maksimale størrelse, der bliver brugt i vores blogbilleder — det bør være størrelsen på vores billede.

Brug næste generations formater eller formater med god komprimering

Vil du ikke gøre livet for indviklet med formater som webp (udviklet af Google, men endnu ikke understøttet af 100 % af browserne), så brug JPEG og undgå PNG, medmindre du har brug for en gennemsigtig kanal.

Brug lazy loading-funktionen

Lazy load eller udskudt indlæsning er en af de mest interessante funktioner til at forhindre, at elementer som billeder eller videoer indlæses fra start. Den udskyder indlæsningen af billeder i første omgang.

Tænk på de billeder, vi har nederst på siden — hvorfor skal vi indlæse dem, hvis brugeren slet ikke er nået derned?

Plugins til billedoptimering

Selvom jeg personligt ikke er den store fan af den slags plugins, vil jeg anbefale nogle, der kan løse optimeringsproblemer, hvis du støder på sites med mange billeder.

• ›Imagify
• ›EWWW Image Optimizer
• ›WP Smush

Minificér og kombinér CSS, HTML og JavaScript

Minificering går ud på at reducere vægten af de ressourcer — jo mindre vægt en side skal indlæse, jo hurtigere går den indlæsning.

Selvom det virker som en grundlæggende handling (fordi alle anbefaler den), er det ikke en handling, vi får store resultater ud af.

Til gengæld er det mere nyttigt at kombinere, men det er også mere sarte sager.

Hvad ville være ideelt?

Det ideelle er at have små filer med de JS-funktioner eller CSS-styles, der reelt bliver brugt i den HTML, men hver designer og hver programmør bestemmer selv, hvad de lægger i deres CSS og JS. Kig på eksemplet fra mit site før optimering. Nå, jeg lyver, for selvom jeg har slået pluginsene fra, har jeg stadig minificerede filer.

29 requests alene til JavaScript. Det er vanvittigt, men husk, at når du gør noget som at indlejre en Youtube-video, indlæser du en JS-ressource (Javascript), så har du flere videoer, ganges det hele op.

Og nu viser jeg dig ressourceindlæsningen efter optimering.

Nu har vi kun 4 JS. Det skyldes kombinér-funktionen.

Med CSS'en skete det samme — vi ser før:

Og efter:

Faldet i requests skyldes ikke kun kombinering af CSS og JS — vi er også holdt op med at indlæse visse ressourcer, der ikke var nødvendige, som den typiske Wp-emoji-release.js (emojis i WordPress).

Hvad mangler vi at gøre?

For at optimere videre skal vi tage fat i hver enkelt JS og se, om der kan laves en udskudt eller asynkron indlæsning.

• ›JS Async: ressourcen hentes, uden at HTML-indlæsningen stopper, men når den er hentet, stopper den indlæsningen for at udføre JS'en.
• ›JS defer: ressourcen hentes også parallelt med HTML-indlæsningen, men den udføres til sidst i indlæsningen — scriptet blokerer ikke.

Det skal være klart, at attributten er til ekstern JS og ikke til den, der udføres INLINE (i samme HTML).

Cache-optimering

Uden tvivl en af de vigtigste dele af optimeringen af indlæsningshastighed, men vi skal huske, at for at det er nyttigt, skal brugeren have været inde på vores site før og have hentet de ressourcer, browseren skal bruge.

Altså: cache-optimering er vigtig, men den er måske ikke afgørende, hvis »den bruger« ikke besøger vores site igen.

Cache-optimering er en af de dele, alle værktøjer til indlæsningsaudit vægter højest. Nedenfor forklarer jeg de dele, du skal tage højde for.

Hvad gør et cache-plugin?

Det, et cache-plugin gør, er at lave kopier af de forskellige behandlede dele af et site (side, objekter, DB-forespørgsler) for så at servere dem og spare ventetid, når der sendes kald til serveren.

• ›Levetid eller maksimal cache-alder, før der caches igen: den faktor afhænger meget af, hvilken slags site du har — ændrer dit indhold sig ikke ofte, kan du bruge en længere varighed; opdateres dit site ofte eller flere gange om dagen, så forkort varigheden.

Har vi gjort det med et af de cache-plugins på markedet, som vi ser om lidt, kan vi i Chromes udviklerværktøjer tjekke, hvordan vi har arbejdet med funktionen:

Vi har flere cache-metoder:

• ›Last-Modified
• ›ETag (Entity Tag)
• ›Expires
• ›Max-age

Lad os indlæse vores site med Chromes udviklerværktøjer åbne og vælge Network — nu kan vi se alle de ressourcekald, vores browser sender. Klikker vi på en af ressourcerne og vælger Headers, kan vi se svaret i filernes headers, og om vi har caching slået til, og hvilken metode der bruges.

Hos SEO Alive ser vi, at det er via MAX-AGE. I den del ser vi også, om der køres GZIP-komprimering fra serveren.

• ›Cache for brugere, der er logget ind: den funktion er vigtig, så vi ikke serverer cachede sider til brugere, der er logget ind, hvis de skal opdatere WordPress, for ellers ser de ikke de ændringer, de laver.
• ›Mobil-cache: mange plugins giver mulighed for at lave forskellige »caches« til forskellige enheder — jeg anbefaler det, hvis din mobilversion er tilpasset og ikke en responsiv version.

Plugins til at optimere indlæsningshastigheden i WordPress

Jeg ville forklare de vigtigste dele af optimeringen, før vi kommer ind på plugins, for i næsten alle plugins er det, der er forklaret ovenfor, bare valgmuligheder, og det er dig, der skal vurdere, om du vil slå dem til.

Derfor ville jeg hellere forklare det, så du forstår det, før jeg fortæller dig, hvilke plugins du skal bruge til at udføre handlingerne. Det er de mest populære plugins til WordPress.

• ›WP Rocket
• ›W3 Total Cache
• ›WP Fastest Cache
• ›Autooptimize

I dem alle har du de muligheder, vi har talt om ovenfor, selvom de måske er mere begrænsede med hensyn til indlæsningstype, når det gælder JS.

Værktøjer til at måle indlæsningshastighed

Som du kan forestille dig, findes der et hav af værktøjer, der hjælper os med at kende et sites indlæsningshastighed.

Husk, at et WordPress består af forskellige typer sider, og hver af dem svarer forskelligt, så skal du lave en WPO-audit, så lav den af:

• ›Forsiden
• ›Kategorier
• ›Sider
• ›Indlæg

Det er også vigtigt, at du ved, at Google Analytics har en måling af et sites hastighed, og trækker du den efter ugedag eller måned, kan den være nyttig til at drage konklusioner.

Det er de mest populære værktøjer til at lave en WPO-audit:

• ›Google PageSpeed Insights
• ›GTmetrix
• ›Pingdom Tools

Strukturerede data i WordPress

Er du lige begyndt med SEO, kender du sikkert ikke begrebet semantisk web, men i dag er det svært at lave SEO uden at forstå det.

Google arbejder dag for dag på at blive bedre til at læse og fortolke websites, og dataopmærkning gennem semantiske metadata gør det arbejde lettere.

Til det har vi forskellige plugins, der hjælper os med at markere det forskellige indhold på vores sites sider.

Har du installeret Rank Math, har du en liste over metadata til dit indhold gennem pluginnet, synlig i fanen Rich Snippet.

Ulempen ved den mulighed er, at et stykke indhold mange gange kan have mere end én dataopmærkning — for eksempel:

Du kan tagge indhold som Blog Posting og have 3 umarkerede videoer i indholdet.

Er du fortrolig med strukturerede data, kan du tilføje HTML-blokke med Gutenberg (WordPress' blokeditor) og lægge det ind manuelt.

Google stiller et værktøj til rådighed, så du kan validere, at dine strukturerede data er implementeret korrekt.

Anbefalede plugins til at forbedre SEO i WordPress

For at runde artiklen af vil jeg anbefale nogle SEO-plugins til WordPress, der kan hjælpe dig med at forbedre dit site.

Indholdsfortegnelse

Selvom det plugin sagtens kan laves med HTML, gør de stil- og designmuligheder, det giver, det til en basisting, når brugerens navigation på siden skal forbedres.

Relaterede indlæg

I dag har mange plugins funktionen med relaterede indlæg, men husk, at hvis dit ikke har, er den funktion meget vigtig, så dit indhold altid er linket til hinanden.

Jeg efterlader dig med dette plugin, som har hjulpet mig meget med visse skabeloner.

AMP

At udvikle en side i AMP kan være en god mulighed af flere grunde: hastighed, brugervenlighed ... eller for at arbejde med placeringer i karruseller som nyhedskarrusellen i mobilversionen, hvor den slags teknologi har forrang.

Så jeg efterlader dig med et plugin, hvis du vil have dine sider i AMP — selvom der findes mange muligheder.

Video-sitemap og Google News

Selvom mange SEO-folk ikke længere bruger sitemaps, vender jeg altid tilbage til dem for at have bedre styr på indekseringen af mit indhold. Her efterlader jeg dig et plugin til at lave et video-sitemap og et andet til Google News.

Jeg håber, artiklen i nogle af sine dele er nyttig og interessant for dig, og har du selvfølgelig spørgsmål, jeg kan svare på, har du kommentarerne til at få fat i mig.