Teknisk SEO-sjekkliste for SaaS-nettsteder

Teknisk SEO for SaaS: appen utenfor søk, gjengivelse for crawlere, dokumentasjon, endringslogger, canonical, strukturerte data, hastighet og KI-crawlere.

FixReports-redaksjonen8 min lesing

Teknisk SEO for et SaaS-selskap handler mest om atskillelse og gjengivelse. Atskillelse, fordi ett domene som regel rommer et markedsføringsnettsted som skal rangere, dokumentasjon som skal rangere, og en applikasjon som ikke skal være i søk i det hele tatt. Gjengivelse, fordi SaaS-nettsteder ofte er bygget som JavaScript-apper, og selv om Google gjengir JavaScript, gjør mange andre crawlere det ikke, deriblant de fleste KI-crawlere. Denne sjekklisten dekker begge deler, pluss det vanlige grunnlaget: kanoniske URL-er, sitemaps, strukturerte data, hastighet og hvordan KI-søkemotorer når sidene dine.

Kort oppsummert

  • Google gjennomsøker, gjengir og indekserer JavaScript-sider i separate faser og sier at gjengivelse på serveren eller forhåndsgjengivelse «is still a great idea» (fortsatt er en god idé), fordi ikke alle roboter kan kjøre JavaScript (Google Search Central (åpnes i en ny fane)).
  • En analyse fra desember 2024 fant at ingen av de store KI-crawlerne, deriblant GPTBot, ClaudeBot og PerplexityBot, gjengav JavaScript (Vercel (åpnes i en ny fane)).
  • Google sier at AI Overviews og AI Mode ikke har noen ekstra tekniske krav og ikke trenger noen spesiell schema.org-markup eller egne KI-tekstfiler (Google Search Central (åpnes i en ny fane)).
  • OpenAI bruker OAI-SearchBot for ChatGPT-søk og GPTBot for modelltrening; å blokkere GPTBot fjerner ikke et nettsted fra ChatGPT-søk (OpenAI (åpnes i en ny fane)).
  • Google-Extended styrer om Google kan bruke innhold til trening av Gemini, og påvirker ikke om innholdet tas med i Google-søk (Google Search Central (åpnes i en ny fane)).

Bør appen din være i søkeresultatene?

Nei. Applikasjonssider bak innlogging har ingenting å tilby folk som søker, og Googlebot logger ikke inn. Risikoen går den andre veien: offentlige URL-er fra appen, som delte lenker, tomme visninger, sider for tilbakestilling av passord og testmiljøer, kan bli indeksert og konkurrere med markedsføringssidene dine.

  • Server applikasjonen fra en egen vert, for eksempel app.example.com, og send X-Robots-Tag: noindex i hvert svar fra den.
  • Hold test- og forhåndsvisningsmiljøer utenfor søk med autentisering, som er mer pålitelig enn robots-regler.
  • Ikke stol på robots.txt for å fjerne sider fra Google: en blokkert URL kan fortsatt bli oppført hvis det lenkes til den fra andre steder, og Google kan ikke se en noindex på en side den ikke har lov til å gjennomsøke (Google Search Central (åpnes i en ny fane)).
  • Folk søker ofte etter innloggings- og registreringssider ved navn («dittprodukt innlogging»). Å holde dem indekserbare hjelper eksisterende kunder med å finne dem; de bør ikke inneholde tungt markedsføringsinnhold.

Vår robots.txt-sjekk viser hva hver crawler har lov til å hente, og sjekken av metatagger viser robots-metataggen og X-Robots-Tag-headeren på en side.

Kan søkemotorer og KI-crawlere lese markedsføringssidene dine?

Sjekk hva en crawler mottar før noe JavaScript kjører. Hvis HTML-svaret for prissiden din verken har priser eller overskrifter, bare en script-tagg, ser crawlere som ikke kjører JavaScript, en tom side.

  • Google gjengir JavaScript med en nyere Chromium, men gjengivelsen skjer i en kø etter gjennomsøkingen, og Google anbefaler gjengivelse på serveren eller forhåndsgjengivelse (Google Search Central (åpnes i en ny fane)).
  • KI-crawlere: Vercels analyse av sitt eget nettverk fant at crawlerne til OpenAI, Anthropic, Perplexity og Meta hentet JavaScript-filer, men ikke kjørte dem; Gemini, som bruker Googles infrastruktur, og Applebot gjengav sidene (Vercel (åpnes i en ny fane)).
  • Forhåndsvisninger av lenker i chatapper og sosiale nettverk leser som regel bare HTML-en fra serveren, så titler, beskrivelser og Open Graph-tagger må ligge i den.

Den praktiske løsningen er å gjengi markedsføringssider, dokumentasjon og bloggen på serveren eller ved bygging, noe rammeverk som Next.js, Nuxt og Astro støtter, og beholde gjengivelse i nettleseren for den innloggede applikasjonen. En rask test: kjør curl mot URL-en din, eller se på sidekilden i stedet for den inspiserte DOM-en, og sjekk at teksten er der.

Hvordan bør markedsføringsnettstedet være strukturert?

Kjøpere av SaaS søker med en hensikt du kan knytte til sider. Hver av disse fortjener sin egen indekserbare side med en beskrivende tittel og sin egen kanoniske URL:

  • Produkt- og funksjonssider, én per viktig funksjonalitet.
  • Sider for bruksområder og bransjer, for søk som «faktureringsprogram for byråer».
  • Integrasjonssider, én per integrasjon, fordi folk søker etter «[ditt produkt] + [verktøyet deres]».
  • Priser, med planene og prisene i HTML-en, ikke lastet fra et API etter gjengivelsen.
  • Sammenlignings- og alternativsider, skrevet rettferdig: konkurrentenes priser og funksjoner endres, så dater dem og hold dem oppdatert.
  • Kundehistorier, med tillatelse og ekte detaljer som kan knyttes til en navngitt kilde.

Unngå tynne varianter: dusinvis av nesten identiske sider av typen «[funksjon] for [bransje]» der bare ordene er byttet ut, er det Googles retningslinjer for spam kaller misbruk av innhold i stor skala (scaled content abuse) (Google Search Central (åpnes i en ny fane)).

Hvordan bør du håndtere dokumentasjon, hjelpesentre og endringslogger?

Dokumentasjon gir ofte mer søketrafikk enn markedsføringsnettstedet, fordi folk søker etter hvordan de gjør ting.

  • Gjør dokumentasjonen offentlig og indekserbar, med mindre den inneholder kundespesifikk informasjon.
  • For versjonert dokumentasjon lar du den kanoniske URL-en til eldre versjoner peke til den gjeldende versjonen av samme side, eller merker gamle versjoner med noindex, slik at søkeresultatene viser de gjeldende instruksjonene.
  • Gi hver dokumentasjonsside en beskrivende tittel og H1 som samsvarer med hvordan folk formulerer oppgaven («Eksporter fakturaer til CSV»), ikke interne funksjonsnavn.
  • Hold innleggene i endringsloggen på stabile, daterte URL-er.
  • Ta med dokumentasjonen i XML-sitemapen din, eller gi den en egen sitemap som oppgis i robots.txt.

Hvis hjelpesenteret ditt kjører på en tredjepartsplattform på et underdomene, sjekker du at det er verifisert i Search Console, og at sidene lenker tilbake til hovednettstedet.

Hvilke problemer med kanoniske URL-er, hreflang og videresendinger er vanlige på SaaS-nettsteder?

  • Parametere: UTM-tagger, henvisningskoder og parametere for A/B-tester lager dupliserte URL-er. Hver side bør oppgi sin egen rene URL som kanonisk (Google Search Central (åpnes i en ny fane)).
  • Skråstrek til slutt og store og små bokstaver: velg én form, og videresend den andre med en 301.
  • Lokaliserte sider: hvis du oversetter markedsføringsnettstedet, kobler du språkversjonene sammen med hreflang, inkludert en selvreferanse og en x-default (Google Search Central (åpnes i en ny fane)).
  • Navnebytter og domeneflyttinger: knytt gamle URL-er til nye én til én med 301-videresendinger; hvis du videresender alt til forsiden, går verdien av de gamle sidene tapt.

SEO-sjekken tester titler, H1-er, kanoniske URL-er og robots-regler på de viktigste sidene på nettstedet ditt, og finner brutte interne lenker.

Hvilke strukturerte data passer for et SaaS-nettsted?

  • Organization på forsiden, med navn, URL, logo og sameAs-lenker til offisielle profiler.
  • WebSite på forsiden med name og url, som Google bruker til å velge nettstedsnavnet som vises i resultatene (Google Search Central (åpnes i en ny fane)).
  • SoftwareApplication: Googles utvidede resultat for programvareapper krever en pris og enten en samlet vurdering eller en anmeldelse (Google Search Central (åpnes i en ny fane)). Legg bare til vurderinger som er ekte og synlige på siden; uten dem beskriver markupen fortsatt produktet, men gir ikke det utvidede resultatet.
  • BreadcrumbList på dokumentasjons- og bloggsider.
  • Article på blogginnlegg, med forfatter og datoer.

Ikke forvent at FAQ-markup gir ekstra plass: Google sluttet å vise utvidede resultater for FAQ 7. mai 2026 (Google Search Central (åpnes i en ny fane)). Sjekken av strukturerte data viser hvert element på en side og egenskapene Google krever for det.

Hvorfor består ikke markedsføringssidene til SaaS-selskaper Core Web Vitals?

Markedsføringsnettsteder for SaaS laster gjerne mange tredjepartsskript: analyse, tag managers, chat-widgeter, A/B-testing, øktopptak og annonsepiksler. De forsinker hovedinnholdet og holder hovedtråden opptatt, noe som viser seg som en treg LCP og en dårlig INP.

  • Gå gjennom hvert tredjepartsskript, og fjern dem ingen bruker.
  • Last inn chat-widgeter først ved interaksjon, og unngå skript for A/B-testing som skjuler siden til de har kjørt.
  • Server hero-bilder og produktskjermbilder i den størrelsen de vises i, i WebP eller AVIF, uten lazy loading på det første.
  • Følg med på INP på sider med interaktive priskalkulatorer og demoer.

Google bruker Core Web Vitals i rangeringssystemene sine, selv om relevans kommer først (Google Search Central (åpnes i en ny fane)). Hastighetstesten måler en side slik en strupet mobil laster den, og viser data fra ekte brukere når Google har dem.

Hvordan finner og siterer KI-søkemotorer SaaS-innhold?

Det finnes ikke noe eget teknisk spor for KI-søk, og noen populære råd støttes ikke av selskapene som driver disse systemene.

  • Google AI Overviews og AI Mode bruker sider som er indeksert og kan vises med et utdrag; Google sier at det ikke finnes noen ekstra krav, ingen spesiell schema-markup og ikke noe behov for KI-tekstfiler (Google Search Central (åpnes i en ny fane)).
  • ChatGPT-søk bygger på OAI-SearchBot. Hvis du vil vises i svarene fra ChatGPT, må du ikke blokkere OAI-SearchBot i robots.txt; å blokkere GPTBot reserverer deg bare mot trening (OpenAI (åpnes i en ny fane)).
  • Trening av Gemini styres med tokenet Google-Extended, som ikke påvirker Google-søk (Google Search Central (åpnes i en ny fane)).
  • llms.txt er et forslag fra fellesskapet om et Markdown-sammendrag av et nettsted. Google sier at slike filer ikke trengs; andre KI-tjenester har ikke dokumentert om de bruker dem. Det koster lite å publisere en slik fil, men den erstatter ikke sider som kan gjennomsøkes.

Det som hjelper på tvers av alle disse, er det samme: sider som gjengis på serveren, tydelige overskrifter som svarer på spørsmålene kjøpere stiller, konkrete fakta som priser og grenser i tekst, og sider som ikke motsier hverandre.

Ofte stilte spørsmål

Bør dokumentasjonen vår ligge på et underdomene eller i en undermappe?

Begge kan rangere. Det som betyr mer, er at dokumentasjonen kan gjennomsøkes, at det lenkes til den fra hovednettstedet, at den er med i en sitemap, og at den er verifisert i Search Console.

Indekserer Google innholdet i JavaScript-appen vår?

Google kan gjengi JavaScript, men gjør det i et eget trinn, og andre crawlere gjør det ofte ikke. For sider du vil skal bli funnet, gjengir du innholdet på serveren eller ved bygging.

Bør vi blokkere KI-crawlere?

Det er en forretningsbeslutning. Å blokkere treningscrawlere som GPTBot eller Google-Extended holder innholdet utenfor modelltrening uten å fjerne deg fra søk; å blokkere søkecrawlere som OAI-SearchBot fjerner deg fra svarene i den tjenesten. Robots.txt-sjekken viser hva de nåværende reglene dine tillater.

Trenger vi SoftwareApplication-markup?

Det er valgfritt. Markupen beskriver produktet ditt for søkemotorer; det utvidede resultatet for programvareapper krever i tillegg ekte vurderinger eller anmeldelser som vises på siden.

Hva er den vanligste tekniske SEO-feilen på SaaS-nettsteder?

To gjør mest skade: markedsføringssider som bare gjengir innholdet sitt med JavaScript, og test- eller app-URL-er som står åpne for indeksering.

Kilder

Alle veiledninger