ForHosting KIT · SEO

Prüfen Sie Canonical-Konflikte und Domainrisiken

Ein Canonical-Tag kann gültig aussehen und Suchmaschinen dennoch unbemerkt von der Seite wegführen, die Sie indexieren möchten.

● BetaKostenlos · im Browser

Im Browser ausführen – kostenlos API ansehen

Nutzen Sie es über WebAPIE-MailTelegramApp bald

Diese Prüfung vergleicht die Seiten-URL mit dem Wert des Tags, meldet ihre Übereinstimmung nach sicherer Normalisierung und stuft eine andere Zieldomain als hohes Risiko ein. So prüfen Sie Template-Änderungen, Migrationen und Publikationsfehler, bevor sie Indexierungssignale schwächen.

Was ein Canonical-Konflikt bedeutet

Ein Canonical-Tag teilt Suchmaschinen mit, welche URL eine Seite vertreten soll, wenn mehrere Adressen gleiche oder sehr ähnliche Inhalte zeigen. Ein selbstreferenzielles Canonical wiederholt normalerweise die Seiten-URL und gibt Crawlern eine eindeutige bevorzugte Adresse. Ein Konflikt liegt vor, wenn die eingegebene Seiten-URL und der Canonical-Wert nach der Normalisierung unterschiedliche Zeichenfolgen ergeben. Die Abweichung kann beabsichtigt sein, etwa wenn eine Tracking-URL ihre Signale auf eine saubere Produktseite bündelt. Sie sollte dennoch geprüft werden, weil sie Indexierungssignale von der aktuellen Adresse weglenken kann. Das Ergebnis enthält beide analysierten URLs, die Vergleichsformen ohne Fragmente, Kennzeichen für Übereinstimmung und Konflikt sowie eine verständliche Meldung. Das Werkzeug ruft keine Ziele ab und beurteilt keine inhaltliche Gleichwertigkeit. Es beantwortet deterministisch, ob das Canonical die angegebene URL bezeichnet. Damit eignet es sich für Deployment-Kontrollen, Audits, redaktionelle Abläufe und automatisierte Tests.

So werden URLs validiert und verglichen

Geben Sie die absolute HTTP- oder HTTPS-Adresse der Seite und den absoluten Wert ihres Canonical-Tags ein. Beide Felder werden als URL geparst. Fehlerhafte Werte, relative Pfade, nicht unterstützte Schemas, fehlende Angaben und Adressen mit eingebetteten Zugangsdaten werden als ungültig abgelehnt. Dadurch wird weder ein HTML-Ausschnitt noch ein einzelner Host oder ein Pfad wie /produkte/artikel als vollständiges Ziel missverstanden. Beim Vergleich normalisiert der Standardparser unter anderem die Großschreibung des Hosts und ausdrücklich angegebene Standardports. Fragmente entfallen, weil sie nur eine Stelle innerhalb desselben Dokuments bezeichnen. Schema, Host, Pfad, Query und abweichende Ports bleiben relevant. Die Prüfung entfernt keine Parameter, vereinheitlicht keine www-Varianten, erzwingt kein HTTPS und setzt Varianten mit abschließendem Schrägstrich nicht gleich. Solche Änderungen könnten echte Template-Fehler verdecken. Die zurückgegebenen normalisierten Werte machen den Grund jeder Abweichung nachvollziehbar.

Warum fremde Domains ein hohes Risiko sind

Ein Canonical zu einem anderen Host kann bei syndizierten Artikeln, lizenzierten Inhalten oder einer kontrollierten Migration korrekt sein. Ebenso kann es durch eine Staging-Einstellung, eine alte Domain, ein kopiertes Template oder manipuliertes Markup entstehen. Deshalb wird jeder Hostwechsel als domainübergreifend und hohes Risiko eingestuft, auch wenn er beabsichtigt ist. Hohes Risiko bedeutet Prüfpriorität, nicht automatisch einen Fehler. Bestätigen Sie, dass die Verantwortlichen die Bündelung verstehen, das Ziel die maßgebliche Version ist und Weiterleitungen, Sitemaps, interne Links sowie hreflang dieselbe Entscheidung stützen. Abweichungen innerhalb einer Domain erhalten eine Warnung, da sie ebenfalls auf die falsche Kategorie, das falsche Produkt oder die falsche Sprache konsolidieren können. Eine Übereinstimmung hat kein Risiko. Nutzen Sie die Prüfung bei Veröffentlichungen, Migrationen, Routing- und Template-Änderungen; in CI können unerwartete Konflikte Builds stoppen und domainübergreifende Ergebnisse eine Freigabe verlangen.

Anwendungsfälle

Staging-Domain im Markup finden

Vergleichen Sie eine Produktionsseite mit ihrem Canonical und markieren Sie einen vergessenen Test- oder Vorschauhost sofort.

Templates nach Deployments testen

Prüfen Sie nach CMS- oder Routing-Änderungen repräsentative Paare auf unbeabsichtigte Pfad-, Query-, Schema- oder Hostwechsel.

Migrationssignale kontrollieren

Erkennen Sie bei einem Umzug domainübergreifende Angaben und gleichen Sie jedes hohe Risiko mit dem freigegebenen Plan ab.

Häufige Fragen

Was gilt als Übereinstimmung?

Die geparsten HTTP- oder HTTPS-URLs müssen nach Standardnormalisierung und Entfernung der Fragmente identisch sein. Pfade, Queries, Schemas und Hosts bleiben bedeutsam.

Warum gilt ein fremdes Canonical als hohes Risiko?

Es kann syndizierte oder migrierte Inhalte bündeln, Signale aber auch an Staging, eine alte Domain oder Dritte senden. Prüfen Sie jeden Fall.

Ruft die Prüfung eine URL ab?

Nein. Sie validiert und vergleicht ausschließlich deterministisch; Inhalte, Weiterleitungen, HTTP-Status, robots-Regeln und Ziel-Canonicals werden nicht untersucht.

Sind relative Canonical-Werte zulässig?

Nein. Der Wert muss eine absolute HTTP- oder HTTPS-URL sein, damit das Ziel ohne eine erfundene Basisadresse eindeutig ist.

Ist jede Abweichung ein Fehler?

Nein. Parameter, Duplikate, Syndizierung und Migrationen können ein anderes Canonical absichtlich verwenden. Die Abweichung erfordert eine Prüfung.

Was kostet die API-Prüfung?

Jeder API-Aufruf kostet $0.002. Die Browserversion führt denselben deterministischen Vergleich kostenlos lokal aus.

Für Entwickler — API-Zugang

Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.

Endpunkt

POSThttps://api.kit.forhosting.com/seo/canonical-conflict-check

Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.

Aufruf aus Ihrem Stack

curl -X POST https://api.kit.forhosting.com/seo/canonical-conflict-check \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"page_url":"https://www.example.com/products/blue-widget","canonical_url":"https://www.example.com/products/blue-widget"}'

const res = await fetch("https://api.kit.forhosting.com/seo/canonical-conflict-check", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "page_url": "https://www.example.com/products/blue-widget",
    "canonical_url": "https://www.example.com/products/blue-widget"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/seo/canonical-conflict-check",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "page_url": "https://www.example.com/products/blue-widget",
    "canonical_url": "https://www.example.com/products/blue-widget"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/seo/canonical-conflict-check", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"page_url":"https://www.example.com/products/blue-widget","canonical_url":"https://www.example.com/products/blue-widget"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"page_url":"https://www.example.com/products/blue-widget","canonical_url":"https://www.example.com/products/blue-widget"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/seo/canonical-conflict-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Beispiel-Anfrage

{
  "page_url": "https://www.example.com/products/blue-widget",
  "canonical_url": "https://www.example.com/products/blue-widget"
}

Beispiel-Antwort

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "seo.canonical_conflict_check",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Preis

pro Anfrage$0.002

Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.

Fehler

HTTP	Code	Bedeutung
`401`	`unauthorized`	Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer).
`402`	`insufficient_balance`	Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht.
`404`	`unknown_type`	Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog.
`429`	`rate_limited`	Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Vollständige KIT-Dokumentation lesen →