SEO til AI-byggede hjemmesider: Hvad der faktisk betyder noget

En AI-bygget hjemmeside kan rangere lige så godt som enhver anden: søgemaskiner bedømmer, hvad siden indeholder, og hvor godt den tjener besøgende, ikke hvilket værktøj der skrev koden. Haken er teknisk. Mange AI-builders producerer single-page apps, der sender browseren en næsten tom HTML-fil og tegner indholdet med JavaScript, hvilket gør hver side sværere at læse og dele for crawlere. Løs det med prerendering eller server-rendering, giv hver side sin egen titel, beskrivelse og URL, tilføj et sitemap, hold siden hurtig, og gør derefter det, intet værktøj gør for dig — skriv indhold, folk søger efter.

Hvorfor single-page apps kan have svært ved søgning

En traditionel hjemmeside sender hele sidens tekst i sin HTML. En single-page app (SPA) — standardoutputtet fra mange AI-builders, typisk React med et værktøj som Vite — sender en lille HTML-skal, noget i retning af et tomt <div id="root">, plus en JavaScript-bundle. Browseren kører JavaScriptet, som så bygger siden.

Det betyder noget for søgning på tre måder:

1. Rendering er et ekstra trin. Google beskriver tre faser for JavaScript-sider: crawl HTML'en, render den i en headless Chromium-browser og indeksér det renderede resultat. Googles egen vejledning siger, at server-side rendering eller prerendering stadig er en god idé, fordi det er hurtigere for brugere og crawlere, og fordi ikke alle bots kan køre JavaScript.
2. Andre læsere af din side renderer slet ikke. Linkeksempler i chatapps og sociale netværk og mange andre crawlere læser typisk kun den første HTML. Hvis din titel og dit preview-billede sættes af JavaScript efter indlæsning, viser de skallens standardværdier — ofte den samme titel på hver side.
3. Alt deler én HTML-fil. Medmindre appen opdaterer den, har hver URL samme <title> og beskrivelse, hvilket fortæller søgemaskiner lidt om hver side.

Intet af dette betyder, at en SPA ikke kan indekseres. Det betyder, at du er afhængig af, at crawleren gør mere arbejde, og at du mister kontrollen over, hvad læsere uden rendering ser.

Vælg en renderingsmetode

Der er fire almindelige måder at få rigtig HTML til crawlere. I rækkefølge efter hvor meget de ændrer din app:

En praktisk regel: den offentlige, søgbare del af dit site bør være statisk eller prerenderet; den logget-ind-app bag den kan forblive en almindelig SPA. Søgemaskiner bør alligevel ikke indeksere dashboards.

Hvis du starter fra bunden, og SEO betyder noget, så sig det i den første prompt, så AI'en vælger en passende opsætning:

Byg et marketingsite for en fysioterapiklinik med sider for Forside, Behandlinger (én side pr. behandling), Om os, Priser og Kontakt. SEO er vigtigt: hver side skal levere sit fulde indhold og sin egen titel og meta-beskrivelse i den første HTML — brug en statisk eller prerenderet opsætning, ikke en ren klientside single-page app.

Har du allerede en Vite-SPA, så bed om prerendering af de offentlige ruter:

Behold denne React-app, som den er, men prerender de offentlige ruter (/, /pricing, /about, /blog og hver /blog/:slug) til statisk HTML under build, hver med sin egen titel, meta-beskrivelse, canonical URL og Open Graph-tags. De logget-ind-ruter under /app kan forblive klientrenderet.

Bagefter tjekker du selv resultatet: åbn en side, vælg Vis sidekilde (ikke devtools' Elements-panel, som viser den renderede side), og bekræft at teksten og titlen står i den rå HTML.

Få det grundlæggende på siden rigtigt

Disse gælder uanset renderingsmetode.

Titler og meta-beskrivelser

• Én unik <title> pr. side, med sidens hovedemne først. Omkring 50–60 tegn er en almindelig retningslinje, fordi længere titler har tendens til at blive klippet i resultaterne.
• Én unik meta-beskrivelse pr. side — en sætning, en person har lyst til at klikke på, ikke en liste med nøgleord. Google kan omskrive den, men en god en bliver ofte brugt.
• Spring meta-nøgleord over. Google siger, at tagget ingen effekt har på indeksering eller rangering.

URL'er, overskrifter og links

• Rigtige URL'er til rigtige sider. Hvert stykke indhold skal have sin egen sti (/services/sportsmassage), ikke en fane eller et modalvindue, der kun findes efter et klik. Undgå #-fragmentrouting for indhold, du vil have indekseret.
• Én h1 pr. side, derefter en fornuftig h2/h3-struktur. AI-genererede designs bruger nogle gange overskrifter til styling; bed om semantiske overskrifter.
• Crawlbare links. Brug rigtige <a href>-links til navigation. Knapper, der ændrer siden med JavaScript, er usynlige for crawlere, der følger links.
• Canonical-tags, der peger hver side mod dens foretrukne URL, så ?utm=-varianter og duplikater med efterfølgende skråstreg ikke konkurrerer.
• Beskrivende alt-tekst på meningsfulde billeder.

Forhåndsvisninger på sociale medier

Tilføj Open Graph-tags (og:title, og:description, og:image, og:url) til hver offentlig side, i den første HTML. Det er den del, SPA'er oftest får forkert, fordi link-preview-bots ikke kører JavaScript.

Sitemaps og robots.txt

Et sitemap er en XML-fil, der lister de URL'er, du vil have indekseret. Det hjælper søgemaskiner med at finde sider, især på nye sites med få indgående links. Ifølge Googles dokumentation, fra september 2026:

• Et enkelt sitemap kan rumme op til 50.000 URL'er eller 50 MB ukomprimeret; del større sites op med et sitemap-indeks.
• Google ignorerer <priority> og <changefreq>.
• Google bruger kun <lastmod>, hvis den er konsistent korrekt, så opdater den ved reelle indholdsændringer, ikke ved hver build.

En robots.txt-fil fortæller crawlere, hvilke stier de ikke skal crawle. Brug den til at holde crawlere ude af /app, /admin og API-ruter, og peg til sitemappet fra den. Husk, at robots.txt stopper crawling, ikke indeksering: for at holde en side ude af resultaterne, brug et noindex-robots-meta-tag og lad siden blive crawlet.

Indsend sitemappet i Google Search Console, når sitet ligger på sit endelige domæne. Search Console viser også, hvilke sider der er indekseret, og hvorfor andre ikke er — det mest nyttige gratis SEO-værktøj, der findes.

Struktureret data

Struktureret data er maskinlæsbar markup, der beskriver, hvad en side er: en organisation, en lokal virksomhed, et produkt, en artikel, en begivenhed. Google anbefaler JSON-LD-formatet og er tydelig på to punkter:

• Den kan gøre sider berettiget til rich results, men garanterer ikke dem.
• Den skal beskrive information, der er synlig på siden. Markér ikke anmeldelser, priser eller FAQ'er, som besøgende ikke kan se.

Fornuftige udgangspunkter: Organization eller LocalBusiness på forsiden, Product på produktsider, Article på blogindlæg, BreadcrumbList på dybe sider. Test med Googles Rich Results Test.

Tilføj JSON-LD struktureret data: LocalBusiness på forsiden med adressen, telefonnummeret og åbningstiderne, der allerede vises på siden, og Article på hvert blogindlæg. Tilføj ingen bedømmelser eller anmeldelser.

Hastighed og mobil

Google bruger signaler for sideoplevelse, herunder Core Web Vitals, og hastighed betyder noget for besøgende uanset. Googles »gode« grænseværdier, målt ved 75. percentil af sideindlæsninger, er:

De almindelige løsninger for AI-byggede sites:

• Billeder — skaler, komprimér, brug moderne formater, angiv bredde og højde (det forhindrer layoutskift), og lazy-load under folden.
• JavaScript — en stor bundle forsinker alt på en SPA. Prerendering hjælper; det gør også opdeling af kode pr. rute.
• Skrifttyper — begræns antallet af familier og vægte, og preload den, der bruges over folden.
• Tredjepartsscripts — hver chatwidget og sporingspixel koster hastighed. Behold kun dem, du bruger.

Test den live URL med PageSpeed Insights eller Lighthouse i mobiltilstand.

Indhold er stadig det meste

Teknisk SEO fjerner forhindringer; det skaber ikke efterspørgsel. Sider rangerer, fordi de besvarer en søgning bedre end alternativerne. For de fleste små sites betyder det:

• Én side pr. emne, folk søger efter. En VVS-installatør har brug for en side pr. ydelse og pr. serviceområde, ikke én »Ydelser«-side, der lister alt.
• Specifikke, originale detaljer — priser, proces, billeder af rigtigt arbejde, svar på de spørgsmål, kunder stiller i telefonen.
• Opdateret, når ting ændrer sig. Forkerte åbningstider og gamle priser mister tillid hurtigt.

AI kan udarbejde sider hurtigt, hvilket gør det fristende at udgive mange tynde, ens sider. Googles vejledning sigter mod indhold, der primært er lavet for at rangere frem for at hjælpe folk, uanset hvordan det er produceret. Brug AI til at udkaste, og tilføj det, kun du ved. Kataloglignende sites rammes hårdest af dette; se sådan bygger du en kataloghjemmeside for, hvordan du gør listesider værd at indeksere.

Lanceringstjekliste

• Offentlige sider leverer fuldt indhold i den første HTML (tjek med Vis sidekilde)
• Unik titel, meta-beskrivelse og canonical URL på hver side
• Open Graph-tags og et delingsbillede på hver offentlig side
• Én h1 pr. side, rigtige <a href>-links, alt-tekst på billeder
• sitemap.xml med rigtige URL'er; robots.txt, der blokerer app- og API-stier
• Struktureret data kun for synligt indhold, testet
• LCP, INP og CLS i det »gode« område på mobil
• Sitet ligger på sit endelige domæne med HTTPS og er indsendt til Search Console

At flytte til dit eget domæne, før du begynder at opbygge søgetrafik, undgår senere omdirigeringer — se sådan forbinder du et eget domæne. Til den bredere byggeproces, læs sådan bygger du en hjemmeside med AI, og til sider, der skal konvertere besøgende, sådan bygger du en landingsside, der konverterer.

SEO på Mythex

Mythex har ikke et særskilt SEO-panel; du forbedrer SEO ved at ændre appen via chat eller kode. Nye webapps bruger som standard en Vite- og React-single-page app, så når søgning betyder noget, så bed fra start om en statisk eller prerenderet site, eller om Next.js. Dokumentationen har en startprompt til titler, Open Graph-tags, sitemap og robots.txt i SEO for din app, og statiske hjemmesider dækker indholdsfokuserede sites. Efter ændringer publicerer du igen, så det live site får dem med. Egne domæner er tilgængelige på Pro.

Spørgsmål