Den richtigen Domain-Kontext, Profilquellen und Analyselauf wählen

Behandle den Domain-Kontext als genaue Evidenzadresse

Ein Domain-Overview-Kontext ist mehr als ein eingetippter Domainname. Er besteht aus autorisiertem Workspace, normalisierter Domain, Länder-Code und Sprach-Code. Snapshots, Domain-Profil, Historie, Speichergrenzen und Modulquellen werden innerhalb dieser Adresse aufgelöst. Evidenz aus einem anderen Workspace, Host-Scope, Land oder einer anderen Sprache gehört zu einem anderen Kontext, auch wenn der Markenname gleich aussieht.

Der optionale Keyword-Gap-Vergleich ergänzt einen gerichteten Domain-Paar-Kontext für genau einen Lauf. Er wird nicht zum allgemeinen Profilmodul, weil eine Lücke aus Quell-Domain und fehlender Vergleichsdomain besteht. Bewahre bei jeder Übergabe beide Seiten und ihre Richtung.

Wähle zwischen Domain-Profil und unveränderlichem Lauf

Der Selector gruppiert erhaltene Läufe nach Domain und sortiert sie absteigend. Die Option Domain-Profil behält den aktuell gewählten Domain- und Marktkontext bei; sie springt nicht heimlich zum neuesten Lauf einer anderen Domain. Ältere Analysen werden seitenweise nachgeladen, ohne das aktuelle Dossier zu wechseln.

Nutze das Profil für die jüngste erfolgreiche Evidenz jedes geeigneten Moduls. Nutze einen datierten Lauf für ein einzelnes Beschaffungsereignis mit ursprünglichem Plan, Modulzuständen, Kostenabschluss, Gap-Richtung und Abdeckung. Ein Ansichtswechsel aktualisiert keine Provider-Daten und überschreibt keinen Lauf.

• Ein laufender Vorgang bleibt auswählbar, damit sein Fortschritt sichtbar ist.
• Ein fehlgeschlagener oder zu löschender Eintrag verdrängt beim Einstieg keinen älteren brauchbaren Lauf.
• Ein einfacher Domain-Deep-Link öffnet vorhandene brauchbare Daten, wenn sie in der geladenen Historie gefunden werden.
• Ein gerichteter Gap-Deep-Link öffnet das Bezahlformular, weil er ein neues paarbezogenes Ergebnis verlangt.

Lies Identität und Provenienz vor der ersten Kennzahl

Halte die verschiedenen Evidenzuhren sichtbar

Die Erstellungszeit des Laufs zeigt, wann Crawl Foundry die Analyse angenommen hat. Der Abschluss nennt die Speicherung des terminalen Ergebnisses. Ein Modul kann zusätzlich Abrufzeit und Provider-Aktualisierungszeit tragen. Monatliche Historienzeilen besitzen eigene Monate. Die Profilzeit zeigt die Änderung der abgeleiteten Projektion und nicht den Abruf aller Provider-Werte.

Diese Uhren können abweichen. Ein aktuell gebauter Profilkopf kann letzte bekannte Backlink-Zeilen aus einem älteren Lauf enthalten, während Rankings neuer sind. Ein neuer Crawl Foundry-Lauf kann Provider-Historie enthalten, deren jüngster Monat vor der Anfrage liegt. Nutze Modulquelle und Provider-Datum der konkreten Aussage, statt der ganzen Seite ein Frische-Datum zu geben.

Starte nur bei verändertem oder zu altem Entscheidungskontext neu

Kaufe keinen neuen Lauf, nur weil die Profilprojektion noch gebaut oder eine weitere Listenseite noch nicht geladen wird. Profilaufbau und Pagination lesen gespeicherte Daten und rufen keinen Provider auf.

• Domain, Land, Sprache, Keyword-Tiefe oder Vergleichsrichtung haben sich geändert.
• Die relevante Modulquelle ist nach Berücksichtigung des Provider-Takts zu alt für die Entscheidung.
• Ein benötigtes Modul ist nicht verfügbar und ein selektiver Repair ist nicht sinnvoller.
• Nach einer Änderung wird nach ausreichender Aktualisierungszeit eine vergleichbare Messung gebraucht.
• Ein vorhandener brauchbarer Lauf kann die neue Frage nur beantworten, wenn sein Scope fälschlich umgedeutet würde.

Verstehe Angebot, Reservierung, Abrechnung und Speicherprüfung

Das Vorabangebot löst erlaubten Plan, Provider-Preiskatalog, Aufschlag und Wechselkurs auf und prüft die ausgabefähige Organisationsbalance. Der Start reserviert den angebotenen Kundenbetrag in derselben Transaktion, in der der laufende Snapshot entsteht. Die endgültige Abrechnung nutzt die real protokollierten Provider-Kosten ausgeführter Schritte mit eingefrorenem Preiskontext.

Ein terminaler Fehler ohne Provider-Ausgaben gibt die Reservierung frei. Ein Fehler nach positiver Ausgabe rechnet diese Ausgabe als Fehlertransaktion ab, statt sie als erstattet darzustellen. Teilweise Läufe rechnen geholte Arbeit ab. Finanzielle Evidenz bleibt erhalten, wenn das Dossier später gelöscht wird.

• Das Formular zeigt die aktuell wirksamen Limits für Workspace und Domain-Kontext und verspricht kein unbegrenztes Archiv.
• Die Code-Defaults sind 500 erhaltene Header pro Workspace und 100 je Domain-, Länder- und Sprachkontext; die aufgelöste Policy bestimmt das tatsächlich angezeigte Limit.
• Bei voller Kapazität müssen geeignete ältere Analysen gelöscht oder die Aufbewahrungsverarbeitung abgewartet werden.
• Ein Retry derselben sicheren Client-Request-ID mit identischen Eingaben gibt die vorhandene Anfrage zurück, statt eine zweite Belastung zu erzeugen.

Lies Lauf- und Modulzustände, ohne fehlende Daten zu null zu machen

Ein abgeschlossener Lauf kann verfügbare, leere oder begrenzte Module enthalten. Ein teilweiser Lauf besitzt mindestens eine fehlgeschlagene Quelle neben brauchbarer geholter Evidenz. Ein fehlgeschlagener Lauf hat kein brauchbares Dossier, kann aber abgerechnete Provider-Kosten tragen, wenn Upstream-Arbeit vor dem Fehler abgeschlossen wurde. Der sichtbare Fehler trennt aufgezeichnete Ausgaben von einem nie gestarteten Dispatch.

Für ein Modul bedeutet leer eine erfolgreiche Messung ohne zurückgegebenes Ergebnis im Scope. Fehlgeschlagen und ausstehend sind keine null. Nicht angefordert bedeutet, dass Plan oder Anfrage das Modul nicht enthielten. Begrenzt kennzeichnet ein aktuelles Teilset, dessen fehlende Zeilen nicht als verloren gelten. Legacy heißt, dass einem älteren Lauf das neue Manifest fehlt und er konservativ gelesen werden muss.

Sichere bei einem teilweisen oder fehlgeschlagenen Lauf die Details und nutze die Fehlersuche in Activity, bevor du Ersatzdaten anforderst.

Prüfe die Quellwahl im Domain-Profil

Nur abgeschlossene oder teilweise Läufe mit erfolgreicher Modul-Evidenz können das Profil beliefern. Ein neueres erfolgreiches Modul ersetzt die ältere Quelle. Ein neuerer Modulfehler lässt die ältere erfolgreiche Evidenz als letzten bekannten Stand sichtbar. Ein neueres erfolgreich leeres Modul ersetzt eine ältere nicht leere Quelle, weil alte Zeilen sonst fälschlich aktuell wirken würden.

Aktuell, letzter bekannter Stand und nicht verfügbar sind Quellzustände und keine Urteile über die Domain. Zeilen aus einem begrenzten Top-Set können außerhalb des neuesten Samples statt historisch sein. Das Profil verschmilzt keine Provider-Werte zu erfundenen Zeilen, sondern verweist auf erhaltene Snapshot-Evidenz.

Kaufe nur fehlende Profilmodule, wenn das genügt

Besitzt ein fertiges Profil nicht aktuelle Module, bietet Fehlende Daten abrufen nur geeignete Refresh-Module an. Der Nutzer wählt Bereiche, wartet auf einen neuen einmaligen Höchstpreis, bestätigt ausreichende Balance und startet einen verknüpften Repair-Lauf. Kein Hintergrundprozess darf diese bezahlte Anfrage stellvertretend bestätigen.

Der selektive Refresh umfasst Sichtbarkeitsübersicht, Historie, Ranking-Keywords, Wettbewerber, Top-Seiten, Backlink-Zusammenfassung, Ankertexte, verweisende Domains und indexierte Seiten. Der gerichtete Keyword Gap ist ausgeschlossen, weil er einem ausdrücklichen Domain-Paar gehört. Ein Repair bleibt ein echter Snapshot mit eigenem Zustand, Kostenbeleg, Quelle und Lebenszyklus.

Mache einen Vergleich reproduzierbar, bevor du das Delta liest

Kenne die aktuellen Aufbewahrungsstufen

Innerhalb eines Workspace-, Domain-, Länder- und Sprachkontexts behalten alle brauchbaren Analysen bis 180 Tage ihre Detailzeilen. Die zehn neuesten brauchbaren Analysen behalten ihre Zeilen außerdem bis zu 365 Tage. Von einem Profilmodul, lebenden Vergleich oder abhängigen Lauf referenzierte Snapshots sind geschützt. Der jüngste brauchbare Lauf des Kontexts bleibt auch bei inaktiver Domain geschützt.

Geeignete ältere Läufe werden kompaktiert: Keyword-, Wettbewerber-, Seiten-, Ankertext-, Referring-Domain- und weitere Detailzeilen entfallen, während Header-Metriken und Historie erhalten bleiben. Ungeschützte Header über drei Jahre werden gelöscht. Fehlgeschlagene Läufe werden nach 30 Tagen entfernt. Gespeicherte Vergleiche laufen nach einem Jahr ab und geben ihre Referenzen frei. Maßgeblich ist das Laufalter; geschützte oder jüngste brauchbare Evidenz kann die reguläre Stufe überleben.

Lösche sicher und erhalte den Prüfpfad

Ein Nutzer mit der erforderlichen Bearbeitungsberechtigung kann die Löschung eines terminalen Laufs anfordern. Laufende Analysen sind gesperrt. Referenzen aus gespeichertem Vergleich oder abhängigem Deep-Lauf müssen zuerst durch Entfernen des abhängigen Datensatzes gelöst werden. Verweist ein Profil auf den Lauf, baut Crawl Foundry die Projektion aus verbleibender Evidenz neu, bevor Zeilen begrenzt gelöscht werden.

Die Löschung entfernt die gespeicherte Analyse, nicht das Finanz-Ledger und nicht bereits ausgeführte Provider-Arbeit. Halte vorab jeden Quelllauf fest, den eine offene Entscheidung benötigt. Prüfe danach, welche Profilmodule aktuell, letzter bekannter Stand oder nicht verfügbar sind und ob ein Bericht noch Evidenz zitiert, die in der Workspace-Oberfläche nicht mehr existiert.

Beispiel: Nur das Backlink-Modul aktualisieren

Häufige Fragen