I 2013 prøvde mange nettsteder fortsatt å rangere ved å gjenta det samme søkeordet i bunnteksten. I 2026 er det dominerende signalet et annet: tematisk autoritet. Google trenger ikke én isolert artikkel om et begrep; den trenger å forstå om domenet dekker et tema fra ende til ende, med sider som svarer på reelle intensjoner og er knyttet sammen.
Hvis du bare har en generisk tekst om WordPress-sikkerhet, er det vanskelig å konkurrere med noen som i samme klynge dokumenterer skadevare, HTTP-headere, SSL, 2FA, sikkerhetskopier og hendelseshåndtering. Programmatisk SEO hører hjemme her som et dekningsverktøy, ikke som snarvei til spam.
I nordisk praksis dukker det samme spenningsfeltet opp på WordCamp Oslo og i byråsamtaler i Stockholm og København: marked vil ha «tusenvis av landingssider», mens utviklere spør om kilde (Brønnøysundregistrene, Digdir-API-er, egne kataloger), norsk bokmål versus nynorsk i malen, og hva siden viser utover bynavnet. Uten svar på det blir skala bare raskere indekseringsstøy.
Hva er programmatisk SEO
Programmatisk SEO er ikke «auto-blogging» der en språkmodell lager tusenvis av nesten like innlegg. Det er å ta et strukturert datasett, designe en mal som viser reelle forskjeller mellom poster, og publisere sider som løser long-tail-spørsmål.
Klassiske arkitektureksempler (ikke oppdiktet trafikk):
- Zillow og lignende: sider per postnummer, bydel og boligfiltre fra markedsdata.
- TripAdvisor og reisekataloger: sider per by, overnattingstype og attributter (basseng, familie, prisintervall).
- B2B-sammenligninger: sider per verktøy × vertikal × kriterium (pris, integrasjoner, samsvar).
Det felles punktet er ikke «generer tusen URL-er». Det er å ha data som endrer svaret på brukerens spørsmål. Hvis eneste forskjell mellom to sider er ordet «Bergen» og «Trondheim» i boilerplate, gjør du ikke nyttig programmatisk SEO: du lager varianter.
Nyttig programmatisk vs tynt innhold og doorway-sider
Google publiserer klar veiledning om nyttig innhold og spam-policyer. Tynt innhold (thin) og doorway-sider er ulike mønstre, men dårlig utført programmatisk SEO faller ofte i begge.
| Kriterium | Programmatisk SEO med verdi | Risiko for thin / doorway |
|---|---|---|
| Data | Verifiserbare kilder, API-er, egne målinger | Bare synonymer og bynavn |
| Opplevelse | Tabeller, filtre, kart, beregnede score | Gjentatt tekstblokk |
| Intensjon | Svarer på en konkret spørring | Finnes for å fange keyword og omdirigere |
| Indeksering | Få nær-duplikater; GSC stabil | Mange URL «discovered, not indexed» |
Doorway-sider, i Search Centrals spam-policy, er sider laget for å rangere på lignende spørringer og føre brukeren et annet sted, uten å tjene eget innhold. En CSV med 5000 byer, samme avsnitt og en «kontakt oss»-knapp er doorway i «skala»-forkledning.
Praktisk regel: hvis du fjerner lokalitets- eller produktnavnet og siden ikke lenger sier noe nytt, skal du ikke publisere den URL-en. Forbedre datasettet eller malen først.
Tematisk autoritet: hub og spoke
Tematisk autoritet er ikke en magisk score. Det er resultatet av konsistent dekning: en hub (pilar) definerer temaet, og spokes (satellitter) går dypere på vinkler, segmenter eller datakombinasjoner.
Eksempel på skjelett:
- Hub: «Guide til CRM for klinikker og profesjonelle tjenester»
- Spoke: «CRM for tannklinikker med gjentakende fakturering»
- Spoke: «CRM for fysioterapi med nettbasert timebok»
- Spoke: «Sammenligning av CRM med API og GDPR-klar eksport»
Regler for intern lenking som veier mer enn volum:
- Huben lenker til alle relevante spokes (eller til et filtrerbart indeks).
- Hver spoke lenker tilbake til huben med beskrivende ankertekst.
- Nære spokes lenker til hverandre når sammenligningen hjelper leseren.
- Unngå «klikk her»; bruk ankre som beskriver målet.
Uten denne topologien blir tusen programmatiske sider et flatt arkiv. Med den forstår crawleren (og leseren) temaets hierarki.
Teknisk implementering i WordPress
Du trenger ikke et skreddersydd CMS. WordPress fungerer godt hvis du behandler programmatiske sider som en egen innholdstype, ikke bloggposter blandet med redaksjonelle artikler.
Vanlig stack:
- Dedikert Custom Post Type (f.eks.
destination,tool,comparison). - Advanced Custom Fields (eller native felter) for pris, attributter, sted, score.
- Rent datasett (CSV/JSON) med kolonner malen faktisk bruker.
- WP All Import (eller eget skript) som mapper kolonner → felter.
- PHP-mal (
single-{post_type}.php) med logikk, ikke barethe_field()i prosa.
<?php
declare(strict_types=1);
// Illustrerende eksempel: tittel og ingress fra strukturerte felter.
$city = (string) get_field('city');
$hotel_count = (int) get_field('hotel_count');
$avg_score = (float) get_field('avg_score');
?>
<h1>Hoteller i <?php echo esc_html($city); ?> med aggregerte data</h1>
<p>
I dette utvalget er det <?php echo esc_html((string) $hotel_count); ?> enheter
og en gjennomsnittsscore på <?php echo esc_html(number_format($avg_score, 1)); ?>.
</p>
<!-- Tabeller, kart og filtre må endre seg med posten, ikke bare H1. -->Produksjonshensyn:
- Skill programmatisk CPT fra redaksjonell blogg (menyer, sitemaps, brødsmuler).
- Valider obligatoriske felter ved import; ufullstendige poster skal ikke gå til
publish. - Generer stabile slugger fra datasettnøkler (by + attributt), ikke fra inkonsistente manuelle titler.
- Inkluder schema bare når feltene finnes (FAQ, Product, Place osv.), aldri tom JSON-LD.
Hvis import og maler er flaskehalsen, løser en WordPress-utvikler ofte CPT, ACF, ingest og template i ett løp, i stedet for at marked publiserer rå CSV.
Datasettkvalitet før malen
Malen forsterker bare det CSV-en allerede inneholder. Svake kolonner gir tusen penere, men fortsatt tynne sider.
Prioriter kolonner som endrer leserens beslutning:
- Numeriske målinger (antall, snitt, intervaller, oppdateringsdatoer).
- Boolske eller kategoriske attributter som SERP-filteret impliserer (med API, med fakturering, med norsk support).
- Kort, faktuell tekst per post (metodenotat, begrensning, kilde), ikke et kopiert markedsføringsavsnitt.
- Stabile identitetsnøkler (eksternt ID, kanonisk slug) for reimport uten duplikater.
Unngå dekorative kolonner frontend ikke bruker. Hvert ACF-felt bør dukke opp i malen eller i schema. Foreldreløse felter øker vedlikeholdskostnaden og gir falsk følelse av «datarikdom».
For nisjer i Norge og EU: dokumenter også jurisdiksjon (GDPR, lokal fakturering, språk). En side «beste verktøy X i Oslo» uten lokale signaler (betalingsmetode, support, samsvar) leses som doorway-variant av en engelsk tekst.
Indekseringskontroll og crawl-budsjett
Å skalere URL-er uten kontroll fyller Search Console med «Discovered - currently not indexed» og fortynner domenets signal. Før full import:
- Publiser en pilot (f.eks. 30–50 URL-er) og mål indeksering og søkeatferd.
- Sett noindex på ufullstendige stubber til mal og data er klare.
- Konsolider åpenbare duplikater (samme by, to slugger) i stedet for å beholde varianter.
- Bruk et sitemap bare for den programmatiske CPT-en og overvåk crawl-feil.
Search Centrals veiledning om nyttig innhold krever ikke at du dropper automatisering. Den krever at resultatet hjelper noen som gjorde den søkingen. Automatisering uten den listen blir tomt volum.
Hvordan måle uten å finne opp seire
Du trenger ikke oppdiktede prosenter. Du trenger observerbare signaler i Search Console og analytics:
- Hvor mange CPT-URL-er er indeksert vs publisert.
- Hvilke reelle spørringer treffer sidene (ikke bare keywords fra briefen).
- Tid på siden og retur til huben (tegn på at spoken gjorde jobben).
- 404/500 og soft-404 etter hver import.
Hvis piloten indekserer dårlig, stopp. Rett data og mal. Øk batchen først etter det. Skalerbarhet uten denne bremsen er den raskeste veien fra et nyttig domene til et arkiv av tomme URL-er.
Sjekkliste før skalering
Bruk listen som publiseringsgate, ikke pynt:
- Hver side svarer på en distinkt intensjon (ikke bare et søkeord).
- Minst ett unikt element per URL: tabell, score, kart, datautvalg, filter.
- Hub og spoke lenket begge veier.
- Datakilde dokumentert (API, internt datasett, dato for siste oppdatering).
- Oppdateringsprosess: når CSV endres, oppdateres sidene uten manuell omskrivning av prosa.
- Avpubliseringskriterium: URL-er uten nyttige impresjoner og uten redaksjonell verdi ut av indeksen.
- Menneskelig gjennomgang av de første tiårene av URL-er i hver batch, med liste over gjentatte malfeil.
Oppsummering
- Jag ikke bare generiske head terms der Wikipedia og bransjegiganter allerede dominerer.
- Bruk long-tail der du har data som differensierer svaret.
- Behandle programmatisk innhold som programvare: dataschema, mal, tester, deploy i batcher.
- Skill programmatisk SEO fra doorway-sider: verdi på siden, ikke bare fangst av spørring.
- Mål indeksering og reelle intensjoner før du mangfoldiggjør volumet.
Innhold i denne modellen er data pluss presentasjon. Mangler ett av to, øker volumet bare risikoen.
Trenger du hjelp med CPT, import og maler? Kontakt oss.
