„Crawle diese Domain“ ist für einen Agenten zu offen. Hinter dem Satz stecken Netzwerkzugriffe, mögliche Kosten, Speicherbedarf und ein erhebliches Missbrauchsrisiko. Ein guter MCP-Vertrag bietet deshalb keinen beliebigen URL-Fetcher, sondern klar begrenzte Auditaufträge.
Mit der kleinsten nützlichen Prüfung beginnen
Für viele Fragen reicht eine einzelne URL oder eine serverseitig ausgewählte Stichprobe. Erst wenn diese Prüfung nicht genügt, wird ein größerer Crawl geplant.
Ein URL-Audit kann Status, Canonical, Robots-Signale, ausgewählte Metadaten und interne Linkbeziehungen prüfen. Das Ergebnis nennt die konkrete URL, den Zeitpunkt, den verwendeten User-Agent und alle nicht erreichbaren Prüfschritte.
Der Crawl-Scope wird serverseitig fixiert
Ein produktiver Crawlvertrag braucht mindestens:
- verifizierte Start-Property,
- erlaubte Hosts und Protokolle,
- maximale URL-Zahl und Tiefe,
- Regeln für Parameter, Redirects und Subdomains,
- Timeout, Parallelität und Abbruchgrenze,
- Umgang mit robots.txt und Auth-Bereichen,
- Speicher- und Aufbewahrungsregel.
DNS-Auflösung und Redirects müssen gegen interne, lokale oder andere gesperrte Ziele geprüft werden. Sonst wird ein öffentlicher Validator zur SSRF-Oberfläche.
Ein Crawl ist meist eine lange Operation
Der Server sollte einen Task-Handle mit klarer Zuordnung zurückgeben. Statusangaben müssen mehr leisten als „läuft“ oder „fertig“. Sinnvoll sind geplante und verarbeitete URLs, Fehlerzahl, aktueller Abbruchgrund und Budgetverbrauch.
Ein Abbruch ist ein regulärer Pfad. Nutzer müssen einen laufenden Auftrag stoppen können; das Ergebnis kennzeichnet anschließend, dass es unvollständig ist.
Befunde brauchen URL-Evidenz
Eine aggregierte Zahl wie „42 Canonical-Probleme“ reicht nicht. Jeder Befund sollte auf betroffene URLs und die beobachteten Felder zurückführen. Bei internen Links gehören Quell-URL, Ziel-URL, Anchor und Fundstelle in die Evidenz.
So kann ein Agent eine Priorität begründen, ohne dass die Rohbelege verschwinden.
Keine automatische Reparatur aus dem Audit
Audit und Änderung werden getrennt. Ein Crawl darf Vorschläge vorbereiten, aber keine Canonicals, Redirects oder Inhalte selbst veröffentlichen. Für eine spätere Schreiboperation braucht es einen konkreten Diff, eine neue Berechtigung und eine menschliche Freigabe.
Contextter besitzt einen öffentlichen Site-Audit-Produktbezug und wird gemeinsam mit dieser Site betrieben. Ein öffentlicher Contextter-MCP-Zugang ist damit nicht belegt.
Quellenregister
Primärquellen für diesen Stand
- Model Context Protocol: The 2026-07-28 SpecificationBeobachtet 22.8.2026 · Stateless core, discovery, routing headers, cache metadata, authorization, tasks and deprecations.
- Contextter: Contextter product surfaceBeobachtet 22.8.2026 · Current public Keyword Database, Site Audit, Action Center, workspace and cost model. No public MCP claim observed.