Google Search Console og Indexing API i 2026

I 2012 fylte du ut et skjema for å «legge til URL» i Google. I 2026 er jobben mer nøktern: du må forstå hvordan Google oppdager, crawler og velger å indeksere, og du må bruke de riktige verktøyene uten å blande sammen API-er som gjør ulike ting.

Denne guiden er skrevet for utviklere og tekniske SEO-ansvarlige som drifter WordPress eller andre stacker. Målet er ikke magiske snarveier. Målet er en arbeidsflyt der Google Search Console (GSC), sitemaps og - der det faktisk er tillatt - Indexing API brukes korrekt, og der IndexNow ikke blandes inn som om Google støttet den.

#Slik setter du opp Google Search Console for WordPress

Før du tar i bruk avansert verktøy, setter du opp Search Console-eiendommen slik Google forventer. Google tilbyr to typer eiendommer: Domene og URL-prefiks.

Domene-eiendommer dekker alle underdomener og protokoller (http, https, www, uten www) i én eiendom. Dette er anbefalt for de fleste nettsteder. Det krever DNS-verifisering, altså en TXT-post i domenets DNS-oppsett. For WordPress på administrert hosting tar dette vanligvis under fem minutter i hostingpanelet.

URL-prefiks-eiendommer er nyttige når du vil følge en bestemt underkatalog (som example.com/blog/) eller mangler DNS-tilgang. Du kan verifisere med opplasting av HTML-fil, metatagg, Google Analytics eller Google Tag Manager.

Etter verifiseringen:

• Koble til GA4: Under Innstillinger i GSC knytter du til Google Analytics 4-eiendommen din. Da ser du GSC-data direkte i GA4-rapporter og får en rikere attribusjonsanalyse.
• Sett brukertillatelser: Legg til teammedlemmer med riktig tilgangsnivå. Brukere med full tilgang ser alle data og kan utføre handlinger, brukere med begrenset tilgang kan bare se data. I byråoppsett bør du delegere eierrollen med forsiktighet, siden den gir mulighet til å fjerne andre brukere.
• Send inn hoved-sitemapen: Gå til Sitemaps og send inn URL-en til XML-sitemapen. For WordPress med Yoast eller Rank Math er det vanligvis https://dittdomene.no/sitemap_index.xml.
• Kontroller internasjonal målretting: Driver du et flerspråklig nettsted, sjekker du hreflang med en crawler og tar stikkprøver i URL-inspeksjon. Google avviklet rapporten for internasjonal målretting i 2022, så Search Console viser ikke lenger hreflang-feil.

#Slik leser du sideindekseringsrapporten i GSC

GSC er ikke en indekseringsknapp. Det er et observasjons- og diagnosevindu mot hvordan Google ser eiendommen din. Når du åpner rapporten for sideindeksering (Page indexing, tidligere «Coverage»), får du grupper av URL-er etter status: indeksert, ekskludert, feil, eller «funnet/crawlet men ikke indeksert».

Les rapporten som et signal om prioritering, ikke som en kø du kan hoppe i med brute force. En stor andel «Discovered - currently not indexed» betyr at Google kjenner til URL-ene (ofte via sitemap eller lenker), men har ikke brukt crawl-budsjett på dem ennå - eller har valgt å vente. «Crawled - currently not indexed» betyr at crawlen skjedde, men indeksen tok ikke siden. Det siste er nesten aldri løst ved å sende flere API-kall.

Praktisk sjekkliste før du rører kode:

1. Er URL-en kanonisk, HTTP 200, og uten utilsiktet noindex?
2. Finnes den i sitemap, og matcher sitemap-URL den kanoniske?
3. Har siden unik verdi (ikke en nesten-kopi av en annen landing)?
4. Peker interne lenker hit fra sider Google allerede stoler på?

Hvis svaret er nei på ett eller flere punkter, fikser du det først. GSC vil da vise bedring over dager og uker, ikke minutter.

#Slik bruker du URL-inspeksjon i Search Console

URL Inspection er det mest undervurderte verktøyet for utviklere. Du limer inn én URL og får et øyeblikksbilde: er den i indeksen, hvilken kanonisk URL Google valgte, siste crawl, om robots tillater tilgang, og om strukturerte data ble oppdaget.

Bruk den slik i en release-arbeidsflyt:

• Etter deploy av en viktig landing: kjør Inspection på den kanoniske URL-en, ikke på en staging-host eller en parameter-URL.
• Når GSC viser «not indexed»: Inspection forteller om problemet er crawl (robots, 404, soft) eller valg (kvalitet, kanonisk konflikt).
• Når du har sendt en sitemap eller en Indexing API-varsling: Inspection er stedet du bekrefter at Google faktisk har sett URL-en igjen - ikke dashboard-antagelser.

«Be om indeksering» i Inspection er en manuell forespørsel med kvote. Den er nyttig for noen få kritiske URL-er etter en ekte fix. Den er ikke en batch-jobb for hele nettstedet. Hvis du ber om indeksering av hundrevis av tynne sider, lærer du bare at Google fortsatt prioriterer etter kvalitet.

For WordPress: sjekk at kanonisk tag, hreflang og eventuelle CDN-URL-er peker på samme host som er verifisert i GSC. En vanlig feil i flerspråklige oppsett er at Inspection viser en annen kanonisk enn den du trodde du publiserte.

#Indekseringsstatuser i Search Console forklart

Nedenfor er statuser utviklere oftest misforstår, med en konkret respons - ikke en panikkrespons.

Discovered - currently not indexed. Google har URL-en i køen. Sjekk sitemap-helse, intern lenking og om siden er verdt crawl. Ikke spam.

Crawled - currently not indexed. Google har hentet siden og valgt å ikke indeksere. Se på innholdsdypde, duplikater, soft-404, og om malen lekker tynt innhold på tvers av URL-er.

Excluded by ‘noindex’ tag. Finn kilden: Yoast/Rank Math, tema, eller hardkodet meta. Verifiser i rendered HTML, ikke bare i admin.

Blocked by robots.txt. Enten med vilje, eller en for aggressiv Disallow som traff /wp-content/ eller et språksegment. Test med GSC robots-tester.

Soft 404. Siden returnerer 200, men innholdet ser tomt ut for Google. Typisk for tomme arkivsider, filtrerte butikkvisninger eller JavaScript-tunge skall uten SSR.

Duplicate without user-selected canonical / Google chose different canonical. To URL-er konkurrerer. Fiks kanonikk, parametre og intern lenking til én vinner.

Når du skriver intern dokumentasjon for teamet, koble hver status til én eier: utvikler (teknisk), innhold (kvalitet), eller SEO (kanonikk og intern lenking). Uten eierskap blir GSC en ubehagelig dashboard-ritual hver mandag.

#Krav til XML-sitemap i WordPress

En sitemap forteller Google hvilke URL-er du anser som viktige. Den garanterer verken crawl eller indeks. Likevel er en ren sitemap fortsatt det mest stabile signalet for store WordPress-nettsteder.

Krav som faktisk betyr noe i produksjon:

• Kun kanoniske, indeksbare URL-er (HTTP 200, ikke noindex, ikke login-beskyttet).
• Hold filene under størrelses- og URL-grensene Google dokumenterer; bruk sitemap-indeks når du splitter.
• Oppdater lastmod når innholdet faktisk endres - ikke ved hver cron-tick.
• Registrer sitemap-URL i GSC og overvåk «Discovered pages» vs feil.

Bildesitemaps har en egen seksjon nedenfor.

For flerspråklige WordPress-installasjoner: la hver språkvariant ha sin kanoniske URL i sitemap, og sørg for at hreflang og sitemap ikke motsier hverandre. En sitemap som lister både /nb/... og en fallback uten språkprefiks for samme artikkel, skaper støy.

Ikke bruk det gamle ping-endepunktet. Google kunngjorde avviklingen 26. juni 2023, det sluttet å virke seks måneder senere og svarer med 404. Samme innlegg sier at Google bare bruker lastmod til å planlegge gjennomsøking når verdien konsekvent stemmer med virkeligheten. Overvåker du sitemaps via Search Console API, ikke tell indekserte URL-er fra contents[].indexed: dokumentasjonen for sitemaps-ressursen merker feltet som utgått. Se på lastDownloaded, errors og warnings.

Yoast og Rank Math genererer sitemaps automatisk. Som utvikler bør du fortsatt validere output etter store strukturelle endringer (nye CPT-er, city-pages, headless-ruter). Automatikk uten QA er en vanlig kilde til tusenvis av lavkvalitets-URL-er i GSC.

#Slik bygger du et bildesitemap for AVIF og WebP

Yoast og Rank Math legger til bildeoppføringer automatisk, men en egen eller headless stack må gjøre det selv. En vanlig <img> i server-rendret HTML blir funnet uten bildesitemap.

Bildesitemaps (image:-utvidelsen) hjelper Google Images når hero og produktbilder er viktige. Googles dokumentasjon beskriver taggene som en måte å fortelle Google om bilder den ellers kanskje ikke finner, for eksempel bilder lastet med JavaScript. Hver <url> kan ha opptil 1000 <image:image>, og <image:caption>, <image:title>, <image:geo_location> og <image:license> er fjernet fra dokumentasjonen. Eksempel:

<url>
  <loc>https://example.com/nb/artikkel/</loc>
  <image:image>
    <image:loc>https://example.com/images/hero.avif</image:loc>
  </image:image>
</url>

Generatorer som fortsatt skriver de fjernede taggene, sløser bytes. Bilder på et CDN-domene er greit så lenge det domenet også er verifisert i Search Console og robots.txt ikke blokkerer det.

#Når kan du bruke Google Indexing API

Google Indexing API er ikke en generell «indekser hele nettstedet nå»-tjeneste. Ifølge Google Search Central er API-et ment for URL-er som representerer JobPosting (stillingsannonser) eller BroadcastEvent (livestream-videoer) i strukturerte data.

Det betyr:

• Hvis du driver en jobbportal eller publiserer livestream-arrangementer med korrekt schema, kan API-et varsle Google raskt om URL_UPDATED og URL_DELETED.
• Hvis du driver en vanlig bedriftsside, blogg eller WooCommerce-butikk uten disse typene, er Indexing API utenfor det dokumenterte bruksområdet. Stol på sitemaps, intern lenking, kvalitet og eventuell manuell Inspection for få kritiske sider.
• Rykter om at «det fungerer for alt innhold likevel» er ikke en strategi du bør bygge infrastruktur rundt. Policy og kvoter kan endre seg; dokumentasjonen er kontrakten.

Når bruken er legitim, ser arbeidsflyten slik ut:

1. Opprett en service account i Google Cloud.
2. Last ned JSON-nøkkelen og lagre den utenfor webroot.
3. Legg service account-e-posten til som eier i GSC-eiendommen.
4. Bruk det offisielle klientbiblioteket (for PHP: googleapis/google-api-php-client).
5. Send URL_UPDATED når stillingen eller livestream-siden publiseres/endres, og URL_DELETED når den fjernes.

// Kun for URL-er som kvalifiserer (JobPosting / BroadcastEvent).
$client = new Google_Client();
$client->setAuthConfig('/secure/service_account.json');
$client->addScope(Google_Service_Indexing::INDEXING);

$service = new Google_Service_Indexing($client);
$notification = new Google_Service_Indexing_UrlNotification();
$notification->setUrl('https://example.com/nb/stilling/123/');
$notification->setType('URL_UPDATED');

$service->urlNotifications->publish($notification);

Koble gjerne publisering til transition_post_status i WordPress for stillings-CPT-er, ikke til hver blogpost-save. Logg respons og feilkoder. Kvotesiden setter standardverdiene per Google Cloud-prosjekt: 200 publiseringsforespørsler per dag (URL_UPDATED og URL_DELETED samlet), 180 getMetadata-forespørsler og 380 forespørsler totalt per minutt. Fram til 16. oktober 2026 beskrev Google 200 som en startverdi for testing, og produksjon krevde godkjenning via et skjema. Den dagen forsvant både beskrivelsen og skjemaet fra dokumentasjonen; kvotesiden viser nå bare standardverdiene og viser til API-konsollen. Hvis API-et svarer med feil om uautorisert type eller kvote, stopp batchen - ikke retry i loop.

#IndexNow eller Google Indexing API

IndexNow er en åpen protokoll støttet av Bing, Yandex og flere. Du hoster en nøkkel og poster URL-er når innhold endres. Det er nyttig hvis Bing-trafikk betyr noe for markedet ditt.

Google har ikke adoptert IndexNow som erstatning for crawl. Å sende IndexNow-ping «fordi vi også vil nå Google» er en kategori-feil. Du kan kjøre IndexNow for Bing og samtidig holde Google-siden av huset (sitemap + GSC + legitim Indexing API der det gjelder). De er parallelle spor, ikke synonymer.

I praksis for et norsk WordPress-team:

• Google: sitemap i GSC, Inspection for kritiske URL-er, Indexing API kun for JobPosting/BroadcastEvent.
• Bing: IndexNow eller Bing Webmaster Tools sitemap.
• Ikke bygg én «notifyAllSearchEngines()» som later som om protokollene er like.

Når noen i teamet sier «vi må IndexNow-e for Google», rett dem til Search Central-dokumentasjonen og denne skillet-listen. Det sparer timer med feilaktig instrumentering.

#Vanlige feil ved indekseringsforespørsler

Spam i denne konteksten er ikke bare ondsinnet SEO. Det er også godt ment automatisering som overbelaster signalene.

Ikke gjør dette:

• Batch-sende Indexing API for hele bloggen «for å være sikker».
• Kalle «be om indeksering» i Inspection i loop via skript (det bryter både kvote og intensjon).
• Oppdatere lastmod i sitemap hvert minutt uten innholdsending.
• Pushe URL-er som er noindex, soft-404 eller duplikater.
• Retry-aggressivt ved 429/403 uten backoff og uten å lese feilmeldingen.
• Behandle IndexNow-suksesskoder som bevis på Google-indeks.

Gjør dette i stedet:

• Fiks rotårsaken (kanonikk, innhold, lenking, ytelse, robots).
• Begrens push-varsler til endrede, kvalifiserte URL-er.
• Mål effekt i GSC over tid: andel indeksert, crawl-statistikk, Inspection på et utvalg.
• Hold en allowlist for API-bruk (f.eks. job_listing-post type) i kode, ikke en global hook.

Et sunt mønster i CI/CD: etter deploy, valider at kritiske landinger svarer 200 og at JSON-LD for stillinger/livestream er gyldig. Indekserings-API-et kalles kun fra den valideringen når posttypen matcher. Resten overlates til sitemap og organisk crawl.

#Hvor lang tid crawling, indeksering og visning faktisk tar

Før du feilsøker en side som “ikke er indeksert ennå”, sjekk klokka. Gary Illyes viste Googles interne tidslinjer på Search Central Live i Barcelona, og Search Engine Roundtable publiserte tabellen 5. oktober 2026. Hver rad har en typisk og en tregeste tid:

Prosessene henger sammen: en side kan ikke indekseres før den er crawlet, så forsinkelser legger seg oppå hverandre. Gary sa selv:

“husk at dette var en øvelse for å se om publikum kjenner seg igjen i tallene vi hentet ut internt og la inn i de lysbildene.”

Gary Illyes, Google, Search Engine Roundtable, egen oversettelse

Tallene er størrelsesordener, ikke en avtale.

Én grense til hører hjemme ved siden av tabellen. Grensesiden for Search Console API gir URL Inspection API 2000 forespørsler per dag og 600 per minutt per nettsted, så 6000 URL-er på ett nettsted tar tre dager å inspisere én gang.

#Eksempler på indekseringsforsinkelser i Search Console

• Utdatert sitemap-henting skjulte 2034 URL-er. GSC hentet de seks lokasjons-sitemapene våre sist 1. september kl. 10:08, da de hadde 2037 URL-er. Korpuset vokste til 4071, og Google hentet ikke på nytt på fem dager, selv om blogg-sitemapene ble lest daglig. Ny innsending via API 6. september ble hentet samme dag. Sider med visninger gikk fra 223 til 343, visninger fra 1570 til 4382, men det ble 2 klikk på 7 dager.
• En dom i GSC er et øyeblikksbilde. 17. september hadde 3609 av 6747 sitemap-URL-er (53,5%) null visninger på 90 dager. Av 19 inspiserte URL-er sto 6 som “Excluded by noindex” mens live-siden leverte index, follow. 27. september sto 3 av 20 igjen, siste crawl mellom 7. mai og 20. august.
• IndexNow med gjettede URL-er. Skriptet vårt bygde 2328 URL-er fra filnavn. Ingen sto i sitemapen, alle svarte 301.

Sammenlign datoen på dommen med datoen for siste endring før du kaller en side svak.

#Indekseringsrutine for WordPress i produksjon

Sett opp tre lag.

Lag 1 - kontinuerlig. Ren sitemap, korrekt robots.txt, stabile kanoniske URL-er, intern lenking fra hub-sider. Dette dekker 90 % av et vanlig WordPress-nettsted.

Lag 2 - diagnose. Ukentlig gjennomgang av Page indexing i GSC. Stikkprøver med URL Inspection på nye landinger og på URL-er som mistet synlighet. Spor endringer i et kort notat (dato, URL, status før/etter).

Lag 3 - push (kun når det gjelder). Indexing API for JobPosting/BroadcastEvent. Manuell Inspection-forespørsel for noen få forretningskritiske sider etter en dokumentert fix. IndexNow for Bing hvis dere bryr dere om den kanalen.

Robots.txt fortjener en kort merknad: den styrer crawl-tilgang, ikke indeks direkte (selv om blokkering ofte fører til at sider ikke indekseres fordi de ikke crawles). Blokker det som ikke skal crawles. Ikke bruk robots.txt som erstatning for noindex på sider som må forbli tilgjengelige for brukere men ute av søk - da er meta robots riktig verktøy.

User-agent: Googlebot
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

AI-crawler-regler er et separat produktvalg. De sparer båndbredde, men løser ikke indekseringsproblemer i Google Søk. Bland ikke de to målene i samme commit-melding uten å vite hva du endret.

#Slik automatiserer du Google-indeksering i en CI/CD-pipeline

For statiske nettsteder bygget med Astro, Next.js eller lignende rammeverk (som stacken til wppoland.com) sørger indeksering i bygge-pipelinen for at hver deploy sender riktige varsler.

#Eksempel på post-build-hook

Lag et skript som kjøres etter bygget, leser den genererte sitemapen, finner nye eller endrede URL-er og sender dem til IndexNow. Bare URL-er for stillingsannonser og livestreamer går til Google Indexing API:

const { readFileSync } = require('fs');
const { XMLParser } = require('fast-xml-parser');

async function postBuildIndex(sitemapPath) {
  const xml = readFileSync(sitemapPath, 'utf-8');
  const parser = new XMLParser();
  const sitemap = parser.parse(xml);

  const urls = sitemap.urlset.url
    .filter(entry => {
      const lastmod = new Date(entry.lastmod);
      const oneDayAgo = new Date(Date.now() - 86400000);
      return lastmod > oneDayAgo;
    })
    .map(entry => entry.loc);

  console.log(`Found ${urls.length} recently modified URLs`);
  // submitIndexNow og submitBatch er egne funksjoner som sender forespørsler til IndexNow og Indexing API
  await submitIndexNow(urls, process.env.INDEXNOW_KEY, 'wppoland.com');  // IndexNow
  const jobUrls = urls.filter(u => u.includes('/jobs/'));  // only JobPosting pages
  await submitBatch(jobUrls);  // Google Indexing API
}

#CI/CD-integrasjon

I GitHub Actions- eller GitLab CI-pipelinen legger du til et steg etter deploy-jobben:

- name: Notify search engines
  env:
    GOOGLE_INDEXING_CREDENTIALS: ${{ secrets.GOOGLE_INDEXING_CREDENTIALS }}
    INDEXNOW_KEY: ${{ secrets.INDEXNOW_KEY }}
  run: node scripts/post-build-index.js

#Slik styrer du kvoten

Med standardkvoten på 200 publiseringsforespørsler per dag for hele Cloud-prosjektet må en jobbportal prioritere:

• Nye annonser først: En annonse Google aldri har sett, får høyest prioritet.
• Utløpte annonser deretter: Send URL_DELETED når en stilling er besatt, så den forsvinner fra resultatene i stedet for å sende søkere til en død side.
• Hopp over uendret innhold: Sammenlign lastmod-datoer eller innholdshasher, så du ikke bruker kvote på sider som ikke er endret.
• Overskudd til neste dag: Har en deploy flere URL-er enn kvoten, lagrer du resten og behandler dem dagen etter med en planlagt jobb.

#Slik ser du flere land samlet i resultatrapporten i Search Console

Fra oktober 2026 tar filteret Land i resultatrapporten imot flere land samtidig. Google kunngjorde det på LinkedIn, og Barry Schwartz omtalte det 6. oktober:

«Hvis du driver virksomhet i flere land, kan du nå se den samlede trafikken deres fra Google Søk.»

Google på LinkedIn, sitert av Barry Schwartz i Search Engine Roundtable, 6. oktober 2026, egen oversettelse

En norsk nettbutikk som også leverer til Sverige og Danmark krysser av alle tre og får klikk og visninger i én linje, uten å legge sammen tre eksporter i et regneark. Sjekk deretter Sverige alene mot totalen. Løfter det knapt linjen, betaler en egen svensk versjon seg ikke ennå.

#Oppsummering for utviklere

• GSC forteller deg hva Google valgte å gjøre; den tvinger ikke Google til å elske tynt innhold.
• URL Inspection er din enhets-test for én URL: crawl, kanonikk, indeksstatus.
• Sitemaps er nødvendige forespørsler - hold dem rene.
• Indexing API er smalt: JobPosting og BroadcastEvent, dokumentert av Google Search Central.
• IndexNow er Bing-sporet; Google er et annet spor.
• Spam av forespørsler skjuler rotårsaker og kan koste kvote og tillit.

Hvis du bygger videre på denne stacken, se også vår SEO- og GEO-optimalisering for hvordan indekserbare sider bør være strukturert for både klassisk søk og AI-svarflater.

Er noen i teamet nye i Search Console, publiserte Google Search Central 6. oktober 2026 to kuraterte spillelister på YouTube, presentert av Daniel Waisberg. Search fundamentals for beginners (grunnleggende for nybegynnere) går gjennom crawling, indeksering, visning og resultatrapporten. Technical SEO fundamentals (teknisk SEO) dekker robots.txt, crawl-budsjett, URL-inspeksjon og bulk-dataeksport og API-er i Search Console.

Kilder brukt i denne guiden: Indexing API quickstart, Sitemaps overview, URL Inspection, Page indexing report.