Google Search Console datovelger fungerer ikke: hente data via API

#Hvorfor viser datovelgeren i Google Search Console året 1969

Feilen i datovelgeren i ytelsesrapporten i Google Search Console viser svakheten ved å stole utelukkende på webgrensesnittet. 13. oktober 2026 skrev Barry Schwartz i Search Engine Roundtable at rapporten avviser skjemaet med meldingen Date can't be after 1969-12-31 når man velger et egendefinert tidsrom, altså at datoen ikke kan være senere enn 31. desember 1969. Datovelgeren ble reparert, sluttet å virke igjen 14. oktober og fungerte på nytt etter noen timer. Så lenge feilen varer, kan analytikere ikke filtrere historiske data i nettleseren.

Google oppga ingen årsak, men selve datoen sier mye. I POSIX-standarden er Unix-tid antall sekunder siden midnatt 1. januar 1970 UTC. Hvis et datofelt i JavaScript får verdien null, en tom streng eller et objekt som ikke er klart, ender det lett på verdien 0. I tidssoner med negativ forskyvning mot UTC faller nullpunktet på 31. desember 1969, i amerikanske tidssoner mellom klokken 16:00 og 19:00. Den mest sannsynlige forklaringen er derfor et tidsstempel lik null som havnet i valideringen som øvre grense for tidsrommet.

Med den antakelsen sammenligner valideringen den valgte datoen med en grense satt til 1969. Enhver reell dato er senere, så regelen vurderer tidsrommet som ugyldig og blokkerer grafen.

For store nettsteder, nettbutikker og byråer som forvalter titalls portaler, betyr en slik feil at den løpende diagnostikken stopper opp. SEO-teamets arbeid kan ikke være avhengig av stabiliteten i én enkelt enkeltsideapplikasjon (SPA). Løsningen som gir full analytisk kontinuitet, er en direkte integrasjon med det offisielle Google Search Console API-et.

                  Arkitektur for tilgang til Search Console-data
                  
    [GSC Webgrensesnitt]              [Search Analytics API v1]
             │                                    │
    UI-feil, grense på 1000 rader        Stabilt REST-endepunkt
    Unix epoch-problem (1969)            25 000 rader per kall
    Ingen automatisk eksport             50 000 rader per dag
             │                                    │
             ▼                                    ▼
       [Nettleser]                       [Lokal DB / BigQuery]

#Hva er begrensningene i Google Search Console-grensesnittet sammenlignet med API-et

Det grafiske grensesnittet i Google Search Console er laget for et raskt overblikk over de viktigste nøkkeltallene, ikke for avansert dataarbeid. Selv når datovelgeren fungerer som den skal, legger webpanelet begrensninger som forvrenger bildet av domenets synlighet.

Den første begrensningen er en fast grense for hvor mye data som vises. Tabellen i Search Console viser maksimalt 1000 rader. For portaler med hundrevis av undersider og titusenvis av søk i den lange halen (long-tail keywords) ser brukeren bare en del av frasene som gir trafikk.

Det andre problemet er lagringstiden. Google Search Console sletter poster som er eldre enn 16 måneder. Uten en automatisert arkivering er det umulig å sammenligne resultater år mot år over flere år. Den tredje faktoren er anonymisering av sjeldne søk (anonymized queries): Google filtrerer dem bort av personvernhensyn i panelet, i API-et og i eksporten til BigQuery. API-et har derimot ikke tabellgrensen på 1000 rader, og forespørsler som kjøres separat for hver dag, returnerer opptil 50 000 rader per dag per søketype (Googles dokumentasjon).

Med API-et blir rapporteringen uavhengig av feil i Googles frontend, og utviklerne får kontroll over dataarkivet.

#Hvordan sette opp en tjenestekonto for Google Search Console API

For å få tilgang til Search Analytics API uten å logge inn via nettleseren med OAuth2 for sluttbrukere hver gang, setter man opp en tjenestekonto (Service Account) i Google Cloud Platform. En tjenestekonto er en selvstendig teknisk identitet med sitt eget kryptografiske nøkkelpar.

Første steg er å opprette et prosjekt i Google Cloud Console (console.cloud.google.com). Når prosjektet er opprettet, går du til APIs & Services, søker etter Google Search Console API og klikker på knappen som aktiverer tjenesten.

Andre steg er å opprette tjenestekontoen under IAM & Admin, i underseksjonen Service Accounts. Gi kontoen et unikt navn, for eksempel gsc-analytics-collector. Når kontoen er opprettet, åpner du fanen Keys og lager en ny privat nøkkel i JSON-format. Filen lastes ned til den lokale disken. Den inneholder nøkkel-ID-en, tjenestekontoens e-postadresse og den private RSA-nøkkelen i PEM-format.

{
  "type": "service_account",
  "project_id": "nordic-seo-pipeline",
  "private_key_id": "5c6d7e8f9a0b1c2d",
  "private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQC1...\n-----END PRIVATE KEY-----\n",
  "client_email": "gsc-analytics-collector@nordic-seo-pipeline.iam.gserviceaccount.com",
  "client_id": "108765432109876543210",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token"
}

Tredje steg er å autorisere tjenestekontoen i Google Search Console. Kopier adressen i client_email og åpne Search Console for det verifiserte domenet. Gå til Innstillinger (Settings), velg Brukere og tillatelser (Users and permissions) og legg til den nye e-postadressen med rollen Begrenset (Restricted) eller Full (Full). Fra nå av kan tjenestekontoen spørre mot Search Console-endepunktene for denne egenskapen.

JSON-filen med den private nøkkelen må aldri havne i et offentlig kodelager. Legg den i .gitignore, eller send innholdet som en kryptert miljøvariabel på produksjonsserveren.

#Hvordan sjekke hvilke Search Console-egenskaper tjenestekontoen har tilgang til

Den vanligste årsaken til feil 403 etter at tjenestekontoen er satt opp, er at adressen til egenskapen i skriptet ikke stemmer med den Search Console kjenner. I stedet for å gjette kan du spørre API-et. Metoden sites.list returnerer listen over egenskaper kontoen har tilgang til, og hver oppføring har to felt: siteUrl, skrevet nøyaktig slik de andre metodene forventer, og permissionLevel (dokumentasjon for ressursen sites).

Feltet permissionLevel har én av fire verdier: siteOwner (eier), siteFullUser (full tilgang), siteRestrictedUser (begrenset tilgang) og siteUnverifiedUser (bruker uten verifisert egenskap). Hvis egenskapen ikke står på listen, er tjenestekontoens e-postadresse ikke lagt til i innstillingene i Search Console, eller den er lagt til i en annen egenskap, for eksempel i prefikset https://www. i stedet for i domeneegenskapen.

const { data } = await searchconsole.sites.list();
for (const site of data.siteEntry || []) {
  console.log(site.siteUrl, site.permissionLevel);
}
// sc-domain:wppoland.com siteFullUser

Den samme ressursen har metodene add, delete og get. For ren datauthenting holder det med omfanget webmasters.readonly og et kall til list når skriptet starter: hvis den returnerte siteUrl avviker fra den som er konfigurert, kan skriptet avslutte med en tydelig melding før det sender hundrevis av forespørsler som feiler.

#Hvordan hente data fra sc-domain og URL-prefiks i Node.js

Når utviklere jobber med Search Console API, møter de ofte feil 403 eller 404 som skyldes feil format på nettstedets identifikator (siteUrl). Google har to ulike typer egenskaper:

1. Domeneegenskap (Domain Property): samler alle protokoller og subdomener. I API-et må identifikatoren ha prefikset sc-domain:, for eksempel sc-domain:wppoland.com.
2. URL-prefiksegenskap (URL-prefix Property): gjelder en bestemt protokoll og bane. I API-et er identifikatoren en fullstendig URL med skråstrek til slutt, for eksempel https://wppoland.com/nb/.

For flerspråklige nettsteder er det beste praksis å spørre mot prefiksegenskaper for hver språkversjon, eller mot domeneegenskapen og deretter filtrere URL-banene i koden.

Skriptet nedenfor, skrevet i Node.js, viser en komplett implementasjon som henter analysedata med paginering og lagrer dem i en JSON-fil. Det bruker det offisielle biblioteket googleapis.

import fs from "node:fs";
import path from "node:path";
import { google } from "googleapis";

async function exportSearchData() {
  const credentialsFile = path.resolve("./scripts/gsc-service-account.json");
  const creds = JSON.parse(fs.readFileSync(credentialsFile, "utf8"));

  if (creds.private_key) {
    creds.private_key = creds.private_key.replace(/\\n/g, "\n");
  }

  const auth = new google.auth.GoogleAuth({
    credentials: creds,
    scopes: ["https://www.googleapis.com/auth/webmasters.readonly"],
  });

  const client = await auth.getClient();
  const searchconsole = google.searchconsole({ version: "v1", auth: client });

  const siteUrl = "sc-domain:wppoland.com";

  // Tre dagers forsinkelse for aa sikre konsoliderte tall fra Google
  const endDate = new Date(Date.now() - 3 * 864e5).toISOString().slice(0, 10);
  const startDate = new Date(Date.now() - 33 * 864e5).toISOString().slice(0, 10);

  console.log(`Starter uthenting for ${siteUrl} fra ${startDate} til ${endDate}`);

  const allRows = [];
  let startRow = 0;
  const rowLimit = 25000;

  while (true) {
    const response = await searchconsole.searchanalytics.query({
      siteUrl,
      requestBody: {
        startDate,
        endDate,
        dimensions: ["page", "query", "device", "country"],
        rowLimit,
        startRow,
      },
    });

    const rows = response.data.rows || [];
    allRows.push(...rows);
    console.log(`Hentet pakke: ${rows.length} rader (Totalt: ${allRows.length})`);

    if (rows.length < rowLimit) {
      break;
    }

    startRow += rowLimit;
  }

  const destination = "./reports/gsc-performance-data.json";
  fs.mkdirSync(path.dirname(destination), { recursive: true });
  fs.writeFileSync(destination, JSON.stringify(allRows, null, 2), "utf8");

  console.log(`Eksport fullfoert. Lagret ${allRows.length} rader til ${destination}`);
}

exportSearchData().catch((err) => {
  console.error("Feil ved uthenting fra Search Console API:", err.message);
  process.exit(1);
});

Koden går gjennom resultatsidene én etter én ved hjelp av parameteren startRow. Når API-svaret inneholder færre rader enn den angitte grensen på 25 000, avsluttes løkken. Slik henter du hele søkehistorikken uten å miste data fra den lange halen.

#Hvordan hente data fra Google Search Console med Python

For dataingeniører og team som jobber i Pandas og Jupyter, er et Python-skript det mest praktiske verktøyet for å hente ut og rense data fra Search Console. Eksemplet nedenfor henter data fordelt per dag og lagrer dem i det optimaliserte Parquet-formatet, som tar mindre plass enn CSV og bevarer kolonnetypene.

For å kjøre skriptet trenger du bibliotekene google-api-python-client, google-auth, pandas og pyarrow:

pip install google-api-python-client google-auth pandas pyarrow

Implementasjonen av skriptet:

import datetime
import pandas as pd
from google.oauth2 import service_account
from googleapiclient.discovery import build

def fetch_search_console_records(site_url: str, days: int = 30) -> pd.DataFrame:
    key_path = "scripts/gsc-service-account.json"
    credentials = service_account.Credentials.from_service_account_file(
        key_path,
        scopes=["https://www.googleapis.com/auth/webmasters.readonly"]
    )
    
    service = build("searchconsole", "v1", credentials=credentials)
    
    end_date = (datetime.date.today() - datetime.timedelta(days=3)).strftime("%Y-%m-%d")
    start_date = (datetime.date.today() - datetime.timedelta(days=days + 3)).strftime("%Y-%m-%d")
    
    rows_list = []
    start_row = 0
    row_limit = 25000
    
    while True:
        body = {
            "startDate": start_date,
            "endDate": end_date,
            "dimensions": ["date", "page", "query", "country", "device"],
            "rowLimit": row_limit,
            "startRow": start_row
        }
        
        response = service.searchanalytics().query(
            siteUrl=site_url,
            body=body
        ).execute()
        
        rows = response.get("rows", [])
        if not rows:
            break
            
        for item in rows:
            rows_list.append({
                "date": item["keys"][0],
                "page": item["keys"][1],
                "query": item["keys"][2],
                "country": item["keys"][3],
                "device": item["keys"][4],
                "clicks": item["clicks"],
                "impressions": item["impressions"],
                "ctr": item["ctr"],
                "position": round(item["position"], 2)
            })
            
        print(f"Hentet {len(rows)} rader (startRow={start_row})")
        if len(rows) < row_limit:
            break
            
        start_row += row_limit
        
    df = pd.DataFrame(rows_list)
    return df

if __name__ == "__main__":
    property_id = "sc-domain:wppoland.com"
    data_frame = fetch_search_console_records(property_id, days=60)
    
    if not data_frame.empty:
        data_frame["date"] = pd.to_datetime(data_frame["date"])
        data_frame.to_parquet("reports/gsc_performance.parquet", index=False)
        print(f"Lagret {len(data_frame)} rader som Parquet-fil.")
    else:
        print("Ingen data funnet.")

Med lagring i kolonneformatet Parquet kan du raskt aggregere og gruppere søk etter produktkategorier eller sidemaler i WordPress uten å belaste arbeidsminnet på serveren.

#Hvordan hente ferske data og timesdata fra Search Console API

Skriptene ovenfor hopper over de tre siste dagene, fordi Google oppgir at dataene vanligvis er tilgjengelige etter 2 til 3 dager (guiden til å hente alle data). Den samme guiden anbefaler en enkel test: en forespørsel med dimensjonen date for de siste 10 dagene viser hvilken dag som er den siste tilgjengelige.

Om API-et returnerer foreløpige data, styres av parameteren dataState (dokumentasjon for metoden query):

Med dataState: "all" og gruppering etter dato inneholder svaret feltet first_incomplete_date i metadataene. Alle verdier etter denne datoen kan fortsatt endre seg tydelig, så et arkiveringsskript bør lagre dem separat eller overskrive dem ved neste kjøring. Tidspunktene i metadataene oppgis i tidssonen America/Los_Angeles, noe som har betydning når du kobler dataene med serverlogger i norsk tid.

Google la til dimensjonen hour 9. april 2025. Panelet viser timesdata bare for de siste 24 timene, mens API-et returnerer dem for opptil 10 dager (kunngjøring på Google Search Central Blog). Dermed kan du sammenligne den siste dagen med samme ukedag uken før, for eksempel etter at et innlegg er publisert eller en ny mal er rullet ut.

{
  "startDate": "2026-10-15",
  "endDate": "2026-10-15",
  "dataState": "hourly_all",
  "dimensions": ["hour"]
}

Nøklene i svaret har formen 2026-10-15T00:00:00-07:00, altså klokkeslettet i Los Angeles-tid med forskyvning. Før du lagrer dem i databasen, bør du regne dem om til UTC.

#Hvordan filtrere sider og søk i Search Analytics API

En forespørsel uten filtre returnerer all trafikk for egenskapen. På et flerspråklig nettsted trenger du vanligvis et utsnitt, for eksempel bare adresser under /nb/. Til det brukes tabellen dimensionFilterGroups. Du kan filtrere på dimensjonene country, device, page, query og searchAppearance, og de tilgjengelige operatorene er (dokumentasjon for metoden query):

• equals (standard) og notEquals: eksakt treff, for page og query med skille mellom store og små bokstaver,
• contains og notContains: treff på en del av teksten uten skille mellom store og små bokstaver,
• includingRegex og excludingRegex: regulært uttrykk i RE2-syntaks.

{
  "startDate": "2026-09-01",
  "endDate": "2026-09-30",
  "dimensions": ["page", "query"],
  "type": "web",
  "dimensionFilterGroups": [{
    "filters": [
      { "dimension": "page", "operator": "includingRegex", "expression": "^https://wppoland\\.com/nb/" },
      { "dimension": "query", "operator": "notContains", "expression": "wppoland" }
    ]
  }],
  "rowLimit": 25000
}

Det andre filteret fjerner merkevaresøk, et vanlig steg før man analyserer den lange halen. Parameteren type har erstattet den utdaterte searchType og tar verdiene web (standard, fanen Alle uten Discover og Google News), image, video, news (fanen Nyheter), discover og googleNews. Hver type må hentes med en egen forespørsel.

Parameteren aggregationType avgjør om tallene beregnes per egenskap (byProperty) eller per URL (byPage); standardverdien auto overlater valget til Google. Verdien byProperty fungerer ikke for typene discover og googleNews.

#Hvorfor stemmer ikke summen fra API-et med grafen i Search Console

Etter den første eksporten legger nesten alle team merke til at summen av klikk fra radene er lavere enn tallet på grafen i panelet. Det er ikke en feil i skriptet. Google beskriver tre årsaker (guiden til å hente alle data):

1. API-et gir tilgang til høyst 50 000 rader per dag per søketype, sortert etter klikk. På store nettsteder kommer ikke halen av søk under denne terskelen med i svaret.
2. Ved gruppering etter dimensjonene page eller query kan systemet utelate en del av dataene for at beregningene skal være gjennomførbare.
3. Visninger, klikk, posisjon og CTR beregnes annerledes ved aggregering per side enn per egenskap.

I tillegg kommer de anonymiserte søkene, som ikke finnes i noen kilde. Den praktiske konklusjonen: hent totaltallene for trafikk fra en forespørsel uten dimensjonene page og query (bare date), og behandle oppdelingen på fraser som et utvalg sortert etter klikk. Google anbefaler også å hente data dag for dag og paginere med 25 000 rader om gangen helt til siden er tom, separat for hver søketype.

#Hvordan lagre data fra Google Search Console i Google BigQuery

Løsningen som tåler størst datamengder for store nettsteder, er automatisk eksport av data fra Google Search Console til datavarehuset Google BigQuery. Google lanserte Bulk Data Export 21. februar 2023: funksjonen sender hver dag et uttrekk av ytelsesdata til et valgt BigQuery-prosjekt (kunngjøring på Google Search Central Blog).

Fordelene med denne tilnærmingen:

1. Ingen grense på 16 måneder: data som er lagret i BigQuery, blir liggende så lenge du trenger dem.
2. Eksporten er ikke underlagt den daglige radgrensen i API-et. Google filtrerer bare bort anonymiserte søk, av personvernhensyn.
3. Mulighet til å koble data fra Search Console med tabeller i WordPress-databasen (WooCommerce-ordrer, handlekurver, konverteringer).

Eksporten settes opp i to steg. I Google Cloud Console aktiverer du BigQuery API i prosjektet og gir tilgang til tjenestekontoen for Search Console. I innstillingene i Search Console oppgir du prosjekt-ID-en og plasseringen for datasettet. Bare eieren av egenskapen kan sette opp eksporten. Search Console simulerer først en eksport; lykkes simuleringen, får alle eiere en e-post, og de faste eksportene starter innen 48 timer. Ved en feil vises et varsel med en gang.

Eksporten oppretter tre tabeller:

• searchdata_site_impression: data aggregert per egenskap, med søk, land, søketype og enhet.
• searchdata_url_impression: data aggregert per URL, med detaljer om søk og resultater med utvidede elementer.
• ExportLog: en logg over hvilke data som ble lagret hvilken dag. Mislykkede eksporter registreres ikke her.

Eksempel på en SQL-spørring i BigQuery som finner undersider med mange visninger og lav klikkfrekvens (kandidater for å optimalisere metakoder og overskrifter):

SELECT
  url,
  query,
  SUM(impressions) AS total_impressions,
  SUM(clicks) AS total_clicks,
  ROUND(SAFE_DIVIDE(SUM(clicks), SUM(impressions)) * 100, 2) AS calculated_ctr,
  ROUND(SUM(sum_position) / SUM(impressions) + 1, 1) AS avg_position
FROM
  `nordic-project.searchconsole.searchdata_url_impression`
WHERE
  data_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
  AND country = 'nor'
GROUP BY
  url,
  query
HAVING
  total_impressions > 500
  AND calculated_ctr < 2.0
  AND avg_position BETWEEN 3.0 AND 10.0
ORDER BY
  total_impressions DESC
LIMIT 100;

Tabellen searchdata_url_impression har blant annet kolonnene data_date, url, query, country, search_type, impressions, clicks og sum_position, i tillegg til flagg for typer av utvidede resultater (Googles eksempel filtrerer search_type = 'WEB'). Kolonnen sum_position teller posisjonen fra null, så gjennomsnittlig posisjon beregnes som SUM(sum_position) / SUM(impressions) + 1, slik som i Googles eksempel. Spørringen plukker ut fraser fra første resultatside som gir under 2 prosent klikk. Dette er kandidater for å teste en ny tittel, H1-overskrift og beskrivelse; effekten av endringen må måles i ukene etterpå, ikke tas for gitt på forhånd.

                  Search Console til BigQuery Pipeline
                  
   [Google Search Console] ──(Bulk Export)──> [Google BigQuery]
                                                    │
                                                    ├──> [Looker Studio Dashboard]
                                                    ├──> [Overvaaking av posisjonsfall]
                                                    └──> [Sammenkobling med WooCommerce]

#Når velge Search Analytics API og når Bulk Data Export

Begge kildene gir de samme nøkkeltallene, men de løser ulike problemer. Google skriver i kunngjøringen av eksporten at den er særlig nyttig for store nettsteder med titusenvis av sider eller med trafikk fra titusenvis av søk per dag, mens små og mellomstore nettsteder har tilgang til alle sine data gjennom grensesnittet, Looker Studio-koblingen eller Search Analytics API (Google Search Central Blog).

I praksis utfyller de to tilnærmingene hverandre. Eksporten til BigQuery blir arkivet og kilden til analyser av den lange halen, mens et lett skript mot API-et med dataState: "hourly_all" følger med på de siste timene etter en publisering eller utrulling. For en liten blogg på WordPress holder det som regel med skriptet fra de forrige seksjonene, kjørt én gang i døgnet via cron.

#Hvordan koble Search Console-data til WordPress-databasen

Rådata fra Search Console får størst forretningsverdi når de kobles til den interne innholdsstrukturen i CMS-et. En vanlig eksport fra Search Console inneholder bare fullstendige URL-er som tekststrenger. Den sier ingenting om innholdstypen (innlegg, WooCommerce-produkt, landingsside), datoen for siste endring i Gutenberg-redigeringsverktøyet eller hvem som skrev teksten.

Integrasjonen går ut på å oversette URL-banen til en objekt-ID i WordPress (post_id). I WordPress brukes funksjonen url_to_postid($url) til dette, eller et direkte oppslag på slugen i tabellen wp_posts.

Kodeutdraget i PHP nedenfor viser hvordan søkedata importert fra API-et knyttes til riktig produkt eller artikkel i databasen:

<?php
/**
 * Koble Search Console-data til WordPress-innlegg
 */
declare(strict_types=1);

namespace WPPoland\Analytics;

class SearchConsoleIngestor {
    
    public function updatePostPerformance(string $url, int $clicks, int $impressions, float $position): void {
        $path = wp_parse_url($url, PHP_URL_PATH);
        if (!$path) {
            return;
        }

        $postId = url_to_postid($url);
        
        if ($postId === 0) {
            $postId = $this->resolveCategoryTerm($path);
        }

        if ($postId > 0) {
            update_post_meta($postId, '_gsc_clicks_30d', $clicks);
            update_post_meta($postId, '_gsc_impressions_30d', $impressions);
            update_post_meta($postId, '_gsc_avg_position', $position);
            update_post_meta($postId, '_gsc_synced_time', current_time('mysql', true));
        }
    }

    private function resolveCategoryTerm(string $path): int {
        global $wpdb;
        $slug = trim($path, '/');
        $parts = explode('/', $slug);
        $termSlug = end($parts);

        $termId = $wpdb->get_var($wpdb->prepare(
            "SELECT t.term_id FROM {$wpdb->terms} t 
             JOIN {$wpdb->term_taxonomy} tt ON t.term_id = tt.term_id 
             WHERE t.slug = %s LIMIT 1",
            $termSlug
        ));

        return $termId ? (int)$termId : 0;
    }
}

Med en slik kobling ser redaksjonen i WordPress-panelet nøyaktig antall visninger og posisjonen til hver underside. Hvis gjennomsnittsposisjonen til en artikkel faller fra plass 4 til 18 etter en maloppdatering eller utrulling av ny kode, kan systemet automatisk sende et varsel til en Slack-kanal eller opprette en revisjonsoppgave for utvikleren.

I arkitekturer basert på headless WordPress eller statiske nettstedsgeneratorer kan data fra Search Console API hentes ved bygging (build time) og brukes til å generere dynamiske seksjoner med de mest populære temaene og relaterte artikler.

#Hvordan sjekke indekseringsstatus for adresser fra eksporten med URL Inspection API

Et fall i klikk på et innlegg i dataene fra Search Analytics sier ikke om siden fortsatt er i indeksen. Det svaret gir URL Inspection API, som bruker den samme tjenestekontoen og de samme omfangene (webmasters eller webmasters.readonly). Forespørselen er POST https://searchconsole.googleapis.com/v1/urlInspection/index:inspect med feltene inspectionUrl (fullstendig adresse, som må tilhøre egenskapen), siteUrl (i samme format som tidligere: sc-domain: eller prefiks med skråstrek) og valgfritt languageCode (dokumentasjon for metoden inspect).

Resultatet indexStatusResult inneholder blant annet (beskrivelse av UrlInspectionResult):

I WordPress passer dette godt sammen med klassen SearchConsoleIngestor fra forrige seksjon: når posisjonen til et innlegg faller, sjekker skriptet adressen og lagrer coverageState og googleCanonical i innleggets metadata. Et avvik mellom Googles kanoniske adresse og den fra SEO-utvidelsen forklarer som regel fallet raskere enn en analyse av frasene. Grensen er imidlertid lav: 2000 forespørsler per dag og 600 per minutt per nettsted (grensene for Search Console API), så sjekk bare adresser som viser tegn til fall, ikke hele nettstedskartet. Metoden viser versjonen i Googles indeks og tester ikke adressen live. Forskjellen mellom dette verktøyet og Indexing API beskriver vi i guiden vår til GSC og Indexing API.

#Hvordan håndtere kvotegrenser og API-feil

Search Analytics API har grenser som er beskrevet i Googles dokumentasjon. Overskrides de, får du en kvotefeil, og skriptet må vente:

I tillegg gjelder en egen belastningskvote (load quota), som beregnes i vinduer på 10 minutter og per døgn. Ifølge Google er forespørsler kostbare når du grupperer eller filtrerer på side eller søk, og belastningen øker med lengden på tidsrommet. Google fraråder uttrykkelig å hente de samme dataene gang på gang, for eksempel hele forrige måned ved hver kjøring. Et arkiveringsskript bør derfor bare hente dagene som mangler.

For at skript som henter millioner av poster for store nettbutikker skal være pålitelige, bør du bygge inn tre forsvarsmekanismer:

1. Eksponentiell ventetid ved nye forsøk (Exponential Backoff): ved feilkode 429 eller 503 avbryter ikke skriptet arbeidet, men venter et økende antall sekunder (2 opphøyd i n pluss tilfeldig jitter) før forespørselen sendes på nytt.
2. Oppdeling av forespørsler per dag (Daily Date Chunking): i stedet for å hente data for et helt år i ett kall med enorm paginering, deler du jobben opp i løkker på én dag. Hvis én av forespørslene feiler på grunn av en midlertidig nettverksfeil, henter du bare den manglende dagen på nytt.
3. Mellomlagring av autorisasjonstokener: Googles klientbiblioteker fornyer OAuth2-tokenet automatisk ut fra tjenestekontoens nøkkel, men i serverløse miljøer (AWS Lambda, Cloudflare Workers) må du sørge for at tokenet ikke genereres på nytt for hver enkelt HTTP-forespørsel.

Kodeutdraget nedenfor viser en spørremekanisme som automatisk prøver mislykkede forespørsler på nytt:

async function executeWithRetry(apiCall, maxRetries = 5) {
  let attempt = 0;
  while (attempt < maxRetries) {
    try {
      return await apiCall();
    } catch (err) {
      attempt++;
      const isRateLimit = err.code === 429 || err.status === 429;
      const isServerError = err.code >= 500 && err.code < 600;

      if ((isRateLimit || isServerError) && attempt < maxRetries) {
        const delay = Math.pow(2, attempt) * 1000 + Math.random() * 500;
        console.warn(`Feil ${err.code}. Nytt forsoek om ${Math.round(delay)} ms (Forsoek ${attempt}/${maxRetries})...`);
        await new Promise((resolve) => setTimeout(resolve, delay));
      } else {
        throw err;
      }
    }
  }
}

Disse tre mekanismene gjør at arkiveringen av SEO-data fungerer uavhengig av feil i nettleserpanelet i Google Search Console.

#Hvordan styre SEO-data med Search Console API

Feil i det grafiske grensesnittet, som feilen i datovelgeren som setter kalenderen tilbake til 1969, minner om at analysedataene til et nettsted bør ligge i eierens eget system, ikke bare i et eksternt panel.

En egen pipeline basert på Search Console API gir målbare fordeler:

• Opptil 50 000 rader per dag per søketype i stedet for 1000 rader i tabellen i panelet, og med Bulk Data Export et komplett datasett uten anonymiserte søk.
• Rapportering som er uavhengig av feil i Googles frontend.
• Beskyttelse mot tap av historiske data etter 16 måneder takket være arkivering i BigQuery eller en relasjonsdatabase.
• Mulighet til å koble trafikk direkte til inntektene i WooCommerce-butikken og til endringer i koden i WordPress-malen.

Skal du innføre avansert analyse, automatisere rapporteringen eller gjennomføre en teknisk revisjon av nettstedet, er det lurt å rådføre seg med en WordPress-utvikler som kobler datapipelinen til arkitekturen i butikken din og sikrer den mot feil. For teknisk rådgivning er du velkommen til å ta kontakt med teamet vårt.