Beobachtungen automatisieren und mit der nächsten Korrektur verbinden

Fehlurteile der Beobachtungswerkzeuge verhindern

Der Text einer Website und externe Suchergebnisse und Antworten ändern sich zu unterschiedlichen Zeiten. Eine einzelne manuelle Prüfung kann schwer verfolgen, ob neue Inhalte nach der Veröffentlichung berücksichtigt oder später alte Inhalte wiederverwendet wurden. Regelmäßige Beobachtungen derselben URLs und Fragen machen Änderungszeitpunkte und Ergebnisse vergleichbar. Speichert die automatische Erfassung eine andere Antwort oder einen alten Bildschirm, korrigiert man womöglich die falsche Ursache. Deshalb Original und Bewertungsgegenstand gemeinsam aufbewahren.

Automatische Indexprüfungen vergleichen die eingegebene URL mit der im Ergebnis bewerteten URL. Bleibt das Ergebnis der vorherigen URL stehen oder ist die Antwort unfertig, als ungeklärt speichern. Verneinung, Warten und Unbekannt zuerst unterscheiden, damit „Indexierung nicht abgeschlossen“ nicht allein wegen der enthaltenen Wörter „Indexierung abgeschlossen“ als Erfolg zählt. Bei geänderter Sprache oder Formulierung das Original erhalten und die Bewertungsregeln prüfen.

Die Extraktion von KI-Zitaten auf die abgeschlossene Antwort zur aktuellen Frage und ihren Quellenbereich begrenzen. Vom Nutzer eingegebene URLs, frühere Gespräche in der Seitenleiste, noch entstehende Sätze und bloße Namensnennungen von Quellenlinks unterscheiden. Zitate der gesamten Website und der angestrebten Detailseite getrennt speichern.

Überschreitet die Quellenliste das Speicherlimit oder wird die Antwort abgeschnitten, den fehlenden Bereich festhalten. Ohne vollständige Prüfung nicht „keine Zitate“ feststellen. Zugriffsfehler, Anmeldepflicht, Dienstbeschränkungen, unfertige Antworten und nicht deutbare Ergebnisse jeweils mit Grund als ungeklärt führen. Fehlten in historischen Aufzeichnungen Bewertungen zu Richtigkeit oder Aktualität, dürfen neue Felder diese alten Daten nicht nachträglich als korrekt ausfüllen.

Die Google URL Inspection API liefert den Zustand der im Index gespeicherten Version. Letztes Crawldatum und gewählte kanonische URL mit der aktuellen Seite vergleichen. Die Google Indexing API meldet Änderungen und Löschungen von JobPosting-Seiten und BroadcastEvent-Seiten innerhalb von VideoObject. Gewöhnliche Informationsseiten erhalten Crawlwege über Sitemaps und interne Links. URL Inspection · Geltungsbereich der Indexing API

Anfragevolumen und Abschlussumfang geplanter Beobachtungen verwalten

Vor der Automatisierung das Anfragevolumen aus Ziel-URLs, Suchdiensten, Fragen, KI-Diensten und Wiederholungen berechnen. Bei U URLs für Indexprüfungen, E Suchmaschinen, Q KI-Fragen, A Diensten und R Wiederholungen beträgt die Grundzahl pro Runde U×E + Q×A×R. Dazu kommen Wiederholungsversuche und Anfragen während des Wartens auf Antworten.

Cache-Aktualisierungen bei Veröffentlichung von externen Such- und KI-Beobachtungen trennen. Jede Frage bei jeder Veröffentlichung erneut auszuführen kann identische Anfragen kurz hintereinander erzeugen. Ziellisten regelmäßig aktualisieren, geänderte URLs identifizieren und die nötigen Beobachtungen ausführen. Das Intervall bestimmt der Betreiber; mehr Seiten dürfen nicht automatisch häufigere Läufe auslösen.

Jobs erhalten Schlüssel für Dienst, URL, Fragenversion und Beobachtungsrunde. Belegungsfristen und Abschlussprotokolle verhindern, dass mehrere Runner dieselbe Arbeit gleichzeitig übernehmen. Anzahl, Abstand und Abbruchbedingungen für Wiederholungen festlegen. Bei einer Limitantwort den nächsten Lauf dieses Dienstes verschieben. Nach Ablauf der Wartefrist den unvollständigen Zustand und den nächsten Wiederholungszeitpunkt speichern.

Die Verwaltung zeigt registrierte Jobs, tatsächliche Versuche, reguläre Antworten, Fehler und ungeklärte Fälle sowie den letzten Abschlusszeitpunkt getrennt. Diesen Zeitpunkt erst aktualisieren, nachdem Originalantwort und Bewertung gespeichert sind. Ausführung, Originalspeicherung, Bewertung und erneutes Abrufen der Verwaltungsanzeige prüfen. Ausfälle einzelner Dienste getrennt ausweisen.

Aus Beobachtungen die nächste Korrekturstelle bestimmen

Bei nicht indexierten URLs Zugriff, robots-Regeln, kanonische URL, Duplikate und Textqualität mit den Gründen des Suchwerkzeugs abgleichen. Ist die Seite indexiert, erscheint aber nicht bei passenden Fragen, die Übereinstimmung von Frage und Text, interne Links und ausreichende Belege prüfen. Wird sie zitiert, aber falsch beantwortet, die verwirrenden Datumsangaben, Formulierungen, Schritte oder Verbindungen zu älteren Inhalten korrigieren.

Ist eine Antwort korrekt, passt aber nicht zur Frage, Zielgruppe und Bedingungen in Titel, erstem Absatz und Zwischenüberschriften klar nennen. Ist sie unvollständig, fehlende Anmeldewege, Ausnahmen, Kosten oder andere nötige Inhalte mit echten Belegen ergänzen. Den geänderten Satz mit der Fragen-ID verbinden und in der nächsten Runde unter denselben Bedingungen beobachten.

Betriebsaufzeichnungen enthalten aktuellen Messwert, Veränderung gegenüber zuvor, mögliche Ursachen, nächste Korrektur und nächsten Beobachtungszeitpunkt. Zitiert eine Antwort auf eine Sonntagsfrage Werktagszeiten, die zitierte URL speichern. Wochenendbedingungen auf der Seite ergänzen und anschließend prüfen, ob Sonntagszeiten und Schließausnahmen in die Antwort eingehen.

Enthält etwa das neue HTML die Schließbedingungen und wurde auch das Crawldatum erneuert, während die KI nur Aufzeichnungen von 2025 zitiert, Titel, Zeiträume und Links aktueller und alter Dokumente untersuchen. Zitiert sie das aktuelle Dokument und lässt eine Ausnahme weg, die Passage mit den Fragebedingungen abgleichen. Ist das Dokument bereits eindeutig, auch Antwortschwankungen prüfen. Nur eine gesunkene Zitierquote ohne Originale und zitierte URLs erlaubt diese Auswahl nicht.

Steigt bei automatischen Prüfungen die Bildgröße in Bytes plötzlich, currentSrc, Breite und Format der CMS-Route speichern und prüfen, ob sie wieder die Original-URL nutzt. Steigt nur die Zahl der Transformationen, Speicherschlüssel und Wiederverwendungswege prüfen. Kommt nach Rücknahme noch 200, öffentliche Freigabe und verbliebene CDN-Dateien vor der Größenoptimierung reparieren. Ergebnisfelder trennen, damit verschiedene Fehler nicht in einem einzigen „SEO-Fehler“ verschwinden.

RSS-Prüfungen vergleichen öffentliche Eintrags-IDs, Links und Erstveröffentlichungsdaten. Ändert eine Titelkorrektur die guid, können im Reader Duplikate entstehen. Bleibt ein zurückgezogener Eintrag erhalten, muss die Aktualisierung der öffentlichen Liste repariert werden. Videoprüfungen kontrollieren Abschnitts-URLs und Medienzugriff regelmäßig; bei Inhaltsänderungen Transkript, Zusammenfassung und Zeitmarken neu prüfen. Suchsichtbarkeit und KI-Antworten nach diesen technischen Prüfungen separat mit eigenen Daten und Fragen beobachten.

Die drei ursprünglichen Diagnoseprobleme bis zum Ende abgleichen

Die drei Ausgangsprobleme der fiktiven Bibliothek erneut prüfen. Stehen Öffnungszeiten im Antwort-HTML, zeigt das Detail-canonical auf den Artikel und enthalten alte Hinweise Gültigkeitszeitraum und Link zum aktuellen Hinweis, sind die Website-Änderungen bestätigt. Auch Zustände öffentlicher, entworfener und nicht vorhandener Dokumente mit Listen und Sitemaps abgleichen.

Danach aufzeichnen, wann das Suchwerkzeug die URL crawlte und welche kanonische URL es wählte. Der KI dieselbe Sonntagsfrage unter denselben Bedingungen erneut stellen. Nutzt sie nach technischen Korrekturen weiterhin alte Zeiten, tatsächliche Quellen-URL und Original lesen und Verknüpfungen sowie Zeitangaben alter Inhalte erneut untersuchen.

Entstehen Zitate mit falschen Antwortbedingungen, die Zuordnung zwischen Inhalt und Belegen korrigieren. Scheitert der Zugriff, Server, WAF oder Cache reparieren. Sind technische Ergebnisse normal, aber externe Crawlprotokolle noch unverändert, den erneuten Crawl beobachten. Die nächste Maßnahme nach Ursache wählen und den erwarteten veränderten Wert notieren.

Von der Originalspeicherung zur nächsten Korrektur in einem Datensatz

Den Jobschlüssel aus Fragen-ID, Fragenversion, Dienst und Ausführungsrunde bilden. Zuerst die abgeschlossene Originalantwort und Quellen sichern. Die Bewertung bleibt ein eigener Datensatz mit Verweis auf das Original. Ändern sich Kriterien, lässt sich die Bewertungsversion erhöhen, ohne das Original zu überschreiben. Wiederholungen als neue Versuche aufzeichnen und den ersten fehlgeschlagenen Versuch nicht löschen.

Aggregationseingaben brauchen Antwortstatus, sechs Urteile, Belege und Gründe je Behauptung sowie den Originalpfad. Der Bewertungscode weist abgeschlossene Zeilen mit fehlenden Feldern zurück. Die folgende Übung führt Originalspeicherung, Lesen der Bewertungsdatei, bedingungsbezogene Aggregation und Aufzeichnung der nächsten Korrektur aus.

URL-Prüfanfragen ausführen und Originale speichern

observe.mjs neben metrics.mjs und assessment-fixture.mjs speichern. node observe.mjs arbeitet mit Beispieldaten ohne externe Anfragen. Unter observations/run-… entstehen raw/index.json, Originalantworten, assessments-v1.json und report.json. Auch derselbe erneut ausgeführte Job erstellt einen neuen Ordner und überschreibt keine früheren Originale.

// Node.js 22. Standard: Fixture; --live sendet eine URL-Inspection-Anfrage. import { mkdir, mkdtemp, writeFile, readFile } from 'node:fs/promises'; import { resolve, join } from 'node:path'; import { pathToFileURL } from 'node:url'; import { grouped } from './metrics.mjs'; import { examples } from './assessment-fixture.mjs'; export async function inspectIndex({ inspectionUrl, siteUrl, token, request = fetch }) { if (!token) throw new Error('OAuth access token required'); const queriedAt = new Date().toISOString(); try { const response = await request('https://searchconsole.googleapis.com/v1/urlInspection/index:inspect', { method: 'POST', headers: { Authorization: `Bearer ${token}`, 'Content-Type': 'application/json' }, body: JSON.stringify({ inspectionUrl, siteUrl, languageCode: 'ko-KR' }), signal: AbortSignal.timeout(10000), }); const raw = await response.text(); const base = { inspectionUrl, siteUrl, queriedAt, httpStatus: response.status, raw }; if (!response.ok) return { ...base, status: 'failed', reason: 'HTTP ' + response.status, retryable: response.status === 429 || response.status >= 500, retryAfter: response.headers.get('retry-after') }; let data; try { data = JSON.parse(raw); } catch { return { ...base, status: 'unknown', reason: 'Invalid JSON' }; } const result = data.inspectionResult?.indexStatusResult; if (!result?.verdict) return { ...base, status: 'unknown', reason: 'Missing index verdict' }; return { ...base, status: 'complete', verdict: result.verdict, lastCrawlTime: result.lastCrawlTime ?? null, googleCanonical: result.googleCanonical ?? null, canonicalMatches: result.googleCanonical ? result.googleCanonical === inspectionUrl : null, coverageState: result.coverageState ?? null }; } catch (error) { return { inspectionUrl, siteUrl, queriedAt, status: 'failed', reason: error.name === 'TimeoutError' ? 'Timeout' : 'Network failure', retryable: true }; } } export async function runObservation(out, indexRecord) { await mkdir(out, { recursive: true }); const run = await mkdtemp(join(resolve(out), 'run-')); await mkdir(join(run, 'raw')); await writeFile(join(run, 'raw/index.json'), JSON.stringify(indexRecord, null, 2), { flag: 'wx' }); for (const row of examples) { await writeFile(join(run, row.rawPath), JSON.stringify({ fixture: true, question: row.question, answer: row.answer, reference: row.reference, status: row.status, failure: row.failure, model: row.model, sources: row.claims?.filter(c => c.sourceUrl).map(c => ({ url: c.sourceUrl, quote: c.quote })), }, null, 2), { flag: 'wx' }); } await writeFile(join(run, 'assessments-v1.json'), JSON.stringify(examples, null, 2), { flag: 'wx' }); // Gespeicherte Bewertungen lesen und nach Bedingungen aggregieren. const rows = JSON.parse(await readFile(join(run, 'assessments-v1.json'), 'utf8')); const report = { index: indexRecord.status, groups: grouped(rows), next: rows.filter(r => r.status === 'complete' && (r.complete === false || r.timely === false)) .map(r => ({ questionId: r.questionId, rawPath: r.rawPath, action: r.timely === false ? 'Geltungszeitraum des alten Hinweises und Link zum aktuellen Hinweis abgleichen.' : 'Schließhinweis zum ersten Sonntag mit der Auslassung in der Antwort abgleichen.' })) }; await writeFile(join(run, 'report.json'), JSON.stringify(report, null, 2), { flag: 'wx' }); return { run, report }; } if (process.argv[1] && import.meta.url === pathToFileURL(resolve(process.argv[1])).href) { const record = process.argv.includes('--live') ? await inspectIndex({ inspectionUrl: process.env.INSPECTION_URL, siteUrl: process.env.SEARCH_CONSOLE_SITE, token: process.env.SEARCH_CONSOLE_TOKEN }) : { status: 'complete', verdict: 'PASS', googleCanonical: 'https://example.com/guides/opening-hours', fixture: true, queriedAt: '2026-10-24T00:00:00Z' }; console.log(JSON.stringify(await runObservation(process.env.OBSERVATION_DIR || './observations', record), null, 2)); }

inspectIndex setzt inspectionUrl und siteUrl in den POST-Body und sendet das OAuth-Zugriffstoken im Authorization-Header. Nötig sind ein Konto mit Zugriff auf die registrierte Search-Console-Property und der Scope webmasters.readonly oder webmasters. URL-Präfix-Properties enthalten das abschließende /; Domain-Properties nutzen sc-domain:example.com. Tokens werden aus Umgebungsvariablen gelesen und nicht in Beobachtungsprotokolle geschrieben. Anfrage- und Authentifizierungsvertrag

INSPECTION_URL, SEARCH_CONSOLE_SITE und SEARCH_CONSOLE_TOKEN als Umgebungsvariablen bereitstellen. node observe.mjs --live sendet die URL-Inspection-Anfrage. KI-Bewertungseingaben kommen aus assessment-fixture.mjs. Für beobachtete Antworten diese Eingabe durch Originalantworten, Quellen und Bewertungen des jeweiligen Dienstes ersetzen.

Bei HTTP 401 oder 403 zuerst Authentifizierung und Property-Rechte korrigieren. Bei 429 und 5xx Originalfehler, retryAfter und retryable speichern und den Lauf beenden. Der Scheduler zeichnet nach Retry-After oder festgelegter Verzögerung einen neuen Versuch auf; keine sofortige Endlosschleife. Auch 200 ist unknown, wenn verdict fehlt oder JSON defekt ist. Nicht nur PASS lesen, sondern lastCrawlTime und googleCanonical mit der angefragten URL vergleichen.

Die URL-Inspection-Kontingente betragen je Property 2.000 täglich und 600 pro Minute, je Projekt 10 Millionen täglich und 15.000 pro Minute. Prüfen mehrere Runner dieselbe Property, Nutzung in gemeinsamem Speicher summieren. Der nächste erlaubte Anfragezeitpunkt in der Queue vermindert geballte Wiederholungen nach 429. Offizielle Kontingente

runObservation speichert zuerst Originale, liest dann die Bewertungsdatei erneut und aggregiert mit grouped. report.next enthält Originalpfade als Belege für ausgelassene Schließausnahmen und alte Quellen. Der nächste Bearbeiter gleicht Original und Seite ab und notiert geänderten Satz, Dokumentrevision und nächste Beobachtungsfrage. Fehlgeschlagene Anfragen und nicht beurteilbare Antworten verschwinden nicht aus der Aggregation.

Die vorgelagerte Originalspeicherung macht Urteile nachprüfbar. Selbst bei geänderten Suchwerkzeugregeln oder KI-Bewertungskriterien bleibt die damalige Antwort lesbar. Über den Originalpfad in report.next den falsch verwendeten Zeitraum oder die fehlende Bedingung finden und den geänderten Satz mit der nächsten Beobachtung verbinden. So führt Automatisierung zu tatsächlichen Inhaltskorrekturen.