Teknisk SEO audit for React websites: Komplet guide.

Er React dårligt for SEO?

Nej.

React er et frontend-værktøj. SEO-resultatet afhænger af, hvordan løsningen er bygget og serveret.

Google kan rendere JavaScript, men crawling og rendering kan stadig påvirkes af tunge bundles, manglende ressourcer, client-side fejl, API-afhængigheder, forkert routing og ustabil metadata.

Skeln mellem HTTP-responsen, initial HTML, den renderede DOM og crawlerens faktiske resultat. Et moderne React-site kan være SEO-venligt med korrekt SSR, SSG, prerendering, metadata, routing og intern linking. Auditér derfor output og adfærd - ikke frameworknavnet.

Før auditten: forstå hvordan React-sitet renderer

Renderingstrategien bestemmer, hvornår sidens indhold bliver til HTML.

Client-side rendering - CSR

Ved ren client-side rendering sender serveren ofte en relativt lille HTML-shell. JavaScript hentes og bygger derefter siden i browseren.

Det kan fungere fint, men gør SEO mere afhængig af scripts, API-kald og routing. Hvis hovedindhold eller metadata kun opstår efter JavaScript, bør SEO-kritiske routes testes ekstra grundigt.

Server-side rendering - SSR

Ved SSR genereres HTML på serveren for den konkrete request. Det gør route-specifikt indhold direkte tilgængeligt i responsen og kan være robust for sider, der skal findes og forstås hurtigt.

SSR er ikke automatisk bedst og kræver stadig korrekt caching, metadata, statuskoder og fejlbehandling.

Static Site Generation - SSG

Ved SSG genereres HTML under build. Det passer godt til marketing-, service- og informationssider, der ikke behøver at blive genereret på ny for hver request.

For SEO-kritiske routes er statisk output ofte let at inspicere, fordi den færdige HTML kan valideres før deployment.

Prerendering

Prerendering betyder i praksis, at route-specifikt HTML produceres på forhånd eller som en del af build/deployment-processen, så brugeren og crawleren ikke er afhængig af at bygge hele hovedindholdet client-side.

Hybrid rendering

Mange sites kombinerer strategier. Spørg derfor ikke kun "Bruger sitet SSR?", men: Hvordan produceres hver vigtig sidetype, og er outputtet robust?

Trin 1 - kontrollér hvad serveren faktisk sender

Dette er et af de vigtigste trin.

Åbn en vigtig side og sammenlign:

• View Source eller den rå HTTP-response
• browserens Elements-panel efter JavaScript er kørt

Kontrollér mindst:

• H1
• vigtig brødtekst
• <title>
• meta description
• canonical
• robots meta
• structured data
• centrale interne links

Du kan også hente HTML og headers direkte:

curl -L https://example.com/service/
curl -I https://example.com/service/

Hvis sidens vigtigste indhold kun findes efter JavaScript, er det ikke automatisk en fejl. Men du bør undersøge, om renderingen er stabil, om API-kald kan fejle, og om Google ser den samme meningsfulde side.

For SEO-kritiske routes bør du kunne forklare, hvornår title, hovedindhold, links og canonical bliver tilgængelige.

Trin 2 - kontrollér title tags og meta descriptions

Hver indexerbar route bør kunne have relevant, route-specifik metadata.

Auditér:

• manglende titles
• samme title på mange routes
• generiske fallback-titles
• route-skift hvor title ikke opdateres
• metadata som kun findes i den færdige browser-DOM
• templates hvor dynamiske data giver tom metadata ved fejl

SPA-routing kan skabe fejl, hvis metadata kun ændres efter client navigation. Test derfor både direkte request og intern navigation til samme URL. Resultatet bør være konsistent.

Google kan vælge en anden snippettekst, så fokusér på unikke og nyttige descriptions - ikke en bestemt tegnlængde.

Trin 3 - kontrollér canonical URLs

Canonical hjælper søgemaskiner med at vælge en foretrukken URL blandt ens eller meget lignende sider. Det er et signal, ikke en erstatning for ordentlig URL-arkitektur.

Auditér:

• self-referencing canonical på primære sider
• HTTP vs. HTTPS
• www vs. non-www
• trailing slash-varianter
• query parameters
• duplicate routes
• canonical til en redirect
• canonical til en noindex-side
• canonical der peger på en forkert route

På client-renderede sites bør canonical være entydig. Undgå setups hvor source og JavaScript angiver forskellige canonicals, og sammenhold user-declared canonical med Google-selected canonical i Search Console.

Trin 4 - kontrollér robots meta og robots.txt

De to mekanismer løser forskellige opgaver.

robots.txt

robots.txt styrer, hvilke URLs eller ressourcer en crawler må hente.

robots meta

Et robots meta-tag på selve siden kan eksempelvis signalere noindex.

Den vigtige nuance er, at en crawler kun kan læse sidens meta-tag, hvis den må hente siden. Hvis en URL er blokeret i robots.txt, kan du derfor ikke regne med, at en noindex på siden bliver set.

Auditér:

• utilsigtet noindex
• staging-regler der er kommet med i produktion
• blokering af JavaScript eller andre ressourcer, som er nødvendige for rendering
• gamle crawl-blokeringer
• legitime private/utility paths

noindex er ikke automatisk en fejl. Login, checkout, interne søgesider og andre utility-routes kan være korrekte noindex-sider afhængigt af sitet.

Trin 5 - kontrollér XML-sitemap

Et sitemap bør primært liste de canonical URLs, virksomheden faktisk ønsker i søgeresultaterne.

Auditér for:

• 3xx-URLs
• 404-URLs
• noindex-URLs
• dubletter
• URLs der canonicaliserer til andre sider
• gamle slettede routes
• forkerte domæne- eller protokolvarianter
• dynamiske routes der mangler
• nye sider der aldrig kommer med

På et React-site med route-data i kode, CMS eller API skal du vide, hvor sitemap-generatoren får sine URLs fra. Et sitemap erstatter ikke intern linking.

Trin 6 - kontrollér statuskoder og routing

Statuskoder er et klassisk problem i client-side apps.

En React-router kan vise en flot "Siden findes ikke"-komponent, mens serveren stadig svarer:

HTTP/1.1 200 OK

Det er en soft-404-risiko. Hvis URL'en reelt ikke findes, bør server-/hostinglaget kunne returnere en korrekt 404-status.

Auditér:

• eksisterende sider -> 200
• permanente flytninger -> typisk 301 eller 308
• midlertidige redirects -> relevant 3xx
• ikke-eksisterende sider -> 404
• serverfejl -> korrekt 5xx
• redirect chains
• redirect loops

Kontrollér redirects med curl -I eller et crawler-værktøj. Client-side redirects bør ikke erstatte korrekte HTTP-redirects ved URL-migreringer.

Trin 7 - kontrollér interne links

Interne links hjælper både discovery, informationsarkitektur, kontekst og brugerflow.

Google kan mest pålideligt crawle almindelige links som:

<a href="/services/teknisk-seo/">Teknisk SEO</a>

Auditér:

• <a href=""> på elementer der fungerer som links
• click handlers på div, span eller knapper der reelt navigerer
• orphan pages
• broken links
• links via unødige redirects
• navigation
• breadcrumbs
• kontekstuelle links
• beskrivende anchor text

React Router, Next.js eller andre routere kan sagtens håndtere navigation, men den resulterende markup bør stadig være et reelt link, når elementet semantisk er et link.

Trin 8 - adskil crawlability fra indexability

Begreberne bliver ofte blandet sammen.

Crawlability: Kan crawleren hente URL'en og nødvendige ressourcer?

Indexability: Må og kan siden optages i indekset som en kandidat til søgeresultater?

En URL kan eksempelvis:

• crawles men være noindex
• opdages, men have meget svag intern linking
• crawles uden at blive indekseret
• være en dublet, hvor en anden canonical vælges
• være blokeret fra crawl og derfor ikke kunne evalueres normalt

En audit bør først definere, hvilke URL-typer virksomheden faktisk ønsker indekseret. Ellers risikerer man at behandle korrekte exclusions som fejl.

Trin 9 - brug Google Search Console korrekt

Search Console supplerer crawler-data med Googles egen vurdering.

URL Inspection

På en vigtig route bør du kontrollere:

• om URL'en er indekseret
• crawl-status
• user-declared canonical
• Google-selected canonical
• sidste crawl
• live-test
• rendered HTML/screenshot hvor relevant

Brug live-testen efter rettelser; de samlede rapporter kan være langsommere om at opdatere.

Page indexing

Se især efter mønstre:

• Crawled - currently not indexed
• Discovered - currently not indexed
• Alternate page with proper canonical
• Page with redirect
• Soft 404
• Excluded by noindex

Ikke alle ikke-indekserede URLs er fejl. Prioritér efter spørgsmålet:

Er dette en URL, vi faktisk ønsker i Google?

Trin 10 - structured data / schema

Structured data kan beskrive entities og sidetype og gøre sider kvalificerede til relevante rich results.

På et B2B-site kan relevante typer eksempelvis være:

• Organization
• BreadcrumbList
• Article
• andre typer der faktisk passer til sidens synlige indhold

Auditér:

• om JSON-LD kan parses
• om data matcher det synlige indhold
• om URLs er korrekte
• om markup er route-specifik
• om schema mangler efter client-side navigation
• om deployment ændrer outputtet

Undgå falske ratings, opdigtede reviews eller markup for indhold, som brugeren ikke kan se.

Valid schema garanterer ikke et rich result. Formålet er først og fremmest korrekt, sand og vedligeholdelig markup.

Trin 11 - Core Web Vitals og performance

De centrale Core Web Vitals er:

• LCP - loading performance
• INP - responsivitet ved interaktion
• CLS - visuel stabilitet

Praktiske "good"-grænser er LCP <= 2,5 sekunder, INP <= 200 ms og CLS <= 0,1 ved 75-percentilen af faktiske sidebesøg.

React-projekter kan især påvirkes af:

• store JavaScript-bundles
• hydration
• tunge dependencies
• animationsbiblioteker
• tredjepartsscripts
• store hero-billeder
• client-side data fetching
• fonts

React er ikke automatisk langsomt. Problemet er den mængde arbejde, browseren skal udføre, og hvornår det sker.

Brug PageSpeed Insights til field data og lab-diagnostik. Lighthouse er nyttigt til fejlfinding, men én laboratoriekørsel er ikke det samme som faktiske brugerdata.

Trin 12 - JavaScript bundle og code splitting

For meget JavaScript kan påvirke download, parsing, execution og især responsiveness.

Auditér:

• bundle size
• route-based code splitting
• lazy loading
• unødvendige dependencies
• duplicate libraries
• tredjepartsscripts
• komponenter der loader store pakker uden at bruge dem på første view

Et "unused JavaScript"-fund betyder ikke, at hele filen kan slettes; kode kan være nødvendig senere eller på andre routes. Brug fundet som startpunkt for udvikleranalyse.

Trin 13 - auditér billeder

Billeder påvirker både performance, layout og forståelse.

Kontrollér:

• passende dimensioner
• responsive images
• moderne formater hvor de giver mening
• width og height
• lazy loading
• LCP-billedet
• alt-tekst
• dekorative billeder med tom alt-tekst
• stabile billed-URLs

LCP-billedet bør normalt ikke lazy-loade på en måde, der forsinker det vigtigste indhold.

Alt-tekst skal beskrive relevante billeder for tilgængelighed og kontekst. Den skal ikke bruges som en skjult keyword-liste.

Trin 14 - heading-struktur og semantisk HTML

SEO kræver ikke et magisk antal headings. En logisk struktur hjælper dog brugere, hjælpemidler og søgemaskiner med at forstå indholdet.

Auditér:

• en tydelig hovedoverskrift
• logiske H2/H3-niveauer
• <main>
• <article> hvor relevant
• navigation
• header/footer
• buttons vs. links
• formular-labels

En knap bør udføre en handling. Et link bør føre til en URL. React-komponenter bør ikke udviske den grundlæggende semantik.

Trin 15 - dynamic routes

React-sites har ofte routes som:

/projekter/:slug
/produkter/:id

Auditér for hver dynamisk sidetype:

• kan alle vigtige URLs opdages?
• er de med i sitemap?
• kan server/build generere dem?
• har de route-specifik title og description?
• er canonical korrekt?
• returnerer ugyldige slugs 404?
• findes crawlbare interne links?
• er prerendering/build-output komplet?

Et typisk problem er, at appen kan vise enhver slug, mens sitemap, metadata eller 404-logik ikke følger med.

Trin 16 - client-side data fetching

En route kan returnere en HTML-shell og derefter hente hovedindholdet fra et API.

Det er ikke automatisk forkert. Men auditér, hvad der sker hvis:

• API'et svarer langsomt
• API'et fejler
• data mangler
• crawlerens rendering ikke får samme resultat
• metadata afhænger af data, der først kommer senere
• en bruger åbner route-URL'en direkte

For SEO-kritisk indhold kan server-side fetching eller build-time generation være mere robust, fordi hovedindhold og metadata findes tidligere i request-flowet.

Trin 17 - JavaScript-fejl

En runtime-fejl kan være alvorlig, hvis navigation eller hovedindhold afhænger af JavaScript.

Auditér browserens console og network-panel for:

• uncaught errors
• failed network requests
• hydration errors
• API failures
• chunk loading errors
• script-fejl fra tredjepart

Test både direkte landing og intern navigation; nogle fejl opstår kun i ét flow.

Trin 18 - duplicate content og URL-varianter

Kontrollér om samme indhold kan åbnes via flere varianter:

• www / non-www
• HTTP / HTTPS
• trailing slash / ingen trailing slash
• uppercase / lowercase
• query parameters
• filter-URLs
• gamle routes

Brug redirects, canonical og konsistente interne links efter behov. Målet er at gøre den foretrukne URL tydelig.

Trin 19 - mobiloplevelse

Google bruger den mobile version af indholdet til mobile-first indexing.

Auditér derfor:

• samme centrale content på mobil og desktop
• responsive layout
• navigation
• touch targets
• overlays
• billeder
• loading
• performance
• metadata og structured data hvis sitet serverer forskellige versioner

På responsive React-sites kan betinget indlæste komponenter stadig skabe forskelle mellem mobil og desktop.

Trin 20 - accessibility og SEO overlap

Accessibility er ikke et SEO-hack, men flere tekniske praksisser overlapper.

Det gælder blandt andet:

• semantisk HTML
• crawlbare og forståelige links
• logiske headings
• relevant alt-tekst
• formular-labels
• meningsfuld navigation
• klar content hierarchy

Notér derfor tilgængelighedsproblemer, når de også påvirker struktur eller funktion.

En konkret audit-workflow

En praktisk audit kan gennemføres i denne rækkefølge:

1. Crawl hele sitet

Eksportér URL, statuskode, title, description, canonical, H1, indexability og interne links.

2. Udvælg repræsentative routes

Vælg fx forsiden, en service-side, en artikel, en dynamisk route, en 404 og en route med API-data.

3. Kontrollér HTTP og initial HTML

Brug View Source, curl eller server/build-output. Notér hvad der findes før browser-JavaScript.

4. Sammenlign med rendered DOM

Kontrollér om centrale elementer ændres, mangler eller først kommer efter API-kald.

5. Kontrollér Search Console

Undersøg vigtige URL'er med URL Inspection og se efter mønstre i Page indexing.

6. Kontrollér sitemap, robots og canonical

Sammenlign crawlerens URL-liste med sitemap og den ønskede informationsarkitektur.

7. Auditér intern linking

Find orphan pages, click-handler-navigation og unødvendige redirect-links.

8. Test performance

Brug PageSpeed Insights, Lighthouse og browserens Performance/Network-værktøjer.

9. Kontrollér structured data

Valider syntaks og sammenhold markup med det synlige indhold.

10. Prioritér og implementér

Gruppér fund efter effekt og risiko. Ret kritiske indexerings- og routingfejl før kosmetiske notices.

11. Validér igen i production

Crawl den deployede version, kontrollér statuskoder og HTML-output, og test de vigtigste URL'er igen.

Prioritér fejl efter effekt - ikke antal

Et auditværktøj kan finde mange notices. De er ikke lige vigtige.

Kritisk

Eksempler:

• centrale sider er utilsigtet noindex
• vigtige routes kan ikke rendere hovedindhold
• en central side returnerer forkert status
• canonical peger væk fra en vigtig side
• production blokerer crawleren

Høj

Eksempler:

• vigtige routes mangler route-specifik metadata
• centrale sider er orphaned
• 404-routes returnerer konsekvent 200
• alvorlige LCP/INP-problemer på centrale templates
• dynamiske money pages mangler i sitemap eller build

Medium

Eksempler:

• enkelte redirect-links
• descriptions der bør forbedres
• schema-muligheder
• mindre inkonsistens i headings eller interne anchors

Lav

Eksempler:

• kosmetiske tool-notices uden reel effekt
• "manglende" schema, som ikke er relevant
• bevidste noindex-routes
• små optimeringer uden effekt på vigtige sider

Målet er ikke en SEO-health score på 100.

Målet er et website, hvor de sider der betyder noget, er crawlbare, indexerbare, relevante, forståelige og hurtige nok til den faktiske brugeroplevelse.

Typiske falske positiver i auditværktøjer

Et værktøj kan markere noget som et issue, selv om det er intentionelt.

Eksempler:

• noindex på login eller utility-routes
• redirects som bevidst konsoliderer gamle URLs
• manglende description på en side, der ikke skal indekseres
• schema som ikke giver mening for sidetypen
• links med attributter, der er valgt med et konkret formål

Hovedreglen er:

Forstå hvorfor værktøjet markerer noget, før du retter det.

Auditér websiteadfærd og forretningskritiske routes - ikke farven på tool-ikoner.

De mest almindelige React SEO-fejl

1. Samme title på alle routes. Metadata håndteres globalt i stedet for per route.
2. Hovedindhold findes kun efter JavaScript/API. Der mangler en robust renderingstrategi for SEO-kritiske sider.
3. SPA-404 returnerer HTTP 200. Brugeren ser en fejl, men serveren signalerer succes.
4. Forkert eller manglende canonical. URL-varianter bliver uklare.
5. Dynamiske routes mangler i sitemap. Sider findes i appen, men ikke i URL-generatoren.
6. Click handlers bruges som links. Navigation er visuelt korrekt, men markup er ikke crawlbar.
7. For store JavaScript-bundles. Loading og responsiveness bliver unødigt tunge.
8. SEO-routes prerenderes ikke, selv om det ville forenkle outputtet.
9. API-content fejler under rendering. Crawler og bruger kan få tomt eller ufuldstændigt indhold.
10. Intern linking er svag. Routes findes kun gennem sitemap eller direkte URL.
11. Staging-`noindex` er kommet med i production.
12. URL-flytninger sker kun client-side. HTTP-redirect mangler.

Frameworks: React er ikke én arkitektur

"React website" kan betyde meget forskelligt:

• klassisk React SPA
• Next.js
• Remix
• Astro med React-komponenter
• Vite + React med prerendering
• custom SSR
• hybrid setup

Auditten bør derfor ikke begynde med "Next.js = godt" eller "SPA = dårligt". Auditér output, statuskoder, routing, links, metadata, rendering, performance og indexeringsadfærd. Frameworket er kun en del af forklaringen.

Test production build - ikke kun udviklingsmiljøet

Et site kan fungere lokalt og opføre sig anderledes efter build eller deployment.

Kontrollér den faktiske production-version:

• generated HTML
• route-metadata
• assets
• routing
• 404
• redirects
• sitemap
• robots.txt
• canonical
• schema
• API-endpoints

Fejl kan opstå i build-time data, environment variables, CDN-regler, rewrites eller hosting-konfiguration.

Pre-deploy SEO-validering

En del fejl kan fanges automatisk før deployment.

Overvej checks for:

• title på indexerbare routes
• canonical
• sitemap-URLs
• broken internal links
• route-status
• JSON-LD parsing
• build success
• type check

På statiske sites kan et script fx kontrollere, at vigtige routes indeholder title, canonical og hovedindhold.

Automatisering erstatter ikke manuel SEO-review. Den er bedst til kendte regressionsfejl: ting som altid skal være sande før production.

Hvornår er problemet ikke teknisk SEO?

Et teknisk perfekt site kan stadig have lav organisk synlighed.

Problemet kan være:

• meget lav søgeefterspørgsel
• forkert search intent
• tyndt eller udifferentieret indhold
• stærk konkurrence
• lav autoritet
• få relevante omtaler eller backlinks
• svag informationsarkitektur
• uklart brand eller tilbud

Teknisk SEO skaber fundamentet for discovery, rendering og forståelse. Det garanterer ikke rankings.

Hvis crawl, indexering og performance er solide, bør analysen bevæge sig videre til indhold, intent og konkurrence.

Hvornår giver en professionel teknisk SEO-audit mening?

Det er især relevant ved større React-sites, migrationer, framework-skifte, mange dynamiske routes, vedvarende indexeringsproblemer, svage Core Web Vitals eller tekniske fund, der mangler prioritering.

Når behovet er gået fra selvdiagnostik til en egentlig kode- og implementeringsgennemgang, kan en teknisk SEO-gennemgang være det naturlige næste skridt.

Hvis problemet mere grundlæggende handler om arkitekturen på en ny React-side, kan det også være relevant at se på skraddersyede hjemmesider og hvordan route-specifikt HTML, metadata og performance bygges ind fra starten.

Praktisk audit-checkliste

Rendering

• [ ] Vigtigt indhold kan rendere pålideligt
• [ ] Renderingstrategi er forstået per vigtig sidetype
• [ ] Initial HTML/build-output er kontrolleret
• [ ] Ingen kritiske JavaScript-fejl blokerer indhold

Indexering

• [ ] Vigtige landingssider er indexerbare
• [ ] noindex bruges intentionelt
• [ ] URL Inspection er kontrolleret på repræsentative routes
• [ ] Page indexing-mønstre er vurderet efter ønsket indexering

Metadata

• [ ] Unik title på centrale routes
• [ ] Relevant meta description
• [ ] Korrekt canonical
• [ ] Robots meta er korrekt
• [ ] Metadata virker ved både direkte request og client navigation

Crawl

• [ ] Sitemap indeholder de ønskede canonical URLs
• [ ] robots.txt er kontrolleret
• [ ] Interne links er crawlbare
• [ ] Orphan pages er identificeret
• [ ] Statuskoder og redirects er korrekte

Content og HTML

• [ ] Klar H1
• [ ] Logisk headingstruktur
• [ ] Semantiske links og buttons
• [ ] Vigtigt indhold er tilgængeligt uden brugerinteraktion

Performance

• [ ] LCP er analyseret
• [ ] INP er analyseret
• [ ] CLS er analyseret
• [ ] JavaScript-bundle er gennemgået
• [ ] LCP-billede og billedstrategi er gennemgået
• [ ] Tredjepartsscripts er vurderet

Structured data

• [ ] JSON-LD kan parses
• [ ] Schema er relevant
• [ ] Markup matcher synligt indhold
• [ ] Route-specifik data er korrekt

Production

• [ ] Final build er valideret
• [ ] Redirects virker efter deployment
• [ ] 404 returnerer korrekt status
• [ ] Dynamiske routes er testet
• [ ] Sitemap og robots.txt er production-korrekte

FAQ

Er React dårligt for SEO?

Nej. React kan bruges til SEO-stærke websites. Problemer opstår ved implementeringer, hvor rendering, routing, metadata, links eller statuskoder ikke fungerer robust for crawleren.

Kan Google indeksere React-websites?

Ja. Google kan rendere JavaScript. Det er stadig vigtigt at teste, om det konkrete site kan hentes og renderes korrekt, og om indhold, links og metadata faktisk bliver tilgængelige.

Hvad er forskellen på CSR, SSR og SSG?

CSR bygger primært siden i browseren. SSR genererer HTML på serveren ved request. SSG genererer HTML under build. Mange moderne React-sites kombinerer strategier.

Skal React-sider prerenderes?

Ikke altid. Prerendering er ofte nyttigt for stabile, SEO-kritiske routes, men den rigtige strategi afhænger af data, opdateringsfrekvens og applikationsbehov.

Hvordan kontrollerer jeg, om Google kan se mit React-content?

Sammenlign initial HTML med rendered DOM, brug Search Console URL Inspection, og kontrollér relevante routes med et crawler-værktøj og direkte HTTP-requests.

Er client-side rendering dårligt for SEO?

Ikke automatisk. CSR øger dog afhængigheden af JavaScript og client-side data. Vigtige routes bør testes for robust rendering, metadata, links og fejltilstande.

Hvordan håndterer man metadata i React?

Metadata bør være route-specifik og stabil ved direkte request til URL'en. I SEO-kritiske setups bør title, canonical og andre centrale tags ikke kun afhænge af en sen client-side navigation.

Hvorfor kan en React-404 returnere status 200?

Fordi routeren kan vise en 404-komponent efter serveren allerede har svaret med 200. Hosting/serverlaget skal konfigureres, så ikke-eksisterende URLs returnerer en korrekt 404-status.

Er Core Web Vitals en del af teknisk SEO?

Ja, de er relevante for teknisk kvalitet og brugeroplevelse. De bør dog analyseres sammen med rendering, indexering, content og andre tekniske forhold - ikke som en isoleret SEO-score.

Kan et React-site ranke lige så godt som WordPress?

Ja. Ingen af platformene ranker automatisk bedre. Den konkrete implementering, indholdet, search intent, autoritet, crawlbarhed og brugeroplevelsen er vigtigere end teknologinavnet.

Konklusion

En teknisk SEO-audit handler ikke om at få alle auditværktøjer til at vise 100. Målet er at sikre, at de sider der skal ranke, kan crawles, renderes, forstås og bruges effektivt.

På React-sites betyder det især, at du skal kontrollere mere end den færdige browservisning. Se på HTTP-status, initial HTML, rendering, metadata, dynamiske routes, interne links, JavaScript-fejl og den faktiske production build.

Hvis et React-site har uklare indexerings-, rendering- eller performanceproblemer, kan AS Web Solutions hjælpe med en teknisk gennemgang og implementering af de relevante rettelser. Men auditten bør først afgøre, hvilke problemer der reelt påvirker de vigtige sider, så indsatsen prioriteres efter effekt frem for antal notices.