Mestre 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.

#Hva Google Search Console faktisk måler

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.

#URL Inspection som førsteklasses diagnose

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.

#Dekningsstatuser du må kunne forklare

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.

#XML-sitemaps: forespørsel, ikke garanti

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 (image:-utvidelsen) hjelper Google Images når hero og produktbilder er viktige. Eksempel:

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

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.

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.

#Google Indexing API: begrenset bruk - vær presis

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. Hvis API-et svarer med feil om uautorisert type eller kvote, stopp batchen - ikke retry i loop.

#IndexNow er ikke 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.

#Når du ikke skal spamme forespø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.

#En arbeidsflyt som holder 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.

#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.

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