Was sich in Contextter geändert hat
Ein datierter Verlauf neuer Funktionen, verbesserter Abläufe, behobener Fehler und Änderungen, die bestehendes Verhalten betreffen.
Die öffentliche Suche konzentriert sich auf die wichtigsten Produktseiten
Die Navigation und die Suchmaschinen-Signale der öffentlichen Contextter-Website priorisieren jetzt Startseite, Plattform und Lösungen. Vergleichs- und Alternativseiten sind nicht mehr veröffentlicht. Tools und Ressourcen bleiben erreichbar, belegen aber keinen Platz mehr in der globalen Navigation. Die XML-Sitemap enthält außerdem keine Rechts- und Hilfsseiten mehr. Kategorie-, Tag- und Autorarchive des Blogs werden erst dann für Suchmaschinen freigegeben, wenn mindestens drei veröffentlichte Beiträge das Archiv tragen. Jeder veröffentlichte Artikel bleibt weiterhin über seine eigene URL erreichbar.
Verbundene Agenten können frische SEO-Arbeit mit festem Kostenlimit anfragen
Verbundene Agenten können jetzt eine Freigabe für frische Keyword-Recherche, Keyword-Metriken, Wettbewerbsanalysen, AI Visibility, Domain-Snapshots und Site Audits anfragen. Jede Anfrage nennt die genaue Funktion und enthält einen maximalen Betrag in EUR. Nichts startet automatisch. Der Zugriff bleibt an Organisation, Workspace, verbundenen Client und Eigentümer gebunden. Vor dem Start kostenpflichtiger Arbeit reserviert Contextter den genehmigten Höchstbetrag aus dem EUR-Guthaben. Danach werden die tatsächlichen Kosten abgerechnet oder der nicht verwendete Betrag wieder freigegeben.
Öffentliche Website konzentriert sich auf Deutsch und Englisch
Die öffentliche Contextter-Website unterstützt vorerst Deutsch und Englisch. Der Sprachumschalter und die HTML-Sitemap zeigen nur noch diese beiden Sprachen. Frühere französische und spanische URLs werden dauerhaft auf denselben englischen Pfad weitergeleitet, statt Fehlerseiten oder eigenständige Seiten zu erzeugen. Die vorhandenen Übersetzungsdaten bleiben intern erhalten. Französisch oder Spanisch kommen erst wieder als öffentliche Sprachen hinzu, wenn Contextter Produkterlebnis und Inhaltsqualität in der jeweiligen Sprache verlässlich pflegen kann.
Öffentliche Seiten deklarieren jetzt ihre Sprache im HTML
Die öffentlichen Contextter-Seiten deklarieren die aktive Sprache jetzt im serverseitig gerenderten HTML. Englische Seiten verwenden `en`, deutsche Seiten `de`. Browser, assistive Technologien und Crawler können lokalisierte Inhalte dadurch erkennen, bevor clientseitiger Code ausgeführt wird. Canonical-URLs und Sprachalternativen bleiben unverändert.
Verbundene Agenten können ihre genehmigten Zugriffe zuverlässig prüfen
Verbundene Agenten können die Autorisierungsfreigaben für den ausgewählten Workspace jetzt auch dann auflisten, wenn noch keine Freigabe vorhanden ist. Eine leere Liste gilt als regulärer Zustand und unterbricht die Verbindung nicht mehr. Die Anfrage bleibt an Organisation, Workspace, verbundenen Client und Eigentümer gebunden. Leselimits gelten weiterhin. Die Prüfung des Freigabestatus reserviert kein EUR-Guthaben und startet keine kostenpflichtige SEO-Arbeit.
Die zentralen SEO-Arbeitsbereiche folgen jetzt derselben Leserichtung
Dashboard, Action Center, Domain-Übersicht, Keyword-Recherche, Keyword-Datenbank, Position Tracking, Site Audit und Aktivität folgen jetzt derselben Leserichtung: aktueller Zustand, Belege oder Veränderung, der nächste sinnvolle Schritt und die spätere Verifikation. Die vorhandenen Kennzahlen, Diagramme, Filter, Tabellen und Fachansichten bleiben erhalten. Lange Berichte verwenden die Seite als vertikalen Lesefluss, statt die Arbeit auf mehrere kleine Scrollbereiche aufzuteilen. Breite Tabellen und Modultabs bleiben auf schmalen Bildschirmen horizontal erreichbar. Es bleibt erkennbar, ob Daten gerade laden, fehlen, nur teilweise oder veraltet vorliegen, ein Abruf fehlgeschlagen ist oder eine Messung noch aussteht. Action Center und Position Tracking halten außerdem Ansicht, Umfang, Filter und Detailkontext in der URL fest. Geteilte Links und die Browsernavigation führen dadurch in denselben Arbeitskontext zurück, statt eine allgemeine Übersicht zu öffnen.
Jede Produktseite benennt jetzt ihr konkretes SEO-Tool
Die Homepage beschreibt Contextter jetzt als SEO-Software auf Abruf ohne Abo-Pflicht. Sie trennt das kostenlose Organisieren und Exportieren klar von frischen Daten, die nur bei Bedarf angefordert werden. Platform, Keyword-Datenbank, Site Audit und die sieben Feature-Seiten nennen ihre jeweilige Produktkategorie in Hauptüberschrift und Suchmetadaten. Dekorative Beispiel-Keywords im Homepage-Hero werden nur noch visuell gezeichnet und sind keine Textknoten des Seiteninhalts mehr. Jedes Homepage-Kapitel verlinkt jetzt auf die passende Produkt- oder Solution-Seite. Ein neuer Nachweisbereich erklärt außerdem den Umfang bezahlter Aktionen, die Aktualität der Daten und die Grenzen späterer Vergleiche. Lokalisierte Seiten setzen die aktive Dokumentsprache, ohne das statische Rendering aufzugeben.
Workspace-Analysen bleiben kompakt und zeigen bereits vorhandene Daten
Domain-Übersicht und Wettbewerbsanalyse nutzen die verfügbare Bildschirmhöhe jetzt einheitlich. Wettbewerberlisten wachsen nur bis zu ihrer maximalen Höhe und scrollen danach innerhalb ihres Bereichs. Die zugehörigen Karten und Diagramme nutzen den übrigen Platz. Site Audit verwendet in seinen dichten Ansichten jetzt jeweils einen gezielten Inhalts-Scrollbereich. Zusammenfassungen zu Klicktiefe und Problemkategorien sind kompakter, Beschriftungen bleiben lesbar und Diagramme ziehen benachbarte Karten nicht mehr unnötig in die Länge. Position Tracking zeigt gespeicherte Ranking-Verläufe auch dann, wenn der neueste geplante Lauf nicht starten konnte, und gibt dessen Status korrekt wieder. Beim Start einer Keyword-Recherche bleibt der aktive Zustand schlank, statt Ergebnisdaten zu laden, bevor sie vorhanden sind.
Die wichtigsten Marketingseiten benennen ihre Suchintention jetzt klar
Die Homepage beschreibt Contextter jetzt als KI-gestützte SEO-Plattform für Keyword-Recherche, technische Site Audits, Priorisierung und messbare SEO-Workflows. Diese Kategorieaussage steht im ersten sichtbaren Bereich und in den Metadaten. Platform, Features, Keyword-Datenbank, Site Audit, Solutions, Pricing, Ressourcen, Learning Center, Tools und Owned Data haben nun eigene Titel und Beschreibungen, die zur Aufgabe der jeweiligen Seite passen. Die kürzeren Beschreibungen machen Suchergebnis-Snippets klarer, ohne Rankings oder Traffic zu versprechen.
Agenten-Verbindungen beginnen jetzt mit der Aufgabe, nicht mit dem Protokoll
Die Agent Platform öffnet jetzt mit einer geführten MCP-Verbindung für Codex, Claude, Visual Studio Code, Cursor und andere kompatible Clients. Der ausgewählte Workspace ist Teil der Verbindung, OAuth ist der Standardweg und technische Endpunkte sowie der Inspector bleiben bei Bedarf erreichbar. Die Fähigkeitsansicht erklärt 21 klar abgegrenzte SEO-Tools statt des deutlich größeren internen Operationskatalogs. Keyword-Recherche, Domain- und Wettbewerbsanalyse, Site Audit, Tracking, Planung, Content, Veröffentlichung und Verifikation sind nach dem Ergebnis gruppiert, das ein Agent liefern kann. Die Developer API hat einen eigenen erweiterten Bereich mit Workspace-spezifischen Zugängen, Abrechnungshinweisen und API Explorer. MCP und REST verwenden dasselbe EUR-Guthaben der Organisation, dieselben Freigaberichtlinien, Kostenlimits und Settlement-Kontrollen.
Site-Audit-Beispiele sind jetzt eindeutig gekennzeichnet
Die öffentliche Site-Audit-Übersicht kennzeichnet ihre dargestellten Crawl-Zahlen und den Laufverlauf jetzt als Beispieldaten. Die Vorschau bleibt konkret, ohne wie ein echter Kunden-Audit zu wirken. Jede beispielhafte Problemfamilie erklärt außerdem ihre eigene Auswirkung und Prüfung. Defekte Links, fehlende Canonicals, Weiterleitungsketten und verwaiste Seiten teilen sich nicht länger eine allgemeine Canonical-Erklärung. Die angezeigten URLs sind ausdrücklich als Beispiele gekennzeichnet.
Abrechnung trennt jetzt Geldflüsse, Guthaben, Rechnungen und Belege
Der Abrechnungsverlauf beantwortet jetzt zwei verschiedene Fragen getrennt: Wie viel Geld wurde bezahlt oder erstattet, und wie viel vorausbezahltes EUR-Guthaben wurde hinzugefügt oder entfernt? Diese Trennung ist wichtig, wenn ein Plan mehr Guthaben enthält als sein Kaufpreis. Bei älteren Transaktionen ohne belastbaren Zahlungsbetrag steht „nicht verfügbar“, statt einen Wert zu schätzen. Abgeschlossene Polar-Bestellungen zeigen die Rechnungs- oder Beleglinks, die Polar zurückgibt. Fehlt ein Dokumentlink, verweist Contextter auf das Polar-Kundenportal, statt eine zweite Rechnung oder einen Beleg zu erfinden. Der Portalzugang bleibt auch nach dem Wechsel in den Free-Plan bestehen. Frühere Bestellungen, Rechnungsadressen, Steuerdaten und Zahlungsmethoden lassen sich dort weiterhin verwalten. Vor einem neuen Abonnement oder einer Aufladung legt der Käufer fest, ob der Kauf privat oder geschäftlich erfolgt. Polar bleibt Merchant of Record und erhebt Rechnungs- und Steuerdaten im Checkout. Die Bestätigung erklärt, dass Contextter keine freiwilligen Erstattungen für ungenutzte Abo-Zeit oder vorausbezahltes Guthaben anbietet. Zwingende Rechte und von Polar veranlasste Erstattungen bleiben unberührt. Öffentliche Wege für Kündigung und Verbraucherwiderruf sind auch außerhalb der Produktnavigation erreichbar. Das Kündigungsformular unterscheidet zwischen ordentlicher und außerordentlicher Kündigung und fragt den wichtigen Grund nur im zweiten Fall ab. Beide Erklärungen zeigen sofort eine Referenz und senden eine Bestätigung per E-Mail. Eingeloggte Kunden können ohne vorgeschaltete Feedback-Umfrage direkt zur Kündigung bei Polar wechseln. Die öffentlichen Formulare und ihre Zustellung wurden im Browser geprüft. Für Checkout, Dokumente, Portal, Verlängerung, Erstattung, Kündigung und Widerruf im eingeloggten Produkt fehlen noch kontrollierte Produktionstransaktionen, bevor der gesamte Anbieterablauf als live belegt gelten kann. Diese Veröffentlichung behauptet keine Freigabe durch Rechts- oder Steuerberatung.
Keyword-Recherche findet mehr, merkt sich Bezahltes und reicht bis 2019 zurück
Die tiefe Keyword-Recherche kombiniert jetzt zwei ergänzende Erweiterungsmethoden. Eine kategoriebasierte Abfrage deckt alle Seeds in einem Auftrag ab und liefert zu jedem Keyword Volumen, CPC, Schwierigkeit, Intention und einen 12-Monats-Verlauf. Importierte Kandidaten bringen ihre Grundkennzahlen dadurch bereits mit. Ein Phrasen-Scan ergänzt pro Seed bis zu 300 Ideen, die die eingegebene Formulierung direkt enthalten. Beide Methoden stehen vor dem Start als eigene Positionen in der Kostenvorschau. Bereits bezahlte Daten werden konsequenter wiederverwendet. Keywords mit Grundkennzahlen aus einem früheren Discovery-Import gelten bei Frischeprüfungen und der automatischen Anreicherung nach dem Import als abgedeckt. Derselbe Grunddatensatz wird nicht erneut gekauft, nur weil das Keyword über einen anderen Weg in den Workspace gelangt ist. Das Keyword-Dossier ergänzt das optionale Paket „Historie ab 2019“. Es erweitert den 12-Monats-Trend zu einer mehrjährigen Monatsreihe und wurde für ungefähr einen Cent pro Keyword zum Preis der Datenquelle eingeführt. Das Paket lässt sich in der Trendsektion für ein einzelnes Keyword oder im Anreicherungsdialog für eine Auswahl anfordern. Jede Zeile der Discovery-Ergebnisse öffnet nun ein Dossier. Ein bereits vorhandenes Keyword führt in seine vollständige Workbench-Ansicht. Ein noch nicht importierter Kandidat öffnet eine kompakte Leseansicht mit den Kennzahlen, die der aktuelle Lauf bereits bezahlt hat. Die Belege stehen damit vor der Importentscheidung zur Verfügung. Die automatische Grunddaten-Anreicherung nach einem Import verwendet jetzt eine günstigere Lieferoption, wenn die primäre Quelle ein Keyword nicht kennt. Dieser Weg kostet ungefähr ein Drittel weniger als ein sofortiger Abruf und liefert die Volumendaten normalerweise innerhalb weniger Stunden. Interaktive Anreicherungen behalten die sofortige Option, wenn jemand auf das Ergebnis wartet.
Der Wettbewerberkatalog verbindet bezahlte Daten mit konkreten Entscheidungen
Jeder Wettbewerber öffnete nun mit einer Übersicht seines organischen Fußabdrucks: Ranking-Keywords, geschätzter Traffic und Wert, jüngste Bewegung und Positionsverteilung. Rankingtabellen behielten die genaue URL hinter jedem Keyword. Quellen-Badges erklärten, warum eine Domain in den Katalog gelangte und bei welcher Suchanfrage sie zuletzt auffiel. Vorhandene Domain-Overview-Belege wurden erneut verwendet, statt denselben Kauf noch einmal anzufordern. Competitive Research trennte Übersicht, Katalog, Vergleich und Statistiken. Vergleiche zeigten Modulabdeckung, Erhebungszeitpunkte, Fehler und ein Fazit mit dem vorgeschlagenen nächsten Schritt. Unvollständige Läufe öffneten ihre Belege, statt vollständig zu wirken. Tiefere Daten luden erst für den geöffneten Tab. Das verkürzte den ersten Aufruf, während Traffic-Historie, Keyword-Profile, Linksignale und Marktkarte bei Bedarf verfügbar blieben.
Domain Overview macht mehr gespeicherte Belege nutzbar
Domain Overview machte mehr gespeicherte Analysebelege in Arbeitsansichten nutzbar. Rankings ergänzten SERP-Feature-Abdeckung, Volumentrends und Positionsdiagramme. Wettbewerber zeigten ihr Rankingprofil, Seiten ihre Traffic-Konzentration und Backlinks die Verteilung nach Autorität, Linkposition und verweisender Domain. Der Verlauf trennte geschätztes Traffic-Wachstum, Keyword-Bewegung, Rankinganteile und Churn. Jedes Diagramm nannte seine Datengrundlage und verwendete begrenzte Server-Aggregate statt nur der aktuell sichtbaren Tabellenzeilen. Die neue Ansicht Opportunities identifizierte interessante Rankingbereiche mit einer offengelegten CTR-Schätzung, Brand-Heuristik, SERP-Feature-Exposition und relativer Autorität. Das waren Entscheidungssignale, keine Traffic-Versprechen oder Kausalbehauptungen. Keywords ließen sich in eine Liste oder Recherche überführen, Wettbewerber speichern und wichtige Seiten sowie häufig verlinkte Ziele gegen den letzten Site Audit prüfen. Seiten außerhalb dieses Crawls blieben nicht zugeordnet, statt als gesund zu gelten.
Geladene Zeilen in Domain Overview lassen sich direkt sortieren
Die Tabellen in Domain Overview folgen jetzt demselben Bedienmuster. Zeilen werden beim Darüberfahren hervorgehoben, die Kopfzeile bleibt beim Scrollen sichtbar und ein Klick auf eine Datenspalte sortiert die Ergebnisse ohne zusätzliche Steuerleiste. Die Daten kommen weiterhin in kleinen Serverseiten. Sortiert werden nur die aktuell geladenen Zeilen. Kommen weitere hinzu, wird die Sortierung neu berechnet. Das ist keine globale Sortierung über die vollständige Analyse. Top Organic Keywords kann zusätzlich nach Ranking-URL und Suchintention sortieren. Keyword Gap, die vollständige Wettbewerbertabelle sowie die Tabs Rankings, Seiten, Wettbewerber und Backlinks verwenden dasselbe Verhalten.
Keyword-Importe können fehlende Grunddaten nach einer Kostenvorschau ergänzen
Die Standard-Preisregel für die Anreicherung von Keyword-Daten gibt die Datenkosten jetzt ohne Aufschlag weiter. Maßgeblich bleibt die Kostenvorschau vor dem Start, falls sich diese Preisregel ändert. Sie zeigt die gewählten Datenpakete und mögliche Ausweichrouten, bevor bezahlte Arbeit beginnt. Beim Import von Rechercheergebnissen ist die Anreicherung für Keywords mit fehlenden Grunddaten standardmäßig ausgewählt. Der Importdialog schätzt nur diesen fehlenden Umfang und lässt die Anreicherung abwählen. Keywords, die bereits frische bezahlte Kennzahlen mitbringen, werden nicht erneut gekauft. Ein optionaler Long-Tail-Fallback kann eine zweite Volumenquelle nach Begriffen fragen, die in der ersten Datenbank fehlen. Auch diese Quelle kann jedoch ohne Ergebnis bleiben. Die bereits während der Recherche gelieferten 12-Monats-Verläufe landen jetzt in der Keyword-Datenbank, statt verworfen zu werden. Wenn diese Historie vorliegt, können Trend-Sparklines direkt nach dem Import erscheinen.
Aktivitätsfilter gleichen jetzt die ganze Ansicht mit dem Export ab
Wenn du Aktivität nach Bereich, Status, Initiator, Kostenstatus oder Kalendertag filterst, ändert sich die gesamte Ansicht und nicht nur die Timeline. Kennzahlen, Tagesdiagramm, Atlas, Bereichsübersicht und Ausgaben pro Mitglied rechnen mit demselben strukturierten Umfang. Die Freitextsuche verfeinert weiterhin nur die bereits geladenen Einträge. Die Oberfläche kennzeichnet dieses engere Verhalten. Der Aktivitätskalender umfasst jetzt zwölf Monate, unabhängig vom kürzeren Analysezeitraum. Tageszusammenfassungen liefern exakte Kalenderwerte statt einer Stichprobe. Der aktuelle Tag wird aus den laufenden Vorgängen neu berechnet. Solange ältere Historie noch aufgebaut wird, markiert die Ansicht diesen Zustand und verwendet einen begrenzten Ersatzwert, statt die Zusammenfassung als vollständig auszugeben. Jede Ansicht lässt sich als CSV-Datei mit den gerade sichtbaren Zeilen exportieren. Die Datei hält ihren Umfang fest, einschließlich Zeitraum, Zeilenzahl und Erstellungsdatum. Kostenspalten erhalten nur Mitglieder mit Abrechnungsberechtigung. Läufe des Optimizers und des Precision Editors, die nach dieser Veröffentlichung erfasst werden, erscheinen als benannte Vorgänge mit eigenem Ergebnis und eigener Dauer statt als nicht zugeordnete Nutzungskosten. Frühere Läufe wurden nicht nachträglich rekonstruiert.
Große Site-Audit-Berichte lesen bei der Veröffentlichung nicht mehr jeden Link neu
Aktuelle Crawls führen zu jeder URL exakte Linkzähler. Die Berichtsveröffentlichung verwendet diese Zähler, statt Tausende Linkdatensätze erneut zu laden. Nur ältere Crawls ohne solche Zähler benötigen diesen zusätzlichen Lesevorgang. Damit wird die kumulative Lesegrenze vermieden, durch die ein Crawl abgeschlossen sein konnte, während sein Bericht unvollständig blieb. Ein abgeschlossener oder teilweiser Lauf bleibt für die automatische Wiederherstellung zugelassen, bis die erforderlichen Veröffentlichungsschritte fertig sind. Wenn die Veröffentlichung stockt oder Berichtssummen noch berechnet werden, kann die Wiederherstellung fortfahren, sobald der Lauf lange genug inaktiv war. Für diesen unvollständigen Veröffentlichungszustand gibt es keine Altersgrenze.
Aktivität erklärt jetzt Arbeit und abgerechnete Ausgaben im Workspace
Aktivität führt die Arbeit aus dem gesamten SEO-Workspace in einem Verlauf zusammen: Domain-Übersicht, Wettbewerbsanalyse, Keyword-Arbeit, Position Tracking, Site Audit, Suchleistung, Action Center, Recherche, Content und Brain. Ein Arbeitsablauf erscheint als ein verständlicher Vorgang und nicht als Spur technischer Zwischenschritte. Die überarbeitete Ansicht zeigt Arbeit und Ausgaben pro Tag, einen Aktivitätskalender, die Entwicklung nach Bereich, Vorgänge, die geprüft werden sollten, die Datenabdeckung, Filter und eine aufklappbare Timeline mit Sprüngen in das Produkt, in dem die Arbeit stattgefunden hat. Abgerechnete Ausgaben lassen sich nach dem Mitglied aufschlüsseln, das die bezahlte Arbeit ausgelöst hat, einschließlich Anteil und Tagesverlauf. Nur Mitglieder mit Abrechnungsberechtigung erhalten diese Aufschlüsselung. Alle anderen sehen denselben Arbeitsverlauf ohne Kosten- oder Nutzerdaten. Ein Klick auf einen Kalendertag filtert die Timeline. Die Schaltfläche zum Aufheben der Auswahl sitzt neben diesem Datum im Kopf des Kalenders. Die Timeline umfasst die letzten 100 normalisierten Vorgänge. Wenn beim Zusammenführen der Daten eine Obergrenze erreicht wurde und eine Zahl deshalb unvollständig ist, weist die Abdeckungsansicht darauf hin, statt den Teilwert als vollständige Summe auszugeben.
Site-Audit-Setup verwendet die aktuellen Crawl-Limits
Das Hinzufügen einer Website zu Site Audit scheitert nicht mehr, wenn ein älterer Browserstandard die aktuell im Workspace verfügbaren Crawl-Limits überschreitet. Neue Websites übernehmen die aktiven Grenzen, die auch beim Start eines Crawls gelten. Bestehende Einstellungen bleiben kompatibel. Die Felder für Crawl-Tiefe und URL-Anzahl lassen sich leeren und neu eingeben, ohne auf den vorherigen Wert zurückzuspringen. Ihr Maximum folgt dem aktiven Produktlimit statt der aktuellen Auswahl. In den Einstellungen bestehender Websites ist nun derselbe Crawl-Umfang wie beim ersten Setup sichtbar, einschließlich Tiefe, ein- und ausgeschlossener Pfade, Rendering und robots.txt-Behandlung. Gespeicherte Änderungen gelten für künftige Läufe. Neue Audits erholen sich außerdem, wenn der Crawl-Prozess beim Start seine Verbindung verliert. Ein Lauf bleibt nicht mehr unbemerkt an der ersten Ausgangs-URL stehen, sondern versucht die Verbindung erneut und startet den fehlgeschlagenen Prozess neu, wenn die Wiederherstellung innerhalb der Grenze nicht gelingt. Monatliche Laufkontingente behandeln Ergebnisse ohne verwertbaren Crawl nun einheitlich. Abgebrochene, fehlgeschlagene und teilweise Läufe geben ihren Platz zurück, wenn weniger als zehn Seiten abgeschlossen wurden. Vollständige Läufe und unvollständige Crawls mit nennenswerter Seitenarbeit zählen weiterhin. Die seitenbasierte Abrechnung richtet sich unverändert nach den tatsächlich verbrauchten Seiten.
AI Crawler Checker öffnet jede Prüfung als vollständigen Bericht
Ergebnisse des AI Crawler Checkers öffnen jetzt in einem eigenen Bericht statt unterhalb des Formulars. Vier Eignungsurteile stehen am Anfang, Crawler-Regeln sind nach Anbieter gruppiert und Details zu Abruf, Indexierbarkeit und Extraktion liegen in einem aufklappbaren Belegbereich. Die Ansicht nutzt auch auf dem Smartphone den verfügbaren Platz und nennt den genauen Prüfzeitpunkt. Wiederholte Prüfungen derselben URL können ein bis zu 30 Tage gespeichertes Ergebnis verwenden. Geteilte oder erneut besuchte Berichte sind dadurch sofort verfügbar. Mit „Neu prüfen“ lässt sich die Live-Seite unter denselben Prüf- und Nutzungslimits erneut abrufen. Die Extraktionsmessung vergleicht jetzt den sichtbaren Text im Hauptinhalt, nicht Textmenge und rohe HTML-Größe. Seiten mit viel Framework-Markup werden dadurch nicht allein wegen ihres Quellcodes abgewertet. Auch die Belege zur internen Verlinkung konzentrieren sich auf Links im Hauptinhalt und zeigen lesbaren Ankertext statt Markup-Fragmente.
Der robots.txt-Checker bündelt Crawler-Entscheidungen in einem Bericht
Ergebnisse öffnen sich jetzt in einem eigenen Bericht statt unterhalb des Formulars. Am Anfang steht die Zahl der Such-, Trainings- und Abruf-Crawler, die den geprüften Pfad lesen dürfen. Danach folgen für jeden unterstützten Bot die entscheidende Regel und ihre Quellzeile, nach Anbieter gruppiert. Der Bericht bleibt auf dem Smartphone ohne seitliches Scrollen lesbar. Erfolgreiche Prüfungen werden bis zu 30 Tage gespeichert. Ergebnisse mit eindeutigen Fehlern bleiben nur kurz gespeichert, Netzwerkfehler gar nicht. Der Bericht zeigt, wann die Datei abgerufen wurde und ob das Ergebnis aus dem Zwischenspeicher stammt. Nach einer Änderung an der robots.txt umgeht „Jetzt neu prüfen“ das gespeicherte Ergebnis und liest die aktuelle Datei.
Der AI Traffic Checker trennt lokale Analyse und URL-Prüfungen
Eine Analyse öffnet jetzt einen Vollbildbericht mit KI-Sitzungen, Quellen, erkannten Zeilen und defekten Zielen am Anfang. Danach folgen die Bereiche für Quellen, Zielseiten, URL-Status und Datenqualität. Die Ablagezone ordnet gängige Spalten aus GA4, Plausible und Matomo zu und fragt nach, wenn eine Pflichtspalte fehlt. CSV-Zeilen werden im Browser analysiert und nicht hochgeladen. Nur die deduplizierten URLs, die für eine Statusprüfung ausgewählt wurden, gehen an den geschützten Checker. Statusergebnisse werden 30 Tage gespeichert und zeigen ihr Alter. Eine manuelle Wiederholungsprüfung umgeht das gespeicherte Ergebnis und wird auf das bestehende Tageslimit angerechnet. Browser-Verifizierung und ein unsichtbares Spam-Feld weisen automatisierte Übermittlungen ab, bevor sie den Checker erreichen.
Der Brand Voice Analyzer kann öffentliche Seiten per URL profilieren
Der URL-Modus ruft eine öffentliche Seite ab, extrahiert ihren Haupttext und analysiert diesen Text im Browser. Wenn die Seite abrufbar ist, öffnet sich ein eigener Vollbildbericht mit Satzrhythmus, Perspektive, Stilmarkern, wiederkehrenden Formulierungen und Schreibrichtlinien. Erfolgreiche Abrufe werden 30 Tage gespeichert. Der Bericht zeigt den Zeitpunkt und ob das Ergebnis aus dem Zwischenspeicher stammt. Eindeutige Abruffehler werden fünf Minuten gespeichert, vorübergehende Fehler beim nächsten Versuch erneut geprüft. Die extrahierte Textmenge ist auf 100.000 Zeichen begrenzt, und URL-Prüfungen sind durch eine Browser-Verifizierung geschützt. Im Einfügemodus gibt es keine Serveranfrage. Die Textprobe geht direkt an die lokale Analyse im Browser.
Featured Snippet Checker prüft jetzt eine Live-Seite per URL
Der kostenlose Featured Snippet Checker kann eine öffentliche Seite jetzt direkt abrufen. Nach dem Einfügen der URL extrahiert der Bericht den Hauptinhalt, prüft Antwortstruktur und Überschriftenhierarchie und zeigt, ob wichtige Passagen für sich verständlich sind. Das Ergebnis öffnet in einer konzentrierten Vollbildansicht statt in einer schmalen Spalte unter dem Formular. Geprüfte Seiten können aus einem bis zu 30 Tage gespeicherten Snapshot erneut geöffnet werden. Der Bericht nennt dessen Zeitpunkt, damit ein sofortiges Wiederholungsergebnis nicht wie ein neuer Abruf wirkt. Eine kurze Browserprüfung schützt den öffentlichen URL-Check vor automatisiertem Missbrauch. Die Analyse eingefügter Texte bleibt vollständig lokal im Browser.
Die kostenlosen Checks sind dort verlinkt, wo sie weiterhelfen
Die sechs kostenlosen Checks stehen jetzt neben den Aufgaben, die sie unterstützen. Site Audit verweist auf den AI Crawler Checker, Keyword Discovery auf das People Also Ask Tool, SEO Monitoring auf den AI Traffic Checker und die Technical-SEO-Lösung auf den robots.txt Checker. Die Startseite stellt die Tool-Familie vor, die Plattformseite führt zur vollständigen Übersicht. Jede Empfehlung erklärt, welche Frage der Check beantwortet, und macht deutlich, dass dafür kein Konto nötig ist. So führt der Weg von einem Produktkonzept direkt zu einer begrenzten öffentlichen Prüfung, ohne erst die Website nach dem passenden Werkzeug durchsuchen zu müssen.
AI Crawler Checker zeigt, was KI-Crawler tatsächlich erreichen
Der kostenlose AI Crawler Checker untersucht jetzt eine öffentliche URL und zeigt, welche Inhalte ein Crawler tatsächlich erreichen kann. Er folgt gültigen öffentlichen Weiterleitungen, prüft die robots.txt des endgültigen Ziels und berichtet über Seitenzugriff, Indexierbarkeit, Canonical- und Snippet-Steuerung, crawlerspezifische Regeln, extrahierbaren Inhalt, Überschriftenstruktur und interne Verlinkung. Jedes Urteil ist mit den zugrunde liegenden Belegen verbunden. Der Bericht nennt Weiterleitungsschritte und relevante X-Robots-Tag-Anweisungen, statt eine komplexe Konfiguration auf ein pauschales Ja oder Nein zu verkürzen. Komprimierte Antworten werden innerhalb derselben festen Prüfgrenzen verarbeitet; unsichere oder private Ziele bleiben ausgeschlossen. Der Checker führt kein JavaScript der geprüften Seite aus und sendet den untersuchten Inhalt nicht an ein externes Textmodell. Diese Grenze steht im Bericht, damit klar bleibt, was geprüft wurde und wofür weiterhin ein Browser- oder manueller Review nötig ist.
AI Traffic Checker prüft jetzt Verweis-URLs
Der kostenlose AI Traffic Checker kann jetzt eine begrenzte Liste öffentlicher Verweis-URLs prüfen. Für jede Adresse zeigt er, ob die Seite antwortet, wo Weiterleitungen enden, welche endgültige URL erreicht wurde und warum eine Prüfung gescheitert ist. Jede URL wird unabhängig geprüft. Ist eine Quelle vorübergehend nicht erreichbar, bleiben die übrigen Ergebnisse nutzbar und der fehlgeschlagene Abruf sichtbar. Prüfungen auf öffentliche Ziele, feste Größen- und Zeitgrenzen sowie Nutzungslimits halten den kostenlosen Check berechenbar, ohne Teilergebnisse als vollständigen Erfolg darzustellen.
AI robots.txt Checker erklärt den Zugriff Regel für Regel
Der kostenlose AI robots.txt Checker liest jetzt die robots.txt einer öffentlichen Website und erklärt, wie deren Regeln bekannte KI-Crawler betreffen. Er unterscheidet erlaubte, blockierte und widersprüchliche Fälle, statt die gesamte Datei auf ein unbelegtes Gesamturteil zu reduzieren. Für jeden Crawler zeigt das Ergebnis die passende Anweisung und ihre Quellzeile. Allgemeine User-Agent-Regeln, speziellere Ausnahmen und Konflikte lassen sich dadurch leichter nachvollziehen. Die Prüfung akzeptiert nur öffentliche Ziele und nutzt feste Grenzen für Inhalt, Dauer und Anfragen, damit auch ungewöhnlich große oder fehlerhafte Dateien beherrschbar bleiben.
Der Brand Voice Analyzer erstellt jetzt vollständige private Stilprofile
Der kostenlose Brand Voice Analyzer verwandelt Textproben ab 100 Wörtern in nachvollziehbare Belege zu Sätzen, Absätzen, Zeichensetzung, Perspektive, Markern, Wiederholungen und lexikalischer Vielfalt auf Deutsch, Englisch, Französisch oder Spanisch. Ab 300 Wörtern entsteht das vollständige Profil; kürzere akzeptierte Proben sind klar als begrenzt markiert. Die vollständige Analyse bleibt im Browser. Selbst eine Textprobe nahe der Grenze von 100.000 Zeichen hält die Oberfläche deshalb nicht fest. Der eingegebene Text wird weder hochgeladen noch protokolliert oder an ein externes Textmodell gesendet. Das Briefing lässt sich kopieren und das strukturierte Profil als JSON herunterladen, ohne die ursprüngliche Textprobe mit zu exportieren.
Featured Snippet Checker erklärt große und mehrdeutige Dokumente klarer
Der browserbasierte Featured Snippet Checker überspringt jetzt leere Strukturen, wenn er nach einer direkten Antwort sucht. Er nennt die Länge der ausgewählten Passage und zeigt, welche Abhängigkeiten eine Antwort ohne den umgebenden Kontext schwer verständlich machen. Bei großen Dokumenten erscheint vor der lokalen Verarbeitung ein sichtbarer Analysestatus. Befunde, Belege, Gliederung, erkannte Strukturen und Fragen werden als getrennte Vorschauen dargestellt. Das Ergebnis auf der Seite bleibt auch bei tausenden wiederholten Überschriften begrenzt, während Markdown-, Checklisten- und JSON-Exporte sämtliche Befunde enthalten.
People Also Ask Tool trennt beobachtete Vorschläge von Annahmen
Das kostenlose People Also Ask Tool sammelt jetzt eine begrenzte Menge beobachteter Google-Autocomplete-Vorschläge für ein Thema, eine Sprache und einen Markt. Es gruppiert die Ideen nach Fragen, Vergleichen, Alternativen oder Reviews und nützlichen Suchaufgaben. Zu jedem Vorschlag bleibt sichtbar, aus welcher Abfragestrategie er stammt. Der Bericht unterscheidet eine aktuelle Beobachtung von einem zuvor gespeicherten Ergebnis. Autocomplete-Vorschläge werden weder als kopierter People-Also-Ask-Block noch als Suchvolumen, Rankingbeleg oder Häufigkeitswert ausgegeben. Leere und teilweise Ergebnisse bleiben erkennbar. CSV- und JSON-Exporte bewahren genau das, was tatsächlich beobachtet wurde, und ein vollständiger Reset erleichtert den Vergleich mehrerer Recherchen.
Sechs kostenlose SEO-Tools starteten mit ehrlichen Vorschauseiten
Am 30. Juli gingen im Tool-Hub sechs Prüfseiten online. Sie behandelten Crawler-Zugriff, Fragenrecherche, Antwortstruktur, Schreibstil und KI-Verweise. Bei dieser Veröffentlichung erklärte jede Seite Eingabe, Belege und Methode, zeigte einen Beispielbericht und nannte den passenden nächsten Schritt in Contextter. Diese ersten Seiten führten keine Analyse aus. Das frühere Formular des SERP Analyzers, das nie einen Bericht erzeugte, leitete stattdessen zum Hub weiter. Die Vorschau war vorübergehend: Spätere Veröffentlichungen schalteten jedes Tool erst live, als Verarbeitung, Missbrauchsschutz, Limits und Ergebnisvalidierung bereitstanden. Im Hub sind inzwischen alle sechs Tools als live gekennzeichnet.
Das Action Center speichert Kalibrierungsantworten im aktuellen Profil
Stammt eine Frage zur geschäftlichen Passung aus einem älteren Action-Center-Bericht, wird die Wahl „relevant“ oder „nicht relevant“ jetzt auf das aktuelle Geschäftsprofil angewendet. Vorhandene Kalibrierungsentscheidungen bleiben erhalten. Eine Profilaktualisierung macht die nächste Antwort damit nicht mehr zu einem Versionskonflikt. Die Schaltflächen warten, bis das aktuelle Profil verfügbar ist, und werden während des Speicherns gesperrt. Diese Übernahme gilt nur für Kalibrierungsantworten. Eine direkte Änderung an einer veralteten Profilversion wird weiterhin abgelehnt, statt neuere Arbeit zu überschreiben.
Produktlimits verwenden jetzt einen gemeinsamen serverseitigen Richtlinienkatalog
Dashboard, Action Center, Domain-Übersicht, Keyword-Recherche, Wettbewerbsanalyse, Position Tracking, Site Audit, Aktivität und Keyword-Datenbank verwenden für die daran angebundenen Grenzen stabile Definitionen aus einem gemeinsamen Richtlinienkatalog. Produkt-, Plan- und Sicherheitslimits bleiben getrennt. Für jede neue Anfrage gilt ein zusammenhängender Stand dieser Regeln. Wird eine angebundene Grenze herabgesetzt, gilt der neue Wert für die nächste zulässige Anfrage. Hinweise in der Oberfläche ersetzen diese serverseitige Prüfung nicht. Limits werden geprüft, bevor kostenpflichtige Arbeit beginnt. Überschreitet eine Anfrage ihre aktuelle Grenze, bleibt die Eingabe erhalten. Contextter startet keinen kostenpflichtigen Lauf und reserviert kein Guthaben. Nicht jede Definition ist bearbeitbar: Werte, die nur bei der Bereitstellung gesetzt werden, sowie Diagnosewerte bleiben fest. Definitionen ohne nachgewiesene Anwendung im Produkt bleiben schreibgeschützt.
Support-Antworten bleiben im ursprünglichen E-Mail-Verlauf
Jede Fehler- oder Hilfeanfrage erhält eine Ticketreferenz, die mit einem E-Mail-Verlauf verbunden ist. Wenn das Contextter-Team antwortet, verwendet die Nachricht den bestehenden Verlauf und die üblichen Antwort-Header. Einzelne Nachrichten müssen dadurch nicht von Hand einander zugeordnet werden. Eine Kundenantwort wird nur zugeordnet, wenn entweder der E-Mail-Verlauf oder die Ticketreferenz passt und außerdem der Absender verifiziert werden kann. Eine verifizierte Antwort öffnet ein gelöstes Ticket wieder und setzt es auf „Antwort nötig“. Doppelte Nachrichten werden ignoriert. Das Team muss ein gelöstes Ticket bewusst wieder öffnen, bevor es eine weitere Antwort senden kann.
Wettbewerber-Kennzahlen aktualisieren sich nach gespeicherten SERP-Läufen
Gemeinsame Keywords, abgedecktes Volumen, durchschnittliche Position und Keyword-Gap änderten sich früher nur, wenn jemand in der Wettbewerber-Ansicht „Neu berechnen“ wählte. Jetzt werden sie automatisch aktualisiert, sobald ein Tracking-Lauf oder ein SERP-Lauf der Keyword-Datenbank neue Ergebnisse speichert. Die Berechnung verwendet die gespeicherten Daten des Workspaces. Sie löst keine weitere kostenpflichtige Anfrage aus und reserviert kein Guthaben. Eine neu in den Katalog aufgenommene Domain muss weiterhin in gespeicherten SERP-Ergebnissen erscheinen, bevor diese Kennzahlen existieren. Bis ein Lauf sie erfasst, zeigen die vier Kennzahlenfelder einen Strich und erklären, warum kein Wert vorliegt. Ein Zahlenwert von null steht damit für ein gemessenes Ergebnis und nicht mehr für fehlende Daten.
Deep-Recherche hat jetzt ein größeres Ergebnisbudget als Quick
Am 27. Juli konnte ein Deep-Lauf aus denselben Startbegriffen weniger nutzbare Keywords liefern als ein Quick-Lauf. Seine Erweiterung war enger, und einige Vorschläge kamen ohne die für einen Import benötigten Kennzahlen an. Mit dieser Änderung erhielt Deep mehr Quellen, begrenzte Folgerunden und eine Kennzahlenprüfung für die stärksten Kandidaten. Seitdem wurde die Zusammenstellung weiter verfeinert. Deep verfügt derzeit über ein größeres Quellen- und Ergebnisbudget als Quick, mit höchstens 2.000 deduplizierten Zeilen gegenüber 600 bei Quick. Das sind Obergrenzen, keine zugesagten Ergebnismengen. Die tatsächliche Abdeckung hängt von den verfügbaren Daten ab. Eine Zeile ohne Kennzahlen bleibt sichtbar, lässt sich aber nicht importieren. Die Schätzung vor dem Start berücksichtigt die ausgewählten kostenpflichtigen Schritte.
Match-Modi der Keyword-Recherche zeigen auch selektive Treffer
Beim Wechsel eines Recherchelaufs zu Phrase, Broad, Exakt, Verwandt oder Fragen wurden früher nur die Zeilen gefiltert, die zufällig im ersten Ergebnisfenster lagen. Ein gültiger Treffer weiter hinten im Lauf blieb unsichtbar, bis jemand mehrfach auf „Mehr laden“ klickte. Dadurch sah ein gefüllter Lauf leer aus. Match-Modi suchen jetzt weiter in den Lauf hinein, sodass auch selektive Treffer auf der ersten Seite erscheinen können. Bei großen Läufen bleibt das Suchfenster begrenzt. Die Workbench fordert außerdem den nächsten Block an, solange ein gefiltertes Ergebnis noch nicht vollständig ist. Die Filterleiste zeigt, wie viele Kandidaten zum aktiven Modus passen. Der Leerzustand unterscheidet drei Fälle: Die Suche läuft noch, bisher wurde kein Treffer gefunden oder alle verfügbaren Kandidaten wurden geprüft.
Position Tracking zeigt laufende Messungen und rettet festgefahrene Läufe
Eine laufende Messung sieht nicht mehr wie ein fehlgeschlagener Lauf aus. Laufprotokoll, Qualitätsdiagramm und ein Live-Band auf der Position-Tracking-Seite aktualisieren sich, während Ergebnisse eintreffen, zum Beispiel mit „2 von 4 geladen“. Fehlende Ergebnisse werden erst gezählt, wenn der Lauf einen Endzustand erreicht hat. Vorher zeigt die Oberfläche die Abdeckung, statt aus unfertiger Arbeit einen abgeschlossenen roten Balken zu zeichnen. Ein Klick auf „Jetzt ausführen“ ersetzt keine gesunde aktive Messung. Startet der Klick keinen Lauf, nennt die Antwort den Grund: Eine andere Messung läuft, der Tracker ist nicht aktiv, das EUR-Guthaben reicht nicht aus oder das Monatsbudget ist erreicht. Die Oberfläche bestätigt keinen Start mehr, wenn kein Lauf angelegt wurde. SERP-Tracker bieten zusätzlich eine eigene schnelle Aktion. Sie schickt genau diese manuelle Messung in die Priority-Warteschlange und zeigt vor dem Klick die geschätzten EUR-Kosten. Geplante Messungen behalten ihre Standardwarteschlange und ihren Standardpreis. Ein Tracker für Desktop und Mobile startet beide Geräteläufe als gemeinsame Gruppe. Das Live-Band fasst ihre Abdeckung zusammen, statt zwei voneinander getrennte halbe Läufe anzuzeigen. Wenn die Verarbeitung stoppt, nachdem Suchergebnisabfragen bereits bezahlt wurden, bleibt der Lauf nicht unbegrenzt liegen. Die Wiederherstellung verwendet die registrierten Abfragen erneut, holt inzwischen verfügbare Ergebnisse ab und schreibt sie über denselben Abrechnungsweg pro Keyword wie der ursprüngliche Lauf. Ergebnisse werden weder neu bestellt noch ein zweites Mal berechnet. Ein vollständig geretteter Lauf endet erfolgreich. Unvollständige Belege bleiben teilweise, und ein nicht wiederherstellbarer Lauf endet mit einem genannten Grund als fehlgeschlagen, statt für immer aktiv zu erscheinen.
Interne Verlinkung wird als Handlungssignal bewertet
Die frühere Kachel zur internen Verlinkung begann mit einem durchschnittlichen Perzentilwert, der konstruktionsbedingt immer 50 betrug, und zwei Korrelationskoeffizienten. Diese Zahlen beschrieben die Berechnung, beantworteten aber nicht, ob die Linkstruktur der Website verbessert werden sollte. Die Kachel zeigt jetzt einen Score von 0 bis 100 und eines von vier Urteilen: Stark, Solide, Ausbaufähig oder Schwach. Ein kurzer Satz erklärt den Zustand, der nächste nennt den schwächsten Teil, an dem gearbeitet werden sollte. Drei bewertete Aspekte machen die Herleitung sichtbar: ob wichtige Seiten in sinnvoller Klicktiefe erreichbar sind, ob sich interne Autorität weder zu flach noch zu stark konzentriert verteilt und ob die Dichte interner Links der Hierarchie folgt. Die Rohwerte für Korrelation und Konzentration bleiben im Methoden-Tooltip verfügbar.
Rechtliche Seiten passen zur Website und schließen Textlücken
Datenschutz, AGB, Cookies und Impressum verwenden jetzt dieselbe Navigation, Marke und Fußzeile wie die übrige öffentliche Website. Das Leselayout ergänzt klare Abschnittsgrenzen, begrenzte Zeilenlängen und Tabellen, die auch auf einem Smartphone bedienbar bleiben. Eine Dokumentnavigation verbindet die vier Seiten direkt miteinander und behält die ausgewählte Sprache bei. Das Impressum nennt den aktuellen Betreiber mit Postanschrift, Umsatzsteuer-Identifikationsnummer und Kontaktadresse. Es unterscheidet diesen Betreiber außerdem von der Contextter UG (haftungsbeschränkt) i. G., die sich weiterhin in Gründung befindet, und ersetzt den vor dieser Änderung verwendeten veralteten Verweis zum Medienrecht. Gleichzeitig wurden mehrere Lücken in den Rechtstexten geschlossen. Die AGB erklären EUR-Guthaben aus Plänen, Aufladungen und Testguthaben, statt leere Listeneinträge auszugeben. In der Datenschutzerklärung stehen die verantwortliche Stelle, die ausgewiesene Rechtsgrundlage für jede Verarbeitungskategorie und das Beschwerderecht bei einer Aufsichtsbehörde. Die Cookie-Richtlinie trennt Cookies und Produktanalytik der angemeldeten Anwendung von der öffentlichen Website und dem Help Center. Deren Standardmessung verwendet keine Analytik-Cookies. Die deutschen, französischen und spanischen Fassungen enthalten dieselben Abschnitte, statt auf unvollständige englische Fragmente zurückzufallen.
Lokalisierte Preistexte und vorgerenderte Marketingseiten
Plannamen, Beschreibungen, Leistungslisten und Handlungsaufforderungen auf der Preisseite verwenden jetzt den ausgewählten deutschen, französischen oder spanischen Katalog, statt unbemerkt auf Englisch zurückzufallen. Preise und Planlimits stammen weiterhin aus der gemeinsamen Plankonfiguration. Die Übersetzung ändert damit die Erklärung und erzeugt keine zweite Quelle für Preisangaben. Die meisten Marketingrouten werden wieder vorgerendert. Sie warten nicht mehr auf Anfragedaten, die sie gar nicht verwenden. Das entfernt unnötige Serverarbeit bei jedem Aufruf. Blog und Glossar bleiben dort dynamisch, wo Vorschau und Filterung aktuelle Daten erfordern.
Site Audit erklärt Aufbewahrung und die Zählung von Crawl-Kontingenten
Der Crawl-Verlauf in Site Audit besitzt jetzt einen ausdrücklichen Lebenszyklus. Aktuelle Läufe und mindestens die zehn neuesten beendeten Läufe behalten ihre Belege auf Seitenebene für Vergleiche und die Prüfung von Korrekturen. Bevor ein älterer Lauf verdichtet wird, kündigt Contextter sein Ablaufdatum an. Die Verdichtung entfernt umfangreiche Seitendetails, erhält aber die Zusammenfassung sowie die Belege für Zustandsverlauf und Trenddiagramme. Aktive Vergleiche oder Exporte verschieben diese Bereinigung. Nach ungefähr sechs Monaten bleibt pro Kalendermonat ein abgeschlossener Lauf als verdichteter Langzeitanker erhalten. Gibt es in einem Monat keinen abgeschlossenen Lauf, kann der jüngste Teillauf diese Rolle übernehmen. Andere Läufe aus demselben Zeitraum können entfernt werden. Nach zwölf Monaten werden Läufe gelöscht, ausgenommen das neueste beendete Ergebnis einer Website. Bis zu fünf Läufe pro Website lassen sich gegen eine frühere Verdichtung anheften. Eine solche Markierung überschreibt jedoch nicht die Zwölfmonatsgrenze. Für eine archivierte Website gilt eine Wiederherstellungsfrist von sieben Tagen, bevor ihr Audit-Verlauf entfernt wird. Crawl-Kontingente sind von URL-Limits getrennt. Die aktuellen Standardwerte der Pläne liegen bei fünfzehn vollständigen Crawls und zehn Prüfläufen pro Organisation und Kalendermonat. Die wirksamen Werte können abweichen, wenn Plan- oder Administrationslimits geändert wurden. Der Startdialog zeigt das geltende Kontingent, verbleibende Läufe und das Rücksetzdatum. Für jeden Crawl gilt weiterhin die URL-Obergrenze seines Plans. Aktive und abgeschlossene vollständige Crawls verbrauchen einen Platz im Kontingent. Abgebrochene, fehlgeschlagene oder nur teilweise abgeschlossene Läufe mit weniger als zehn fertig verarbeiteten Seiten tun dies nicht. Auch ein wegen unzureichenden EUR-Guthabens übersprungener Lauf ist nie gestartet und wird nicht gezählt. So verbraucht ein gescheiterter Start nicht dieselbe Kapazität wie ein Crawl, der die Website tatsächlich verarbeitet hat.
Breadcrumbs machen öffentliche Seitenpfade sichtbar
Öffentliche Produkt-, Lösungs-, Tool-, Rechts-, Blog- und Glossarseiten zeigen jetzt, wo sie innerhalb der Website liegen. Der Breadcrumb führt von der Startseite über den passenden Bereich zur aktuellen Seite. Jede Zwischenstufe ist verlinkt. Zusammengehörige Themen behalten ihren Produktkontext: Keyword-Recherche und Position Tracking liegen unter der Keyword-Datenbank, technische Berichte unter Site Audit. Dieselbe Hierarchie wird als strukturierte BreadcrumbList ausgegeben. Suchmaschinen können damit die Beziehung zwischen den Seiten verstehen und den Pfad in einem Suchergebnis darstellen. Ob und wie er dort erscheint, entscheidet weiterhin die Suchmaschine.
Eine Kontaktadresse auf der gesamten öffentlichen Website
Öffentliche Kontaktlinks führen jetzt zu info@contextter.com. Das gilt für Unternehmens- und Rechtsseiten, Datenschutzhinweise, strukturierte Unternehmensdaten, Kontaktformulare, Rückfalladressen für Kündigung und Widerruf sowie Fehlermeldungen des Newsletters. Alle genannten Bereiche verwenden damit dieselbe Adresse.
Domain Overview ordnet Ranking-Bewegungen ein
Domain Overview zeigt die Ranking-Verteilung jetzt als gestapelten Verlauf. Das Diagramm verfolgt dieselbe Domain durch die Top 3, die Positionen 4 bis 10, 11 bis 20, 21 bis 50 und 51 bis 100. Seine obere Kante entspricht der Gesamtzahl rankender Keywords. Dadurch lässt sich ein bloß wachsender Keyword-Bestand von einer tatsächlichen Verschiebung in bessere Positionen unterscheiden. Die Suchintention wird über den gespeicherten Bestand rankender Keywords berechnet und nicht nur über die gerade geladene Tabellenseite. Für jede Intention erscheinen Anteil, Keyword-Zahl und geschätzter Traffic. Wettbewerber liegen auf einer logarithmischen Karte mit rankenden Keywords auf einer Achse und geschätztem Traffic auf der anderen. Die Blasengröße zeigt die Zahl gemeinsamer Keywords. Quellenkontext bleibt im Hintergrund, solange ein Bereich nicht tatsächlich einen anderen Datenstand als das aktuelle Domainprofil verwendet.
Das Action Center gruppiert interne Linkvorschläge nach Zielseite
Empfehlungen für interne Links wurden zu einem Eintrag pro Zielseite. Zuvor erzeugte jeder gespeicherte Linkvorschlag eine weitere Zeile. Dieselbe Seite konnte dadurch mehrfach in der empfohlenen Reihenfolge erscheinen. Der gruppierte Eintrag sammelte nun die Vorschläge für dieses Ziel. Die Zahl neben dem Eintrag wurde zur Anzahl der gebündelten Linkvorschläge. Ein interner Qualitätsscore erschien nicht mehr unter einer Beschriftung wie „69 konkrete Linkempfehlungen“. Auch die speicherbezogene Systemformulierung wurde durch eine überprüfbare Entscheidung ersetzt. Eine erfasste Position 9 führte beispielsweise zur Prüfung von Ranking-Seite, Suchergebnis, Suchintention und vorhandenen Onpage-Belegen, bevor eine Optimierung gewählt wurde. Sie galt nicht länger als Beweis dafür, dass die Seite steigen würde. Der Seitentitel erschien außerdem nur einmal.
Workspace Home ergänzt eine visuelle Ranking-Zusammenfassung
Die Karte **Your rankings** zeichnete nun die Durchschnittsposition beobachteter Keywords im Zeitverlauf und teilte die zuletzt erfassten Positionen in die Bereiche Top 3, Top 10, Top 20 und Top 100. Die Richtung des Diagramms machte Verbesserung und Rückgang sichtbar, ohne die zugrunde liegenden Positionswerte zu verändern. Eine kurze Fußzeile nannte den Gegenstand der Messung, die Häufigkeit des Zeitplans und den letzten abgeschlossenen Lauf. Die Karte ersetzte zwei reine Textbereiche. Auch der Keyword-Verlauf benannte sein Thema: **Visibility of your domain**. Die Reihen Keywords, Traffic und Top 10 beschrieben Domain-Belege zur organischen Sichtbarkeit und nicht die ausgewählte Liste oder den getrennt beobachteten Keyword-Bestand. Der Activity Feed verließ die Hauptfläche, blieb aber über eine kompakte Karte mit einem Klick erreichbar. Das vollständige Protokoll blieb auf Activity. Die Hilfe auf Workspace Home folgte dem geänderten Aufbau.
Domain Overview ergänzt Steuerungen für geladene Belege
Domain Overview erlaubte nun, geladene Wettbewerber, rankende Keywords, Top Pages, Anchors, verweisende Domains und verlinkte Seiten zu durchsuchen und zu sortieren, ohne eine weitere bezahlte Analyse zu starten. Positionsgruppen filterten den Keyword-Beleg direkt. Wettbewerberzeile und Traffic-Vergleich hoben dieselbe ausgewählte Domain hervor. Die Wachstumsdiagramme verwendeten ein gemeinsames Zeitfenster von 6, 12, 24 oder 60 Monaten. Aktive Steuerungen blieben in der Seiten-URL. Eine fokussierte Ansicht überstand dadurch das Neuladen und ließ sich teilen. Jeder Ergebniszähler sagte, dass er sich auf geladene Belege bezog. Ein teilweiser Snapshot oder ein seitenweise geladenes Ergebnis blieb damit erkennbar.
Keyword Research schließt Läufe mit abgelaufener EUR-Balance-Reservierung
Keyword Research schloss einen Lauf mit abgelaufener EUR-Balance-Reservierung nun über denselben sichtbaren Fehlerweg wie ein Verarbeitungs- oder Übergabefehler. Die ungenutzte Reservierung wurde freigegeben. Der Lauf erhielt einen Support-Code und einen Activity-Eintrag. Eine weitere Recherche konnte beginnen, ohne dass veraltete Kapazität aus dem früheren Lauf im Weg blieb. Timeouts, inaktive Reservierungen, stillstehende Verarbeitung, Abbrüche und autorisierte Wiederherstellung behielten unterschiedliche Diagnosecodes, statt in einem allgemeinen internen Fehler zusammenzufallen. Kunden sahen die stabile Erklärung und den Support-Code. Operative Details blieben autorisierten Betreibern vorbehalten.
Site Audit veröffentlicht gespeicherte Linkbelege mit sichtbarem Fortschritt
Site Audit bewertete kontextuelle interne Links und wiederholte Linktexte nun aus dem gespeicherten Linkgraphen statt aus einer festen Stichprobe der ersten Seite. Große Crawls behielten dadurch auch nach den ersten 1.000 passenden Links weitere Findings, wenn der gespeicherte Graph für die jeweilige Regel vollständig war. Die Fortschrittsanzeige reservierte eine gemessene Phase für die abschließende Veröffentlichung und benannte die laufende Arbeit, etwa Linkmetriken, Issue-Zusammenfassungen, Aggregate oder den Health Score. Sie wechselte nicht zu 99 Prozent, bevor diese Berichtsarbeit begonnen hatte. Audits erkannten außerdem identischen Title- und H1-Text, externe Nofollow-Links und unbenannte externe Links als Prüfsignale. Gültige dekorative Bilder, zugängliche Bildlinks, beabsichtigte Ressourcenlinks und eine fehlende **llms.txt** blieben außerhalb der Defektzahl. Leere Bildalternativen wurden sichtbar, ohne mit einem fehlenden Attribut verwechselt zu werden. Das Audit unterschied wahrscheinliche Inhaltsbilder von ausdrücklich dekorativem Markup und hielt beide bis zur Prüfung aus dem Health Score heraus. Issue-Exporte zeigten bekannte Kategorien, Belegquellen und Ziel-URLs doppelter Linktexte statt allgemeiner Bezeichnungen. Wiederholte Template-Muster verwendeten eine kurze repräsentative URL-Auswahl.
Site Audit prüft strukturierte Daten und zeigt gemessene Performance
Site Audit prüfte JSON-LD, Microdata und RDFa nun über die Syntax hinaus. Die Prüfung umfasste Schema.org-Typen und Eigenschaften, grundlegende Wertformate, veraltetes Vokabular und bei unterstützten Google-Ergebnistypen den Unterschied zwischen Pflichtfeldern und Empfehlungen. Die Übersicht trennte saubere, zu prüfende, blockierte und nicht ausgezeichnete URLs, gruppierte wiederholte Template-Probleme nach Ursache und behielt den Beleg auf Elementebene. Verlauf und URL-Filter machten einen Typ oder Ergebnistyp über mehrere Crawls nachvollziehbar, ohne eine Stichprobe als vollständige Abdeckung auszugeben. Die Performance-Auswertung hielt Crawl-Antwortzeit, Labormessungen und verfügbare Felddaten getrennt. Jeder Lauf zeigte, wie viele geeignete URLs geplant, gemessen oder fehlgeschlagen waren. Fehlende CrUX-Daten blieben nicht verfügbar. Eine langsame Lighthouse-Messung konnte die Performance-Abdeckung verringern, aber keinen abgeschlossenen Crawl zum Fehlschlag machen. Messprofile wurden versioniert, unterbrochene Arbeit konnte fortgesetzt werden und Teilabdeckung blieb in Exporten und Vergleichen erkennbar.
Action Center zeigt jeweils eine Empfehlung
Das Action Center wurde um eine praktische Frage neu geordnet: Was sollte als Nächstes geprüft werden? Statt mit einem dichten mehrspaltigen Dashboard zu beginnen, zeigte es eine Empfehlung mit verständlichem Titel, dem Grund für ihre aktuelle Position und den drei Hauptkennzahlen dahinter. Von dieser Karte aus ließ sich die Empfehlung starten, für später speichern oder als nicht relevant markieren. Die letzte Auswahl wurde zu einem ausdrücklichen Signal über die Geschäftsrelevanz, statt den gemeinsamen Leitfaden unbemerkt zu verändern. Schrittweise Anleitung, unterstützende Belege, Ranking-Machbarkeit und optionale Datenanreicherung blieben in der Detailansicht erreichbar. Eine gruppierte Liste hielt den breiteren Leitfaden in den Bereichen **Now**, **Up next** und **Watch** verfügbar. Begonnene Aufgaben blieben ebenfalls erreichbar. Wenn der Nutzer die aktuelle Auswahl geprüft hatte, beschrieb „done for today“ den Zustand dieser Prüfliste, nicht die Gesundheit oder Vollständigkeit der Website.
Competitive Research hält bezahlte Vergleiche wiederherstellbar
Competitive Research verwendete denselben Vergleich erneut, wenn eine Browser- oder Netzwerkwiederholung die Anfrage ein zweites Mal sendete. Die Guthabenreservierung blieb mit diesem Vorgang verbunden. Eine unterbrochene Übergabe ließ sich dadurch fortsetzen, ohne einen zweiten kostenpflichtigen Lauf anzulegen. Vollständige Wettbewerbsanalysen veröffentlichten jeweils eine abgeschlossene Ranking-Generation. Scheiterten Quellenabruf, Score-Berechnung oder Abschluss, blieben die letzten erfolgreichen Daten sichtbar und ungenutzte Reservierungen wurden freigegeben. Ein teilweise geschriebenes Ergebnis ersetzte keinen brauchbaren Vergleich. Vergleichsberichte unterschieden je Domain zwischen laufenden, teilweisen, fehlgeschlagenen, leeren, begrenzten und verfügbaren Modulen. Abdeckung, Aktualität, geltende Grenzen und Support-Codes blieben sichtbar. Der Bericht ergänzte Entscheidungshinweise, bei Bedarf geladene Detaildossiers, stabile teilbare URLs, eine seitenweise Historie und einen CSV-Export, der fehlende Daten nicht in Nullen verwandelte. Quick-Vergleiche kennzeichneten die Module, für die eine Deep-Analyse nötig war, und boten eine vorausgefüllte Erweiterung an. Starteten Quick und Deep kurz nacheinander, verwendeten sie dieselben laufenden Übersichtsdaten, statt diese zweimal zu reservieren und abzurufen. Deep-Vergleiche führten bereits gekaufte Keyword-Gap-Belege über die ausgewählten Wettbewerber zusammen. Die begrenzte Übersicht priorisierte Lücken, die mehrere Domains teilten, hielt nicht verfügbare Kennzahlen als unbekannt sichtbar und legte Stichproben offen. Einzelne oder gruppierte Chancen ließen sich ohne neuen Quellenabruf an Keyword Research übergeben.
Workspace Home zeigt gemessene Werte statt Einrichtungshinweisen
Durchschnittsposition und Chancen auf Workspace Home verwendeten nun die im Workspace erfassten Belege. Die Durchschnittsposition las den aktiven Rank Tracker auch dann, wenn er manuell ausgewählte Keywords beobachtete. Die Zahl der Chancen verwendete dieselbe workspaceweite Auswertung wie das Action Center. Eine gemessene Null erschien als Null und nicht als Aufforderung, einen bereits laufenden Bereich einzurichten. Jeder Punkt im Keyword-Verlauf erhielt eine größere Hover-Fläche. Sein Tooltip blieb innerhalb der sichtbaren Karte. Eine Legende benannte beide Linien, wenn die Top-10-Ansicht zusätzlich die Top-3-Serie zeigte. Das Diagramm erzeugte keinen eigenen kleinen Scrollbereich mehr in der Karte. Das Tracking-Panel ergänzte neben der Keyword-Zahl einen kompakten Verlauf der Durchschnittsposition des primären Zeitplans. Sobald alle Einrichtungsschritte abgeschlossen waren, reduzierte sich die Checkliste auf eine Bestätigungszeile. Die Wettbewerberkarte erklärte einen leeren Marker als „noch nicht gemessen“, statt wie ein defektes Ergebnis auszusehen. Neue Workspaces sahen in diesem Release außerdem, was ihr verfügbares Startguthaben abdeckte und wo sie Guthaben hinzufügen konnten.
Domain-Analysen trennen fehlende Daten von einem leeren Ergebnis
Domain-Analysen nannten nun die Richtung jeder Keyword-Lücke: Die erste Domain rankte, die Vergleichsdomain nicht. Bei der Analyse eines Wettbewerbers wurde die im Workspace beobachtete Domain zum voreingestellten Vergleich. Eine Analyse der eigenen Domain bot die beobachteten Wettbewerber an und wählte den einzigen automatisch, wenn keine echte Entscheidung nötig war. Jeder Datenbereich behielt seinen eigenen Abrufzustand und seine Abdeckung. Eine fehlgeschlagene Quellenanfrage erschien als fehlender Beleg und nicht als echtes Nullergebnis. Begrenzte Stichproben zeigten die Zahl geladener Zeilen im Verhältnis zur gemeldeten Gesamtzahl. Analysezeit und Quellenaktualität blieben getrennt, wenn eine Aktualitätsangabe vorhanden war. Ein neuer Lauf aus einem gespeicherten Snapshot übernahm Markt, Sprache, Keyword-Umfang und Vergleichsdomain. Bereits gekaufte Felder blieben vollständiger erhalten. Dazu gehörten gemeinsame und vollständige Wettbewerberkennzahlen, organische Werte auf Seitenebene, Zielseiten und Traffic aus Keyword-Lücken, Spam- und Crawl-Fakten zu Backlinks sowie die Zahl indexierter Seiten. Die Historie kennzeichnete abgeschlossene, teilweise, laufende und fehlgeschlagene Versuche direkt. Sie öffnete das neueste brauchbare Ergebnis, statt es durch einen jüngeren fehlgeschlagenen Lauf zu verdecken. Beim Wiederherstellen älterer Keyword-, Wettbewerber-, Seiten- und Linkzeilen erschien ein Ladezustand.
Ein Problem direkt auf der betroffenen Seite melden
Angemeldete Nutzer konnten einen Fehler oder Hilfebedarf über den gemeinsamen Seitenkopf der wichtigsten Workspace-Seiten melden. Der Entwurf enthielt bereits Konto, Workspace, Seite und aktiven Berichtsbereich. Der Nutzer musste nur noch beschreiben, was passiert war. Die Beschreibung blieb erhalten, wenn das Senden scheiterte. Das Schließen eines Berichts mit ungesendetem Text verlangte eine Bestätigung. Eine erfolgreiche Übermittlung erzeugte genau einen Bericht zur weiteren Bearbeitung. Zeigte eine Fehleransicht einen Support-Code, bot sie dieselbe Meldeaktion an und übernahm den Code in den Entwurf. Der Nutzer konnte die unterbrochene Aufgabe beschreiben, ohne Diagnosedaten von Hand zu kopieren.
Keyword Research macht unterbrochene Läufe wiederherstellbar
Keyword Research unterschied nun zwischen Übergabe, Warten, aktiver Verarbeitung und Abschluss, statt einen unbestimmten laufenden Zustand zu zeigen. Ein nicht rechtzeitig übernommener oder nicht mehr antwortender Lauf wurde beendet und gab seine ungenutzte Guthabenreservierung frei. Ein aktiver Lauf ließ sich außerdem direkt abbrechen. Wiederholte Browser- oder Netzwerkanfragen verwendeten denselben Recherchevorgang, statt eine weitere Reservierung anzulegen. Große mehrteilige Importe behielten eine Zielliste und setzten nach dem zuletzt bestätigten Teil fort. Gefilterte Ergebnisse suchten innerhalb einer festen Grenze voraus, damit spätere Treffer nicht hinter einer leeren Seite verborgen blieben. Fehler für Kunden verwendeten stabile lokalisierte Erklärungen und einen Support-Code, statt Quellen- oder Ausführungsdetails offenzulegen. Autorisierte Betreiber behielten die für die Nachverfolgung nötigen Diagnosen. Ergebnisse nutzten vorhandene Keyword- und Suchergebnisbelege erneut, wenn sie verfügbar waren: gespeicherte SERP Features und Top-Ergebnisse, Suchtrends, verwandte Oberthemen, eine klar gekennzeichnete Traffic-Schätzung und eine Schwierigkeit relativ zur Domain. Sortierung und seitenweise Historie blieben auch bei größeren Ergebnismengen nutzbar. Fehlende oder teilweise Belege blieben als unbekannt sichtbar. Gespeicherte Recherche ließ sich gefiltert und sortiert als CSV exportieren. Jedes Ergebnis zeigte seine Quelle und, soweit vorhanden, den Seed-Begriff, aus dem es entstanden war. Ein früherer Lauf konnte eine neue Anfrage aus der Historie vorausfüllen. Der aktuelle Preis blieb sichtbar, und der neue Abruf begann erst nach der Bestätigung.
Domain-Profile behalten den neuesten brauchbaren Beleg
Domain Overview verwendete nun ein persistentes Profil. Eine neue Analyse ergänzte die vorhandenen Belege, während ein vorübergehender Quellenfehler einen älteren erfolgreichen Stand nicht verdrängte. Jeder Quellenstand blieb als datierter Snapshot nachvollziehbar. Ein gefundener Wettbewerber ließ sich direkt in eine neue Keyword-Gap-Analyse übernehmen. Wettbewerber und eigene Workspace-Domain waren in ihren richtigen Rollen vorausgefüllt. Preisvorschau und ausdrückliche Bestätigung blieben vor dem kostenpflichtigen Abruf.
Position Tracking hält Markt- und Gerätekontexte getrennt
Position Tracking hielt Desktop, Mobilgerät, Land und Sprache nun in gespeicherten Ergebnissen, Historie, Vergleichen und Exporten getrennt. Markt und Sprache ließen sich bei der Einrichtung auswählen, statt einen festen Standard unbemerkt zu verwenden. Die Berichtsnavigation blieb stabil, wenn der Nutzer zwischen Berichten und Tracking-Jobs wechselte. Der Cannibalization-Bericht blieb unter Jobs erreichbar. Sein Leerzustand erklärte, wenn die erfassten Suchergebnisse keinen gleichzeitigen Konflikt zwischen mehreren eigenen URLs enthielten. Der Rankings-Bericht ergänzte Tags und Schnellfilter für Top 3, Gewinner, Verlierer und nicht rankende Keywords. Die Filter liefen vor der serverseitigen Seitenteilung, blieben in der Seiten-URL erhalten und galten für denselben CSV-Export. Werte, die Tabellenprogramme als Formeln interpretieren könnten, wurden im Export neutralisiert. Das Positionsdiagramm trennte Verbesserungen, Rückgänge, neue Rankings, Verluste und unveränderte Keywords. Pages zeigte die Zielseiten mit dem größten Beitrag zum geschätzten Traffic. Jobs machte Laufabdeckung und fehlende Daten im Zeitverlauf sichtbar. SERP Features unterschied Auftritte des Workspace, Auftritte von Wettbewerbern und Ergebnisse ohne verlässliche Zuordnung. Die Zuordnung eines SERP Features unterschied „nicht im Besitz“ von einem Ergebnis ohne verlässliche Attribution. Mehrere eigene URLs galten nur dann als Kannibalisierung, wenn sie im selben gemessenen Suchergebnis auftauchten. Ein URL-Wechsel zwischen Tagen und ältere Historie ohne Gleichzeitigkeit blieben getrennte Veränderungen. Ein Lauf über mehrere Geräte wurde als Gruppe abgerechnet. Unmögliche Fortschrittswerte wurden abgelehnt. Die Wiederherstellung veralteter Läufe beendete verwaiste Arbeit und gab ungenutzte Reservierungen frei. Erforderliche Suchergebnisaktualisierungen und Ranking-Historie wurden gemeinsam gespeichert, sodass kein Erfolgszustand erschien, wenn ein Teil der Historie fehlte.
Site Audit wendet die Grenze von 5.000 Seiten einheitlich an
Site Audit wendete die Grenze von 5.000 Seiten nun einheitlich an, wenn eine Domain, ein Crawl oder ein wiederkehrendes Audit eingerichtet wurde. Ältere gespeicherte Einstellungen mit einem höheren Wert wurden für künftige Crawls reduziert. Historische Crawl- und Abrechnungsdaten blieben unverändert. Große Ergebnisse zeigten ihren Vorbereitungszustand genauer. Ein Ergebnis erschien nicht vollständig, solange einer erforderlichen Zusammenfassung noch bewertbare Seiten fehlten. Seitendetails luden Belege für den aktiven Abschnitt, behielten einen direkt verlinkten älteren Crawl ausgewählt und erklärten, wenn dessen Detailbelege abgelaufen waren, die Zusammenfassung aber noch vorlag. URL-Details blieben im selben Site-Audit-Rahmen wie Pages. Die ausgewählte URL stand im Breadcrumb statt in einem zweiten Seitenkopf. Für künftige Crawls ist das aktuelle Produktlimit maßgeblich.
Site-Audit-Vergleiche verwenden klare Crawl-Namen und gleiche Einheiten
Jeder Site-Audit-Crawl erhielt einen Namen mit vollständigem Datum, Uhrzeit, Jahr und seiner chronologischen Run-Nummer des Tages. Mehrere Crawls vom selben Tag ließen sich dadurch auswählen, ohne ihre URL- oder Issue-Zahlen als Ersatz zu verwenden. Crawls aus verschiedenen Jahren blieben unterscheidbar. Compare hielt den früheren und späteren Crawl in chronologischer Reihenfolge, lud die verfügbaren Issue-Gruppen und setzte das Paar nach einem Wechsel der Domain zurück. Die Summen unterschieden Issue-Vorkommen von betroffenen URL-Instanzen. Eine Zunahme und eine Abnahme verwendeten dadurch dieselbe Einheit. Das Öffnen einer Vergleichszeile wechselte zu einem Crawl, in dem das Issue vorhanden war. Compare konnte ältere Crawl-Seiten direkt laden, auch wenn der Lauf nicht zu den neuesten 20 Einträgen gehörte. Die Ansicht wartete außerdem auf die veröffentlichten Ergebnisse eines Laufs und ordnete Veränderungen der Schweregrade in beiden Crawls der richtigen Kategorie zu.
Site Audit trennt einen verzögerten Start von einem fehlgeschlagenen Crawl
Site Audit unterschied nun einen verzögerten Verarbeitungsstart von einem fehlgeschlagenen Crawl. Ein angenommener Crawl blieb in der Warteschlange, versuchte den Start automatisch erneut und bot einen manuellen Versuch an, ohne einen zweiten Lauf anzulegen oder zu berechnen. Blieb die Verarbeitung verzögert, konnte der Hinweis einen vorausgefüllten Problembericht öffnen. Support-Code und Crawl-Kontext waren darin bereits enthalten.
Site Audit trennt bestätigte Defekte von Prüfsignalen
Site Audit trennte bestätigte Defekte nun deutlicher von Signalen, die noch geprüft werden mussten. Beschädigte Titel und Beschreibungen konnten als Defekt erscheinen. Zeichenlänge, wenig Text, statische render-blockierende Kandidaten und einfache Cache-Prüfungen blieben dagegen Hinweise, solange stärkere Belege fehlten. Absichtliche Formulare, Galerien, Downloads, Lightboxes und dekoratives `alt=""` wurden nicht allein wegen wenig Text oder vieler Bilder abgewertet. Wiederholte Anchor- und Ressourcenmuster wurden nach gemeinsamer Ursache gruppiert, Stichproben als Stichproben gekennzeichnet. Externe Ziele erhielten eine browsernahe Bestätigung, bevor sie als defekt galten. Authentifizierungs- oder Challenge-Seiten wurden nicht als Ersatz vorgeschlagen. Hinweise zu kontextuellen Links blieben auf Inhaltsseiten begrenzt und erschienen nur mit vollständigem Beleg. Der Fortschritt erreichte 100 Prozent erst, wenn Findings, Linkanalyse, Health Score und Reportbelege veröffentlicht waren.
Site Audit bindet Issue-Belege an den ausgewählten Crawl
Der Issues-Bereich von Site Audit band Katalog und Historie nun an den ausgewählten Crawl. Kategorien, Quellen, Arten betroffener Einheiten, Entwicklung eines Issues und behobene Issues stammten aus den veröffentlichten Audit-Daten. Sie wurden nicht aus der gerade im Browser geladenen Seite abgeleitet. Unvollständige und fehlgeschlagene Crawls sahen nicht mehr vollständig aus. Begrenzte Zahlen waren als Untergrenzen gekennzeichnet, fehlende Historie blieb sichtbar und das Nachladen weiterer URLs oder Assets behielt seinen Ladezustand, statt kurz ein leeres Ergebnis zu zeigen. Issue-Berichte trennten das Kopieren einer Umsetzungsanleitung vom Öffnen einer agentenfertigen Übergabe. Der Bericht behielt die vollständige Belegzahl des Laufs, auch wenn nur ein Teil der Detailliste geladen war. Er erklärte außerdem, wenn weitere Findings vorhanden sein konnten. Ein Fehler in einem Issues-Panel blieb innerhalb von Site Audit und bot einen erneuten Versuch für diesen Abschnitt. Der Abgleich schloss veraltete Issues, wenn ein frischer Crawl keinen passenden Befund mehr enthielt. Das galt auch für ältere Fälle außerhalb des früheren Verarbeitungsfensters.
Site Audit erklärt interne Linktiefe und Linkchancen
Site Audit berechnete die Klicktiefe nun als kürzesten internen Linkpfad von der Startseite. Overview und Statistics zeigten die Tiefenverteilung. Page Explorer konnte URLs nach Klicktiefe, Erreichbarkeit, eingehenden Links, ausgehenden Links und interner Autorität filtern und sortieren. Enthielten zwei Crawls kompatible Belege mit genauer Tiefe, zeigte Overview auch Veränderungen von Median, P90 und unerreichbaren Seiten. Der Health-Score-Ring hielt einen dreistelligen Wert lesbar. Internal Links lud eine große Website seitenweise, statt das vollständige URL-Inventar im Browser zu halten. Jede URL zeigte einen repräsentativen kürzesten Pfad, benannte Beziehungen und Vorkommen sowie eine Schätzung der relativen Autorität mit sichtbarer Grundlage. Auf dem Desktop blieben Internal Links und Page Explorer im verfügbaren Viewport. Lange URL- und Beziehungslisten scrollten in ihren eigenen Bereichen. Bei Audits innerhalb der Grenze von 5.000 Seiten prüften interne Linkchancen die geeignete URL-Menge, bevor eine begrenzte Maßnahmenliste veröffentlicht wurde. Bereits vorhandene Links, unsichere Ziele, unvollständige Graphbelege und schwache thematische Beziehungen blieben aus der Liste heraus. Jede Maßnahme trug getrennte Belege für Bedarf am Ziel, thematische Passung, Autorität der Quelle, mögliche Platzierung und Risiko. Priorisierte Maßnahmen blieben im Action Center, damit Prüfung und Abschluss denselben gemeinsamen Zustand verwendeten.
Statistiken erscheinen nach dem Crawling und Seitendetails behalten ihren Kontext
Crawl-Statistiken wurden nun veröffentlicht, sobald das Crawling abgeschlossen war. Sie mussten nicht auf spätere Prüfungen externer Links und Assets warten. Statistics konnte dadurch Response Health, Klicktiefe, Indexierbarkeit und Entdeckungsquellen zeigen, während diese Folgeprüfungen noch liefen. Das Öffnen einer Seite aus Pages behielt den Crawl-Kontext. Enthielt ein kopierter oder geteilter Link keinen solchen Kontext, ordnete Contextter ihn dem neuesten Crawl zu, in dem die Seite erfasst worden war. Die Seite wurde nicht mehr abgelehnt, nur weil der Nutzer zuvor keinen Lauf von Hand ausgewählt hatte. Die Detailansicht behielt den Site-Audit-Rahmen. Domain- und Crawl-Auswahl blieben verfügbar. Ein Wechsel des Crawls lud dieselbe Seite in diesem Lauf. Die anderen Site-Audit-Tabs waren erreichbar, ohne zuerst einen Zurück-Link zu verwenden. Seitendetails speicherten ausgewählten Tab, Linkrichtung, Filter, Asset-Bereich und Issue-Schwere in der URL. Previous und Next bewegten sich durch das geladene Pages-Ergebnis, ohne den ganzen Crawl in den Browser zu laden. Beim Prüfen einer verlinkten Seite gab es einen direkten Rückweg zu ihrer Quelle. Link- und Issue-Filter liefen vor der Seitenteilung, sodass Treffer hinter dem ersten geladenen Block erscheinen konnten. Eine nicht mehr vorhandene Seite oder ein nicht mehr verfügbarer Lauf zeigte eine wiederherstellbare Erklärung statt eines allgemeinen Fehlers.
Action-Center-Empfehlungen berücksichtigen bestätigte Geschäftsrelevanz
Das Action Center verwendete bestätigten Geschäftskontext nun gemeinsam mit Keyword-, Ranking-, Wettbewerber-, Domain-, Search-Console-, Site-Audit- und internen Linkbelegen. Themen außerhalb des Angebots wurden zurückgehalten, unsichere Zuordnungen erschienen als Fragen statt als sichere Anweisung. Difficulty, Suchintention, Seitenbereitschaft, Bewegung und die dokumentierte Stärke der Website beeinflussten Keyword-Empfehlungen. Fehlende Belege blieben als Datenbedarf sichtbar. Die fünf Entscheidungsziele erzeugten unterschiedliche Portfolios statt derselben Warteschlange in anderer Reihenfolge. Empfehlungen verlinkten ihren genauen Arbeitskontext, ließen sich mit editierbarer Priorität speichern und enthielten einen kostenlosen deterministischen Plan mit Umsetzungs- und Prüfschritten. Konnte ein fehlender bezahlter Datenpunkt mehrere Entscheidungen verändern, gruppierte Contextter die betroffenen Keywords in einem Vorschlag und zeigte Umfang sowie Preis vor der Bestätigung. Optionale KI-Vorschläge blieben von bestätigten Geschäftsfakten getrennt, bis der Nutzer sie annahm.
Site Audit wartet vor der Veröffentlichung auf die Crawl-Belege
Site Audit wartete nun auf vorgemerkte Seitenanalysen, bevor ein Crawl als abgeschlossen galt. Crawl-Übersicht, Issue-Gruppen, URL-Zahlen und Health Score wurden aus demselben abgeschlossenen Evidenzzustand veröffentlicht statt aus einem früheren Zwischenergebnis. Wurde die abschließende Veröffentlichung unterbrochen, setzte Contextter diesen Schritt fort, ohne die Website erneut zu crawlen. Die Wiederherstellung lief dosiert. Vorübergehende Schreiblimits erhielten begrenzte Wiederholungen. Eine unterbrochene Veröffentlichung blieb dadurch vom abgeschlossenen Crawl-Beleg getrennt, statt mehrere Berichtsneuaufbauten zu starten oder den Crawl selbst nachträglich als fehlgeschlagen zu speichern.
Workspace Home öffnet Position Tracking zuverlässig
Der Einstieg in Position Tracking über Workspace Home erreichte nun den Tracking-Arbeitsbereich, auch wenn Contextter einen Teil der Ansicht noch vorbereiten musste. Der Einrichtungslink zeigte währenddessen einen sichtbaren Ladezustand, statt vor dem Erscheinen der Tracking-Steuerung in einer Fehleransicht zu enden. Der heutige Zugriff hängt weiterhin von den im Workspace aktivierten Funktionen und Berechtigungen ab.
Site Audit trennt Befundbelege von wiederholten Symptomen
Site Audit erkannte gültige Alt-Texte, responsive Bilder, zugängliche Linkbeschriftungen, Navigation, Ressourcenhinweise und Downloads genauer. Wiederholte Ressourcenprobleme wurden nach dem betroffenen Asset gruppiert, statt für jede Quellseite vervielfacht zu werden. Der Bericht hielt Vorkommen weiterhin getrennt von eindeutig betroffenen URLs und Assets. Überschneidende Symptome konnten eine wahrscheinliche Ursache teilen, ohne als bewiesener Zusammenhang zu erscheinen. Externe Links erhielten eine browsernahe Bestätigung, bevor sie als defekt galten. Login-Schranken und instabile Zugriffssperren blieben nicht verifizierbar, Weiterleitungsprüfungen behielten bedeutungsvolle abschließende Slashes. Befunde zu kontextuellen Links erschienen nur mit vollständigen Body-Link-Belegen. Andernfalls nannte der Bericht die Teilabdeckung. Ein Crawl blieb außerdem in Verarbeitung, bis Findings und Health Score veröffentlicht waren. Exporte und Umsetzungshinweise konnten dadurch keine unfertige Projektion als abgeschlossenen Audit darstellen.
Site Audit trennt Website-Gesundheit von Crawl-Konfidenz
Site Audit berechnete Health nun aus den Seiten und Prüfungen, die im jeweiligen Crawl tatsächlich bewertbar waren. Viele Findings mit geringer Auswirkung drückten den Score nicht mehr auf eine künstliche Untergrenze. Fehlgeschlagene oder unvollständige Crawl-Arbeit erschien im Konfidenzzustand, statt die Website-Gesundheit zu verfälschen. Jeder veröffentlichte Score war als gemessen oder vorläufig gekennzeichnet. Reichten die vorhandenen Belege nicht aus, zeigte Contextter die Lücke, statt sie mit einer Zahl zu füllen. Die Übersicht nannte außerdem bestätigte Score-Begrenzungen, die schwächsten Kategorien und die wichtigsten Treiber als eindeutig betroffene Seiten im Verhältnis zum tatsächlichen Nenner bewertbarer Seiten. Treiber erschienen nicht als additive Punktabzüge, weil sich mehrere Regeln auf derselben Seite überschneiden können. Sites-Übersicht, Crawl-Historie, Vergleiche, Portfolio-Zusammenfassungen und Benachrichtigungen bei einem Health-Rückgang verwendeten denselben gespeicherten Score-Snapshot. Für ältere Crawls mit reinen Summendaten blieb die fehlende Unterstützung sichtbar. Inkompatible Läufe erzeugten kein Health-Delta. Benachrichtigungen verglichen nur gemessene Crawls, wenn Score-Version und Crawl-Umfang zueinander passten.
Site Audit trennt Live-Crawltempo von Verarbeitungszeit
Laufende Site Audits zeigten ihre durchschnittlichen Seiten pro Minute direkt unter der Crawlzeit. Sobald das Crawling endete, änderte sich diese Rate nicht mehr. Die spätere Berichtsverarbeitung ließ einen abgeschlossenen Crawl dadurch nicht langsamer erscheinen. Die Verarbeitungszeit begann mit der ersten Verarbeitung, auch wenn der Crawl noch lief. Crawlzeit, Verarbeitungszeit und Gesamtzeit beschrieben damit überlappende Phasen, statt den Eindruck zu erwecken, dass jede Verarbeitung auf die zuletzt geladene Seite wartete.
Das Action Center verbindet Belege aus den SEO-Abläufen
Das Action Center führte Belege aus Keyword-Arbeit, Domain-Analyse, Wettbewerbern, Tracking, verbundener Search-Console-Abdeckung, Site Audit und internen Links in einem Entscheidungsleitfaden zusammen. Jede Empfehlung zeigte ihre Quelle, bekannte Grenzen, Voraussetzungen, den zuständigen Produktbereich und einen Weg zur späteren Prüfung. Geschäftliche Passung und Ranking-Machbarkeit konnten ein attraktives Keyword zurückhalten, statt Nachfrage allein zur Aufgabe zu machen. Ein Workspace mit wenig Historie erhielt eine vorsichtige Einrichtungsfolge. Gab es keine qualifizierte Maßnahme, zeigte die Seite einen ehrlichen Leerzustand statt Füllaufgaben. Empfehlungen ließen sich unter My actions speichern, priorisieren und im Status ändern. Die Liste blieb über spätere Aktualisierungen hinweg erhalten. Vertiefende Daten oder ein KI-Plan starteten nur nach Bestätigung. Der KI-Plan bearbeitete eine ausgewählte Maßnahme mit einem reduzierten SEO-Belegpaket, schloss private Dokumente und Zugangsdaten aus und konnte den deterministischen Leitfaden nach einer fehlerhaften Antwort nicht unbemerkt ersetzen. Frühere Pläne blieben sichtbar, während eine Aktualisierung lief oder scheiterte.
Dashboard und Aktivität erklären jetzt jedes Signal im Kontext
Die Hilfe auf Home folgte dem Workspace-Briefing von Identität und Datenzustand über Keywords, Wettbewerber, technischen Zustand, Prioritäten, letzte Aktivität und Produktbereitschaft bis zu Lernressourcen. Jeder Schritt nannte die Quelle der Zusammenfassung und verlinkte die ausführliche Dokumentation des zuständigen Ablaufs. Activity erklärte das begrenzte 28-Tage-Fenster seiner Zusammenfassung, den neuesten Ereignisverlauf, Zähler, Statusbedeutungen, Benachrichtigungsfilter, Support-Belege und den Zugriff auf ältere Historienblöcke. Der Leitfaden benannte auch die Zuständigkeit: Activity dokumentierte Ergebnisse. Live-Steuerung und ausführlicher Zustand blieben in dem Produktbereich, der den Vorgang erzeugt hatte.
Contextter macht aus SEO-Daten einen geführten nächsten Schritt
Dieser Release verband Domain Overview, Wettbewerber, Action Center, Keyword Research, Keyword-Datenbank und die damalige Position-Tracking-Fläche zu einem geführten Ablauf. Workspace Home zeigte vorhandene Belege, den nächsten prüfbaren Schritt und bei eingerichtetem Tracking den geplanten Zeitpunkt der nächsten Ranking-Messung. Ein Schritt galt erst als abgeschlossen, wenn das entsprechende Ergebnis im Workspace vorhanden war. Domain- und Wettbewerberansicht begannen mit einer kompakten Lageeinschätzung: Was deuteten die aktuellen Daten an, warum konnte das relevant sein, welcher Beleg stützte die Aussage und wo ging die Prüfung weiter? Position Tracking trennte sofort zu prüfende Bewegungen von späteren Checks und Beobachtungspunkten. Fehlendes Suchvolumen erzeugte kein künstliches Dringlichkeitssignal. Keyword Research ergänzte Auswahlhilfen für Ideen, die als erreichbar, kommerziell oder durch Wettbewerberbelege gestützt markiert waren. Lagen bereits bezahlte Top-10-Ergebnisse für denselben Markt sowie denselben Sprach- und Gerätekontext vor, konnte der Workspace Keywords nach beobachteter SERP-Überschneidung gruppieren, ohne dieselben Daten erneut zu kaufen. Site Audit gruppierte Befunde nach einem wahrscheinlichen Lösungsbereich und kennzeichnete die Gruppe als Planungshilfe statt als belegte gemeinsame Ursache. Das Action Center hielt die unmittelbare Auswahl knapp, während die breitere Liste mit qualifizierenden Belegen wuchs oder schrumpfte. Jede aufgenommene Maßnahme nannte beabsichtigten Nutzen, geschätzten Aufwand, Belege, Voraussetzungen und nächsten Schritt. Der hier beschriebene Ablauf ist datiert; für heutige Navigation und Tracking-Verfügbarkeit ist das aktuelle Produkt maßgeblich.
Workspace Home erweitert sein Beleg-Briefing
Dieser Release erweiterte Workspace Home über Site Audit und Keyword-Datenbank hinaus. Die Seite wurde zu einem Briefing über die Domain, mögliche nächste Schritte, kürzlich abgeschlossene Vorgänge und die Belege der einzelnen Produktbereiche geordnet. Die Workspace-Domain stand am Anfang. Ihr Zusammenfassungsband zeigte beobachtete organische Keywords, Top-10-Rankings mit Veränderung seit der vorherigen Analyse, geschätzten Traffic-Wert, offene Site-Audit-Befunde und die Größe des Keyword-Bestands. Jede Zahl führte in den Produktbereich, dem ihr Beleg gehörte. Darunter bezog eine Spalte mögliche Arbeiten aus der vorhandenen Prioritätenliste. Eine zweite Spalte **What happened** zeigte produktübergreifend abgeschlossene Crawls, Domain-Analysen, Keyword-Research-Läufe und Datenaktualisierungen mit einem Link zur jeweiligen Quelle. Site Audit und Keyword-Datenbank behielten ihre größeren Widgets einschließlich Listenauswahl und Befundtrend. Kompakte Karten standen für Domain Overview, Keyword Research, Tracking und Competitors. Ein Produktbereich mit Daten zeigte seinen Hauptwert und die letzte Aktualisierung. Ein noch nicht eingerichteter Bereich erklärte, welche Belege er liefern konnte, und bot einen Startweg an, statt eine Null wie eine Messung aussehen zu lassen. Für die aktuelle Rolle nicht verfügbare Bereiche fehlten. Die letzte Zeile verlinkte Dokumentation sowie die zum Zeitpunkt des Seitenaufrufs neuesten verfügbaren Blog- und Glossareinträge. Auf großen Bildschirmen nutzte das Layout die verfügbare Breite; auf kleineren stapelten sich dieselben Zonen. Karten für Brain, Research und Content verschwanden von Home, solange diese damaligen Bereiche weiterentwickelt wurden, ihre historischen Seiten blieben an diesem Datum jedoch in der Navigation. Dieser Eintrag beschreibt weder das heutige Workspace Home noch die aktuelle Funktionsverfügbarkeit.
Recherche-Hilfe folgt jedem Entscheidungsschritt
Die Hilfe in Keyword Research und Competitive Research folgte dem Arbeitsbereich nun von oben nach unten, statt nach einer kurzen Einführung zu enden. Sie erklärte Recherchemodi, Seed-Begriffe und Domains, Marktkontext, Live-Schätzungen, Laufbelege, Filter, Begriffsgruppen, Kandidatenauswahl, Import, gespeicherte Läufe, Domain-Vergleiche, Historie, Marktposition, Wettbewerbssignale, Keyword-Gaps, Abdeckung, Listenaktionen und Wettbewerberdetails. Mit Enter ging es zum nächsten sichtbaren Schritt. Jeder Abschnitt verlinkte außerdem sein lokalisiertes Help-Center-Thema, wenn die kurze Erklärung nicht ausreichte. In Domain Overview blieb die Lauf-Auswahl in der Domain-Kontextzeile und war im hellen wie im dunklen Farbschema lesbar. Dieser Eintrag dokumentiert die in diesem Release eingeführte Hilfe und Seitenstruktur. Für heute verfügbare Modi und Steuerungen ist der aktuelle Arbeitsbereich maßgeblich.
Keyword Research startet mit konsistenten lokalen Suchsignalen
Keyword Research erzeugte Suchideen nun für den im Rechercheformular gewählten Markt und nicht für den Ort, an dem die Verarbeitung zufällig stattfand. Die Vorschläge dienten als zusätzliche Startpunkte und durchliefen weiterhin dieselben Relevanz-, Deduplizierungs- und Kennzahlenprüfungen, bevor sie in das Ergebnis gelangten. Wiederholte Quick-Research-Läufe verwendeten dadurch den beabsichtigten Marktkontext, ohne den Kandidatenpool zu verkleinern. Die Änderung erhöhte die Konsistenz; getrennte Live-Abfragen mussten trotzdem nicht identisch ausfallen.
Workspace-Seiten teilen einen einheitlichen Seitenkopf
Home, Action Center, Domain, Research, Competitors, Tracking, Briefs, Site Audit, Activity und Keywords erhielten dieselbe kompakte Orientierungsleiste. Seitentitel, relevanter Workspace-Kontext und wichtigste Seitenaktionen blieben an einer vorhersehbaren Stelle. Steuerungen für eine bestimmte Ansicht oder einen Datensatz lagen weiterhin direkt darunter. In der Keyword-Datenbank teilten sich die wichtigsten Kennzahlen eine einzeilige Kontextleiste oberhalb der Ansichtssteuerungen. Der aktuelle Datenkontext blieb sichtbar, ohne der Keyword-Tabelle unnötig Platz zu nehmen. Auch die Aktionen im Seitenkopf folgten einer Regel. Help verwendete eine blaue Informationsdarstellung; gewöhnliche Seitenaktionen nutzten die primäre Buttonfarbe. Home konzentrierte den Seitenkopf auf Help, statt die Navigation zu Keyword-Datenbank und Site Audit zu wiederholen. Help öffnete eine geführte Erklärung der aktuellen Seite und folgte ihren sichtbaren Bereichen. Domain Overview deckte Snapshot-Kontext, Authority, Rankings, Wettbewerber, Keywords, Links und Growth ab. Die historische Tracking-Fläche passte den Leitfaden an Overview, Positions, Pages, SERP Features, Competitors, Cannibalization und Schedules an. Site Audit umfasste seine zehn Workbench-Ansichten; eine gecrawlte URL stellte Help auf Overview, Befunde, Links, Assets, Schema, Änderungen oder technische Belege ein. Jeder Schritt führte zum passenden lokalisierten Dokumentationsthema. Keywords behielt sein ausführlicheres Datenbank-Onboarding hinter demselben Einstieg. Dieser Eintrag dokumentiert die damalige Workspace-Navigation einschließlich Bereichen, die heute nicht mehr zum Kernprodukt gehören.
Position Tracking bleibt auch mit langer Historie reaktionsschnell
Position Tracking isolierte einen Ausfall nun auf die betroffene Ansicht. War eine Datenquelle vorübergehend nicht verfügbar, blieben Tracker-Auswahl, andere Tabs und Zeitplanverwaltung nutzbar. Nur der betroffene Bereich zeigte Support-Code und erneuten Versuch. Auch ein nicht verfügbarer optionaler Site-Audit-Link stoppte, ohne die erfassten Daten zur Ranking-Seite auszublenden. Historienabrufe waren auf den ausgewählten Kontext begrenzt, statt jede Messung an den Browser zu senden. Trends zeigten die letzten 30 Punkte. Die Wettbewerberanalyse lud nur bei geöffneter Ansicht, die aktive Wettbewerberauswahl war auf 20 begrenzt und Zeitplanlisten zeigten die letzten 30 Einträge mit einem Hinweis auf ältere Datensätze. Vor dem Start eines Zeitplans musste seine Kostenschätzung aktuell sein. Ungültige Eingaben für Keyword, Sprache, Ort, Gerät oder Budget wurden einheitlich abgelehnt. Listenbasierte Tracker unterstützten in diesem Release bis zu 500 Keywords je Lauf. Eine größere Liste erhielt eine sichtbare Limitmeldung, statt einen nicht abschließbaren Vorgang zu starten. Die Übersicht behielt die Positionen aller vier Hauptkennzahlen bei, wenn ein Wert fehlte, und erklärte die fehlenden Daten, statt eine Null einzusetzen. Der Einrichtungsbereich hielt Domain, Keyword-Auswahl, Wettbewerber und Zeitplaneinstellungen in einer großzügigen, aber begrenzten Fläche. Die Orders-Ansicht nutzte die verfügbare Breite und behielt eine einzige Erstellungsaktion im Seitenkopf. Diese Tracking-Limits und Flächen dokumentieren den damaligen Produktstand, nicht den heutigen Funktionsumfang von Contextter.
Site Audit trennt Crawl-Historie, Laufprüfung und Automation
Der History-Tab wurde zu **Crawls** und trennte die Laufhistorie von der Prüfung eines einzelnen Crawls. Seine Tabelle listete jeden gespeicherten Lauf mit Zahl gecrawlter URLs, Health, offenen Befunden und der Veränderung jedes Werts gegenüber dem vorherigen Lauf. Die Auswahl eines Crawls verwandelte denselben Tab in einen Run Inspector. Der Inspector fasste das erfasste Ergebnis verständlich zusammen. Während eines aktiven Crawls zeigte **Happening now** die aktuelle Abrufphase und Zusammensetzung der Warteschlange; diese Ansicht öffnete sich dann standardmäßig. Das gespeicherte Crawl-Protokoll verwendete Seitennavigation statt einer kleinen Stichprobe. Nutzer konnten seine URL-Einträge durchgehen, nach Befunden oder Weiterleitungen filtern und die Detailansicht einer Seite öffnen. Fehlermeldungen standen als lesbare Sätze unter der URL statt als interne Codes in der Tabelle. Tabellen scrollten in ihrem eigenen Bereich und nutzten die verfügbare Höhe, auch wenn nur ein Lauf vorhanden war. Eine URL-Detailseite erhielt einen Navigationspfad und eine Zurück-Aktion, die zum übrigen Workspace passten. **Monitoring** wurde in **Automation** umbenannt, weil Zeitpläne Audits starten konnten, statt sie nur zu beobachten. Jeder Zeitplan zeigte den vorherigen Lauf und dessen Ergebnis und verlinkte zu diesem Crawl. Zeitpläne und Benachrichtigungen ließen sich bearbeiten, pausieren oder löschen und verwendeten getrennte Erstellungsformulare. **Crawl now** startete unmittelbar ein Audit. Zeitplan- und Benachrichtigungskarten behielten nach dem Löschen aller Einträge ihren Leerzustand, damit der Tab weiterhin erklärte, was eingerichtet werden konnte.
Domain Overview verhindert doppelte Reservierungen und übernimmt mehr Daten
Domain-Analysen erhielten eine Historie mit Seitennavigation, sichtbare Speichergrenzen und eine bestätigte Löschaktion. Derselbe Abruf verwendete nach einer Netzwerkunterbrechung seine vorhandene Vorgangskennung, statt eine zweite Analyse oder Guthabenreservierung anzulegen. Ein kostenpflichtiger Abruf begann nicht, wenn Zahl oder Wert der aktiven Reservierungen innerhalb der damaligen Grenzen nicht zuverlässig feststanden. Zeilen organischer Keywords ergänzten die beobachtete Ranking-Seite, geschätzten Keyword-Traffic und Competition, sofern die Quelle diese Daten lieferte. Das Wettbewerberpanel behielt seinen kompakten Vergleich und erhielt eine Tabelle mit gemeinsamen Keywords, insgesamt beobachteten organischen Keywords, durchschnittlicher Position und geschätztem Traffic. Ein Auswahlfenster verband den Snapshot mit dem übrigen Workspace. Ausgewählte Zeilen ließen sich als deduplizierte Liste `Domain · example.com` in der Keyword-Datenbank speichern. Vorhandene Angaben zu Volumen, Schwierigkeit, CPC, Competition, Suchintention und Sprache blieben erhalten. Dieselbe Auswahl konnte Keyword Research starten; die Grenze von 100 Seeds erschien vor der Navigation. Bei den damals verfügbaren kostenpflichtigen Research-, Tracking-, Briefing-, Import- und Site-Audit-Aktionen stoppte Contextter vor einem externen Datenabruf, wenn sich die Summe aktiver Reservierungen nicht exakt berechnen ließ. Für heutige Bezahlaktionen, Limits und Aufbewahrung ist das aktuelle Produkt maßgeblich.
Site Audit zeigt die vollständige Crawl-Struktur und Link-Trends
Die Tabelle der Site-Struktur zeigte nun jeden Ordner des ausgewählten Crawls, statt kleinere Gruppen auszublenden. Sie nutzte die verfügbare Bildschirmhöhe, scrollte unabhängig und hielt ihre Spaltenköpfe sichtbar. Die Übersicht der internen Links ergänzte bis zu sechs Trends je Crawl: interne Links, durchschnittliche Links pro Seite, verwaiste Seiten, externe Links, `nofollow` und Links zu Weiterleitungen. Link Explorer und Link Map nutzten ebenfalls die verfügbare Höhe. Die Run-Übersicht behielt dieselben Statistik- und Quellenwerte, trennte sie jedoch in flachere Abschnitte. Der Bereich "Why this happens" eines Befunds führte zu einem passenden Glossareintrag, etwa zu Canonical-Tags, Hreflang oder Weiterleitungsketten. Domain- und Run-Auswahl schlossen, wenn der Fokus an eine andere Stelle wechselte. Asset-Befunde zeigten die vollständige Asset- und Quellseiten-URL und öffneten den Beleg direkt. Die Issues-Übersicht übernahm die kompakten Agent-Aktionen eines einzelnen Befunds. **Agent prompt** öffnete eine Markdown-Vorschau für die aktuell gefilterten Befunde. **Agent endpoint** erzeugte erst nach ausdrücklicher Bestätigung eine begrenzte Abrufadresse, ohne eine eigene Exportfläche über der Liste auszuklappen. Ein optionaler Leitfaden erklärte die Übergabe an Coding-Agenten vom Repository-Zugriff bis zur Validierung und einem bestätigenden Crawl. Das Endpoint-Panel erklärte, wann der Abrufablauf hilfreicher war als ein kopierter Prompt, wie eine authentifizierte Anfrage an einen Coding-Agenten übergeben werden konnte und warum die vorübergehende Zugangskennung privat bleiben musste. Die Kennung stand nicht länger in der URL, lief nach einer Stunde ab und ließ sich im selben Panel widerrufen. Abgebrochene und fehlgeschlagene Crawls erhielten einen verständlichen Zustand und einen möglichen nächsten Schritt. Interne Fehlercodes blieben aus der für Kunden bestimmten Ansicht heraus.
Site-Audit-Monitoring zeigt Zeitpläne und Zustellstatus
Der Monitoring-Tab reduzierte die erste Einrichtung auf Rhythmus und Empfänger. Wöchentlich war in diesem Release die empfohlene Voreinstellung. Erweiterte Einstellungen legten Zeitpunkt, Budget, URL-Limits und Auslöser offen. Jeder wiederkehrende Zeitplan zeigte seinen nächsten geplanten Lauf und ließ sich pausieren, fortsetzen oder löschen. Wurde ein Lauf ausgelassen, etwa wegen zu geringen vorausbezahlten Guthabens, stand der erfasste Grund auf der Zeitplankarte. Benachrichtigungskarten lagen neben dem Zeitplan. Ein Aktivitätsverlauf listete jedes ausgelöste Ereignis mit dem bekannten E-Mail-Zustellstatus auf. Der Status unterschied die erfassten Verarbeitungszustände und behandelte die Annahme durch den E-Mail-Dienst nicht als Beleg für eine bestätigte Zustellung. Diese Zeitplan-Voreinstellungen dokumentieren den Produktstand dieses Datums.
Site Audit korrigiert das Laden von Statistiken und den Umfang der Klicktiefe
Dieser Release korrigierte zwei Verhaltensweisen im Statistik-Tab. Die Statistiken eines abgeschlossenen Crawls wurden verfügbar, ohne dass der Tab nach beendeter Verarbeitung weiter "Statistics are being prepared" anzeigte. Die Klicktiefe beschränkte sich außerdem auf Seiten, die über erfasste interne Links von der Startseite aus erreicht wurden. Eine ausschließlich über die Sitemap entdeckte Seite vergrößerte die intern erreichbare Gruppe nicht mehr und erschien für diese Messung als "Not linked". Vorhandene Crawl-Ergebnisse behielten ihre gespeicherten Werte; die korrigierte Verteilung begann mit dem nächsten Crawl.
Keyword-Recherche findet mehr relevante Suchideen pro Run
Quick Research erweiterte jedes Thema über eng verwandte Suchen und bis zu drei verwandte Blickwinkel. Der Ablauf prüfte Fragen, Präpositionen, Modifikatoren, Vergleiche, Jahres- und lokale Suchintention sowie A-Z-Varianten. Nur eine begrenzte Kandidatenmenge ging anschließend in eine gemeinsame Kennzahlenprüfung. Deep Research führte die Suche in anpassbaren Runden weiter. Der Ablauf folgte relevanten neuen Blickwinkeln, stoppte bei sinkendem zusätzlichem Ertrag und reicherte eine begrenzte Auswahl an, bevor er nach den damaligen Limits bis zu 2.000 deduplizierte Keywords zurückgab. Start-Keywords wurden bereits beim Tippen gezählt. Die Live-Schätzung erschien in einer Startschaltfläche mit fester Breite. Preisaktualisierungen verschoben dadurch die Bedienelemente nicht und wiederholten den reservierten Betrag nicht an mehreren Stellen. Quick Research prüfte höchstens 360 Vorschlagskandidaten und gab höchstens 600 deduplizierte Keywords zurück. In diesem Release bildete die bestätigte Schätzung die Abrechnungsobergrenze. Höhere Kosten der Datenquelle wurden nach Abschluss nicht zusätzlich berechnet. Vor einem kostenpflichtigen Datenabruf prüfte der Lauf, ob er weiterhin dem richtigen Workspace und Datenbestand zugeordnet war. Eine fehlgeschlagene Übergabe gab ihre Reservierung frei. Der Aktivitätsverlauf unterschied Zustellungs-, Konfigurations-, Netzwerk-, Zeitüberschreitungs-, Kontingent- und Datenquellenfehler, statt sie in einer Meldung zusammenzufassen. Diese Methoden, Limits und Preisregeln dokumentieren den damaligen Produktstand; für heute ist der aktuelle Checkout maßgeblich.
Competitor Workbench: die richtigen Domains in der passenden Tiefe vergleichen
Die Competitor Workbench machte aus Domains, die in beobachteten Suchergebnissen auftauchten, einen gepflegten Wettbewerberkatalog. Nutzer konnten relevante Wettbewerber hinzufügen, entfernen oder anheften und die wechselnde SERP-Landschaft vom kuratierten Vergleichsset trennen. In diesem Release konnten bis zu 20 Wettbewerber gleichzeitig aktiv sein. Der größere Kandidatenkatalog blieb paginiert. Ein schneller Vergleich deckte die wichtigsten Signale zu Autorität, Traffic, Keywords und Links ab. Die tiefe Analyse ergänzte Keyword-Gaps, Suchintention, Difficulty, Top-Seiten und ausführlichere Linkbelege. Vor jedem Lauf schlüsselte der Checkout die Schätzung auf und verwendete vorhandene Snapshots oder abgeschlossene Module erneut. Nur fehlende Daten wurden angefordert. Ergebnisse blieben datierte Snapshots: Eine Änderung am aktiven Set bereitete einen neuen Vergleich mit neuer Preisvorschau vor, statt einen früheren Stand umzuschreiben.
Interne Links als verständlicher Explorer
Dieser Release baute den Bereich Internal Links um die Beziehungen und Fundstellen auf, die ein Site-Audit-Crawl erfasst hatte. Die Übersicht zeigte, wie viele interne und externe Links der Crawl gefunden hatte, wie viele auf Weiterleitungen zeigten oder `nofollow` trugen, welche gecrawlten Seiten keinen erfassten eingehenden internen Link besaßen und welche Seiten die meisten internen Links erhielten. Jede Zahl und Tabellenzeile öffnete die passend gefilterten Belege, statt bei einer Zusammenfassung zu enden. Im Explorer öffnete die Auswahl einer Seite ihren Titel, die vollständige URL, den Navigationspfad sowie Summen für eingehende, ausgehende und externe Links. Breite Tabs trennten eingehende, ausgehende, externe und Backlink-Beziehungen. Platzierungsfilter unterschieden Content, Navigation, Footer und weitere erfasste Seitenbereiche. Ein Schalter für Liste oder Karte änderte nur die Darstellung derselben Auswahl. "Page details" öffnete den vollständigen Seitenbericht mit seinen Befunden, ohne den gewählten Linkkontext zu verlieren. Wiederholte Links zwischen derselben Quelle und demselben Ziel erschienen als eine Beziehung. Die Zeile behielt Anzahl der Fundstellen, unterschiedliche Ankertexte und erfasste Seitenbereiche wie Navigation, Header und Footer. Die Zusammenführung entfernte dadurch keine Belege. In der Tabelle "All links" dienten die Summenkacheln für intern, extern, defekt, Weiterleitung und `nofollow` zugleich als Filter. Jede Zeile konnte den Explorer an ihrer Quellseite öffnen. Sämtliche Zahlen blieben auf den ausgewählten Crawl und getrennt gekennzeichnete Backlink-Quellen begrenzt.
Keyword Research wird vom Formular zur Workbench
Dieser Release machte aus dem einzelnen Keyword-Research-Formular einen Arbeitsbereich für die Ergebnisse. Ein Lauf konnte mit Keywords oder Wettbewerberdomains, einem Markt und einer Recherche-Tiefe beginnen. Der Checkout zeigte vor der Bestätigung seine Schätzung. Das Ergebnis öffnete sich als filterbare Tabelle mit dem jeweils verfügbaren Suchvolumen, CPC, Schwierigkeit und Suchintention je Zeile. Match-Modi trennten All, Broad, Phrase, Exact, Related und Questions. Eine Begriffsliste zeigte häufige Wörter des aktuellen Ergebnisses. Weitere Filter erfassten Volumen, Schwierigkeit, Suchintent, Quelle sowie ein- oder auszuschließende Begriffe. Diese Steuerungen arbeiteten auf den bereits gelieferten Daten und starteten keinen weiteren kostenpflichtigen Abruf. Eine Markierung kennzeichnete Keywords, die schon in der Keyword-Datenbank lagen. Der Filter "only new" blendete sie aus. Der Import blieb eine bewusste Entscheidung: Nutzer wählten die gewünschten Zeilen und eine vorhandene oder neue Liste. Recent Searches speicherte jeden Lauf mit Markt, Keyword-Zahl und abgerechneten Kosten nach den damals geltenden Aufbewahrungsregeln. Das erneute Öffnen und Filtern eines gespeicherten Ergebnisses kaufte dieselben Daten nicht noch einmal. Der Eintrag dokumentiert den Ablauf vom Juli 2026; für heutige Aufbewahrung, Recherche-Methoden und Preise ist das aktuelle Produkt maßgeblich.
Position Tracking: beobachtete Wettbewerber, SERP-Features und Trends
Die Competitors-Ansicht listete nun Domains, die wiederholt in den Top 10 der beobachteten Keyword-Menge vorkamen, einschließlich nicht manuell eingetragener Domains. Jede Zeile zeigte gemeinsame Keywords, beste beobachtete Position und durchschnittliche Position. Eine Domain ließ sich zum Vergleich hinzufügen oder daraus entfernen. Wenn gespeicherte Suchergebnisse frühere Messungen abdeckten, konnte ein neu gewählter Wettbewerber diese Historie verwenden, statt mit einer leeren Reihe zu beginnen. Die SERP-Features-Ansicht fasste zusammen, welche erfassten Suchergebnisse AI Overviews, Featured Snippets, Local Packs, Bilderpakete oder weitere Features enthielten, wie viele beobachtete Keywords betroffen waren und wo die eigene Domain in einem solchen Feature erfasst worden war. Die Auswahl eines Features öffnete die dazugehörigen Keywords. Sichtbarkeit, geschätzter Traffic, durchschnittliche Position und Share of Voice erhielten eigene Karten mit Trenddiagrammen. Ein gestapeltes Diagramm zeigte die Veränderung der Top-3-, Top-10-, Top-20- und Top-100-Zahlen zwischen den Läufen. Eine Faktenzeile nannte Domain, Gerät, Sprache, Markt, Keyword- und Wettbewerberzahl, Suchtiefe und letzte Aktualisierung. Fehlendes Suchvolumen blieb in der Traffic-Schätzung unbekannt und erschien nicht als Null. Die Wettbewerberansicht verglich wahlweise Sichtbarkeit, geschätzten Traffic, durchschnittliche Position, Top-10-Zahl oder Share of Voice der ausgewählten Domains. Die Keyword-Tabelle verwendete Seitennavigation. Der Übersichtstrend konnte zusätzlich die Zahl der beobachteten Keywords mit irgendeiner Platzierung darstellen. Im ersten Schritt des Einrichtungsdialogs ließ sich die beobachtete Domain ändern. In der Positionsansicht besaß jedes Keyword eine eigene Reihe; jede abgeschlossene Messung fügte einen Punkt hinzu. Diese Tracking-Flächen beschreiben den Produktstand dieses Datums und sind keine Aussage über den heutigen Funktionsumfang von Contextter.
Klarere Wege zu allen öffentlichen Contextter-Seiten
Dieser Release glich die öffentlichen Routen für Plattform, Funktionen, Lösungen, Lernressourcen, Vergleiche und Unternehmensinformationen aneinander an. Bestehende Kunden- und Vergleichsadressen blieben nach Möglichkeit stabil. Eingestellte Routen leiteten zum nächstgelegenen gepflegten Ziel weiter, statt an einer nicht gefundenen Seite zu enden. Navigation und Seitenverzeichnisse zeigten in jeder unterstützten Sprache dieselben Routengruppen. Öffentliche Verzeichnisse banden ihr Aktualisierungssignal außerdem an eine bedeutsame Änderung der Quelle. Eine unveränderte Seite erhielt dadurch nicht nur wegen eines neuen Website-Builds ein frisches Datum. Der Release verbesserte die Auffindbarkeit; er bestätigte nicht die Vollständigkeit jeder verlinkten Seite oder Übersetzung.
Site Audit gibt jeder URL eine eigene Prüfseite
Die Pages-Ansicht begann mit internen URLs. Ein sichtbarer Scope-Schalter wechselte zwischen Internal, External und All. Die Auswahl einer Seite öffnete eine eigene URL-Route statt eines Overlays. Sie zeigte den aus dem Crawl abgeleiteten Score, Befunde, HTTP-Status, Antwortzeit, Wortanzahl und Linkzahlen. Eigene Tabs trennten Befunde, Links und den erfassten Crawl-Pfad, Assets, strukturierte Daten, Änderungen seit dem vorherigen Crawl und technische Fakten. Beim Öffnen einer verlinkten URL wechselte die Ansicht zu deren eigener Seite. Die normale Browser-Historie blieb dadurch während der Untersuchung nutzbar. Bestehende Deep Links leiteten auf die neue Route weiter, statt zu brechen. Die Übersicht bündelte ihre Readiness-Prüfungen in einer Liste. Die Auswahl eines Schweregrads öffnete die passenden Befunde. Der Crawl-Pfad zeigte den erfassten internen Linkweg als nummerierte Kette. Die Aktion **Copy for agent** bereitete für einen Befund oder die aktuelle Menge offener Befunde einen Prompt mit URL-Kontext, erfassten Belegen und vorgeschlagener Korrektur vor. Der Prompt blieb eine Übergabe zur Prüfung und war kein Beweis, dass die vorgeschlagene Änderung zu jeder Codebasis passte.
Neue Über-uns-, Sicherheits- und Kontaktseite
Dieser Release führte eigene Seiten für Über uns, Sicherheit und Kontakt ein. Die Über-uns-Seite erklärte in einer interaktiven Erzählung beim Scrollen, wie Contextter Suchbelege, Priorisierung und spätere Prüfung verbindet. Die Sicherheitsseite dokumentierte den normalen Anmelde- und Workspace-Zugriffsweg, begrenzte die dazu möglichen Aussagen und bot einen Weg zum Melden eines Sicherheitsproblems. Über ein funktionierendes Kontaktformular mit Themenauswahl erreichten Nachrichten das Team, ohne dass die Seite eine feste Antwortzeit versprach. Seit diesem Release wurden alle drei Seiten weiterentwickelt; ihre heutige Fassung bleibt die maßgebliche Beschreibung.
Domain Overview bündelt wichtige Belege in einem Snapshot
Domain Overview führte Autorität, Backlinks, verweisende Domains, geschätzten organischen Traffic, Ranking-Keywords, Wettbewerber, Top-Seiten, Anchor-Texte und häufig verlinkte Seiten in einem angeforderten Snapshot zusammen. Vor dem Lauf zeigte der Checkout Markt, Keyword-Tiefe und geschätzten Preis. Die endgültige Belastung blieb innerhalb dieser bestätigten Schätzung. Soweit Historie verfügbar war, zeigte sie monatliche Traffic- und Keyword-Bewegungen. Ältere Analysen blieben über Pagination erreichbar. Ausgewählte Keywords ließen sich an die Keyword Database oder Keyword Research übergeben. Eine beobachtete Wettbewerber-Domain konnte eine getrennte Analyse starten oder mit mehreren Domains verglichen werden. Der Vergleich hielt Autorität, Traffic, Keywords, Links, Historie, Gaps und Top-Seiten zusammen und nutzte vorhandene aktuelle Daten erneut, soweit der damalige Releasevertrag das erlaubte. Es blieben datierte Snapshots und bewusste Übergaben, kein automatischer Import aller beobachteten Ergebnisse.
Die Workspace-Startseite stellt aktuelle Signale vor das Inventar
Die neu gestaltete Workspace-Startseite begann mit den verfügbaren Signalen zur Website: Site Health, durchschnittliche Position mit Trend, Größe des Keyword-Bestands und Zahl der erfassten Chancen. Jede Zusammenfassung führte zu ihrer zugrunde liegenden Ansicht. Eine Kennzahl ließ sich dadurch prüfen und erschien nicht als vollständiges Urteil. Der Bereich "What to do now" übersetzte vorhandene Befunde in verlinkte Hinweise, etwa schwerwiegende Probleme zu prüfen, ein gefallenes Keyword anzusehen oder über erfasste Chancen zu entscheiden. Das waren priorisierte Ausgangspunkte, keine Belege dafür, dass jede vorgeschlagene Maßnahme die Leistung verbessern würde. Site Audit zeigte Zustandsanzeige, Fehler- und Warnungszahlen sowie häufige Befunde. Keywords zeigte Positionsverteilung, Trend und die größten Bewegungen einer ausgewählten Liste. Die Brain- und Research-Widgets fassten Wissensbasis und aktuelle Berichte zusammen, die zum damaligen Produkt gehörten. Ungenutzte Werkzeuge erklärten an ihrer leeren Stelle, welche Daten später erscheinen würden. Ein neuer Workspace bot zwei klare Einstiege statt Diagrammen ohne Daten. Dieser Eintrag dokumentiert das damalige Dashboard, nicht die heutige Produktnavigation.
Keyword-Entdeckung: Tiefe wählen statt Datenquelle
Dieser Release ersetzte vier nach Datenquellen benannte Pakete durch drei auf die Aufgabe ausgerichtete Recherche-Tiefen. Quick Research lieferte verwandte Keywords und Ideen mit den enthaltenen Kennzahlen über den günstigeren Weg. Deep Research suchte breiter und kombinierte beobachtete Google-Suchvorschläge mit einer Kennzahlenprüfung. Competitor Analysis lieferte weiterhin Keywords, die für die ausgewählten Wettbewerberdomains gefunden wurden. Contextter wählte die benötigten Quellen und entfernte doppelte Kandidaten, bevor die Ergebnisse erschienen. Vor jedem Lauf zeigte der Checkout die aktuelle Schätzung und das verfügbare Guthaben. Die Abrechnung richtete sich nach den tatsächlich gelieferten Daten und blieb innerhalb der bestätigten Schätzung. Die Methodenkarten berechneten ihre Schätzung aus den aktuellen Seeds. Ein leerer Workspace konnte mit Keywords beginnen, die für die eigene Domain beobachtet worden waren. Der Filter "Questions only" isolierte Kandidaten in Frageform. Die Keyword-Datenbank erhielt außerdem einen direkten Nachschlageweg. Eine Suche nach einem noch nicht gespeicherten Begriff konnte das Keyword anlegen und sein Detailpanel öffnen. Kostenpflichtige Kennzahlen erschienen erst, nachdem der Nutzer den Datenabruf bestätigt hatte. Diese Recherche-Tiefen und Preise beschreiben den Produktstand dieses Datums. Für heutige Methoden, Abdeckung und Kosten ist der aktuelle Checkout maßgeblich.
Optimizer-Presets bleiben zuverlässig synchron
Der damalige Optimizer speicherte nun exakt die vom Nutzer gewählte Strategie und den eigenen Fokus, auch bei mehreren schnellen Änderungen nacheinander. Bestehende Presets blieben lesbar. Ein ungültiger gespeicherter Wert fiel auf eine unterstützte Voreinstellung zurück, statt ein Projekt mit einer nicht unterstützten Strategie oder fehlerhaften Gewichtung zu öffnen. Ergebniswarnungen waren außerdem auf Deutsch, Englisch, Französisch und Spanisch lokalisiert. Dieser Eintrag beschreibt den Writer und Optimizer dieser Zeit, nicht einen heutigen Contextter-Ablauf.
Position Tracking: Rankings, Seiten und Wettbewerber auf einer Fläche
Dieser Release erweiterte Position Tracking von einem einzelnen Diagramm zu einem eigenen Arbeitsbereich. Die Übersicht zeigte Sichtbarkeit, geschätzten Traffic, durchschnittliche Position, die Zahl der beobachteten Keywords in den Top 3, 10, 20 und 100 sowie Begriffe, die seit der vorherigen Messung in diese Bereiche ein- oder ausgetreten waren. Ein Trenddiagramm deckte den ausgewählten Messzeitraum ab. Eigene Ansichten trennten die Belege: eine Positionstabelle mit Bewegung, Suchvolumen, CPC und beobachteter Ranking-URL; eine Seitenansicht, die Keywords nach URL gruppierte; ein Tags-Vergleich für Keyword-Gruppen; eine SERP-Features-Ansicht für erfasste Featured Snippets und AI-Overview-Zitate; ein Wettbewerbervergleich über dieselbe Keyword-Menge; und ein Kannibalisierungsbericht für Begriffe, deren beobachtete Ranking-URL zwischen zwei Seiten wechselte. Ein Kontextschalter stellte Gerät oder Standort für den gesamten Arbeitsbereich um. Die Zeitplanverwaltung blieb in einem eigenen Tab. Ein Nutzer konnte Keywords in der Keyword-Datenbank auswählen und über "Tracken" einen Zeitplan für genau diese Auswahl anlegen, ohne zuvor eine Liste zu erstellen. Diese wiederkehrenden Tracking-Funktionen beschreiben den Produktstand dieses Datums und sind keine Aussage über den heutigen Funktionsumfang von Contextter.
Recherche-Läufe erholen sich sicherer
Der damalige Live-Research-Ablauf prüfte Fortschritt, Funde, Kosten, Abschluss und Fehlermeldungen, bevor sie in den Bericht gelangten. Eine unvollständige Antwort endete in einem ausdrücklichen Fehlerzustand, statt fehlerhafte Berichtsdaten auf der Seite zu hinterlassen. Auch ein verspäteter Abschluss eines abgebrochenen Laufs konnte eine neuere Sitzung nicht mehr stoppen oder überschreiben. Der Fix verringerte dieses konkrete Risiko veralteter Aktualisierungen. Er versprach keine Wiederherstellung nach jeder denkbaren Unterbrechung.
Ein klarerer Einstieg in das Contextter-Wissenssystem
Dieser Release baute Ressourcenübersicht und Learning Center als getrennte Einstiege für unterschiedliche Leseziele neu auf. Die Ressourcenseite erklärte die jeweilige Aufgabe von Learning Center, Blog, SEO-Glossar, Dokumentation und Changelog, ihre Verbindung untereinander und enthielt die damals zuletzt veröffentlichten Bloganalysen. Das Learning Center ordnete vier Lernpfade den Bereichen Keywords und technisches SEO zu. Jeder Pfad zeigte die angegebene Schwierigkeit, geschätzte Dauer und seine Arbeitsschritte. Eine Zielauswahl schlug einen möglichen Einstieg vor. Die Guides zeigten ihre Position im Pfad und verlinkten den vorherigen und nächsten Abschnitt. Das waren Navigationshilfen, keine Behauptung, die Ressourcensammlung sei vollständig oder ein vorgeschlagener Pfad passe zu jedem Leser.
Mehr Klarheit im Site Audit und Workspace
Dieser Release ordnete Site Audit um drei Fragen: Was sagte der Crawl über den Zustand der Website, welche Befunde verdienten zuerst eine Prüfung und wo traten sie auf? Die Übersicht verband einen Health Score mit Trend, anklickbare Befundzahlen, eine "Fix first"-Liste und Kategoriekacheln, die die passenden gefilterten Befunde öffneten. Sites, Overview, Issues, Pages, Links, Compare, History, Monitoring und Settings lagen nun in einer gemeinsamen Tableiste statt in einer zweiten Seitenleiste. Jede Ansicht öffnete zunächst den letzten abgeschlossenen Crawl. Wer im Run Picker einen älteren Lauf auswählte, behielt einen sichtbaren Weg zurück zum aktuellen Ergebnis. Der Compare-Tab zeigte Unterschiede zwischen zwei Crawls: nicht mehr beobachtete Befunde, neue Befunde sowie hinzugefügte oder entfernte Seiten. Er dokumentierte Veränderungen zwischen Messungen, ohne eine bestimmte Korrektur als Ursache auszugeben. Die Seitenleiste der Anwendung ließ sich mit der Taste **[** zu einer schmalen Symbolleiste einklappen. Das vorausbezahlte Guthaben erschien oberhalb des Profils, und der Organisationswechsel zog in das Kontomenü. Diese Navigationsdetails dokumentieren die Oberfläche dieses Datums.
Die Struktur deiner Website auf einen Blick
Die Pages-Ansicht erhielt neben dem flachen URL-Inventar die Perspektive **Site structure**. Ihr Ordnerbaum stellte die URLs des ausgewählten Crawls dar. Jeder Ordner zeigte Seitenzahl, Anteil an der gecrawlten Website und die Zahl der erfassten Seiten, die defekt oder mit `noindex` gekennzeichnet waren. Ordner zeigten außerdem die offenen Befunde ihrer Seiten und markierten Bereiche mit kritischen oder hochpriorisierten Befunden. Sie ließen sich an Ort und Stelle aufklappen. Spalten für URLs, Befunde, defekte Seiten, Weiterleitungen und `noindex` waren sortierbar; die Suche grenzte den Baum ein, ohne seine Hierarchie aufzulösen. Ein Ordner in beliebiger Tiefe öffnete den Page Explorer mit einem bereits gesetzten Filter "path starts with". In der Pages-Werkzeugleiste blieben Suche und ein Filters-Button sichtbar. Die vollständige Filteransicht und Spaltenverwaltung lagen hinter diesem Steuerelement.
SEO-Arbeit beginnt jetzt mit der Aufgabe
Dieser Release trennte die wichtigsten SEO-Aufgaben in der Workspace-Navigation: Keyword Research für die Nachfrage-Recherche, Competitive Research für Wettbewerbsbelege, Position Tracking für die damals beobachteten Keyword-Mengen, Site Audit für crawlbasierte technische Befunde und das Action Center für die Priorisierung. Keywords blieb der gemeinsame Bestand für Listen, Filter, Matrix, Kanban, Activity, kostenpflichtige Anreicherungen und Sammelaktionen. Vorhandene Lesezeichen führten weiterhin in den passenden Ablauf. Seitenleiste und interne Links öffneten die einzelnen Bereiche direkt. Die Navigation änderte sich, ohne die zugrunde liegenden Datensätze aufzuteilen. Research-Ergebnisse ließen sich weiterhin in Keywords speichern, beobachtete Listen behielten ihre Identität und Empfehlungen öffneten die Ansicht, welche die Belege oder Aktion verantwortete. Die kompakte Seitenleiste bot übersetzten Werkzeugnamen genug Raum und stellte Hilfstechnologien die vollständige Zielbezeichnung bereit. Auch interne Linkchancen erhielten eine eindeutige Quelle. Site Audit speicherte Quelle, Ziel, Ankertext und Lebenszyklusbelege unter Internal Links. Das Action Center konnte priorisierte Empfehlungen anzeigen, öffnete für die Details jedoch die passend gefilterte Site-Audit-Ansicht. Dieser Eintrag dokumentiert die damalige Produktstruktur. Dazu gehört auch das historische Position Tracking.
Site Audit konzentriert sich auf belastbare Bereiche
Dieser Release begrenzte den ersten Site-Audit-Arbeitsbereich auf Crawl-Einrichtung, Zustand, Verlauf, Befunde, Seiten, Links, Monitoring und Einstellungen. Überschneidende oder unfertige Bereiche verschwanden aus der Navigation, statt bereits einsatzbereit zu wirken. Der Link Explorer blieb der zuständige Ort für Seitenstruktur und die Belege zu Linkpfaden. Die übrigen Ansichten konzentrierten sich auf die Crawl-Ergebnisse, für die sie tatsächlich verantwortlich waren.
Workspace-Limits erklären Upgrade und Wiederherstellung
Beim Erstellen eines Workspace erklärte das Formular direkt, wenn das Kontingent des aktuellen Plans erreicht war. Die Meldung zeigte aktuelle Nutzung und verfügbare Grenze, behielt die Eingaben und führte zu den passenden Planoptionen, ohne interne Fehlerdetails offenzulegen. Auch der Abo-Checkout erkannte wiederkehrende Kunden, deren Konten noch vor dem Organisationsmodell verbunden worden waren. Ein Upgrade scheiterte dadurch nicht mehr an einem doppelt angelegten Kundenkonto. Falls ein späterer Plan weniger Workspaces erlaubte, führte der Release eine Anpassungsfrist von 30 Tagen ein, statt bestehende Arbeit sofort zu entfernen oder zu verbergen. Teams konnten festlegen, welche Workspaces aktiv blieben, und behielten für die übrigen Lese-, Export-, Abrechnungs- und Wiederherstellungszugriff. Ein bewusst gelöschter Workspace blieb 30 Tage wiederherstellbar. Die endgültige Löschung folgte erst nach diesem Fenster und einer geprüften Bereinigung. Organisationsadministratoren konnten vor der Entscheidung außerdem einen privaten portablen Export erstellen. Das waren die damals eingeführten Wiederherstellungsregeln; für heutige Limits und Aufbewahrung gelten die Angaben im aktuellen Produkt.
Das Action Center priorisiert die nächsten SEO-Schritte
Das Action Center wurde um einen Entscheidungsweg herum neu geordnet: aktuelle SEO-Lage verstehen, unmittelbares Ziel wählen, priorisierte Chancen vergleichen und die für die ausgewählte Arbeit zuständige Fachansicht öffnen. Teams konnten die Priorisierung auf ausgewogene Ziele, Sichtbarkeit, schnelle Chancen, Ranking-Schutz oder technische Verbesserungen ausrichten. Jede Empfehlung zeigte ihre Begründung, die beabsichtigte Wirkung, den geschätzten Aufwand und die verfügbaren Belege, bevor der Nutzer ihr folgte. Die Priorisierung ordnete die vorhandenen Belege; sie garantierte nicht, dass eine vorgeschlagene Maßnahme das erwartete Ergebnis erzielte. Auf kleineren Bildschirmen öffnete sich derselbe Entscheidungsüberblick in einer konzentrierten mobilen Ansicht, ohne den unterstützenden Kontext zu verlieren.
Keyword-Intelligenz und Site Audit arbeiten zusammen
Dieser Release verband Keyword-Datenbank und Site Audit als zwei Teile desselben SEO-Ablaufs. Ein Team konnte von einer Suchchance zu den technischen Befunden einer wichtigen Seite wechseln, betroffene URLs untersuchen und die Belege eines späteren Crawls mit einem früheren Lauf vergleichen. Der Vergleich zeigte Veränderungen zwischen zwei Messungen. Er bewies nicht, dass eine bestimmte Maßnahme die Veränderung verursacht hatte.
Linkpfade im gesamten Crawl mit ihren Belegen
Der Link Explorer verwendete nun das vollständige URL-Inventar eines Crawls statt einer kleinen Stichprobe aus der geladenen Ansicht. Für eine ausgewählte Seite waren die verlinkenden Seiten und jede erfasste Ankertext-Fundstelle sichtbar. Eingehende Links, intern und extern ausgehende Links sowie Selbstverweise blieben getrennt. Platzierung des Ankertexts und DOM-Position dienten als Beleg. Seiten mit vielen Verbindungen öffneten sich in einer kompakten Clusteransicht mit getrennten Summen für Beziehungen und Fundstellen. Ein Cluster ließ sich bis zu seinen konkreten URLs aufklappen; die ausführliche Beziehungsansicht blieb erhalten. Externe eingehende Links waren als Backlink-Daten aus einer eigenen Quelle gekennzeichnet und wurden nicht aus dem Website-Crawl abgeleitet.
Ein klareres Cockpit für die SEO-Arbeit
Das Workspace-Dashboard wurde auf Keyword-Datenbank und Site Audit ausgerichtet. Es führte Keyword-Abdeckung, Suchintention, verfügbare Signale zum Website-Zustand, die Zahl gecrawlter URLs und aktuelle Prioritäten in einer Übersicht zusammen. Jeder Wert führte in den zuständigen Produktbereich. Das Dashboard blieb damit ein Einstieg in die zugrunde liegenden Belege und gab sich nicht als vollständige Diagnose aus.
Ein übersichtlicheres SEO-Cockpit
Dieses ergänzende Dashboard-Update führte Zusammenfassungen aus Keyword-Datenbank und Site Audit in einer responsiven Übersicht zusammen. Wichtige Summen, verfügbare Ranking-Signale, Trends technischer Probleme, Gewinne, Verluste und aktuelle Prioritäten ließen sich prüfen, bevor die zugrunde liegende Arbeitsansicht geöffnet wurde. Die Übersicht unterschied außerdem zwischen aktuellen Daten und nicht verfügbarer Historie. Ein leeres Diagramm wurde als fehlender Beleg gekennzeichnet und erweckte nicht den Eindruck eines Fortschritts, der noch gar nicht gemessen worden war.
Site Audit Monitoring ist leichter zu prüfen
Site Audit Monitoring begann mit einfacheren empfohlenen Voreinstellungen. Erweiterte Zeitplan-Einstellungen blieben verborgen, bis sie tatsächlich gebraucht wurden. Die Alert-Historie behandelte außerdem die Annahme durch den E-Mail-Dienst nicht länger als Beleg für eine Zustellung. Sie unterschied zwischen bestätigter Zustellung, Zurückweisung, Beschwerde, erneutem Versuch und einem Digest, der noch in der Warteschlange lag. Teams sahen dadurch, was über eine Benachrichtigung bekannt war, statt ihre Ankunft nur anzunehmen.
Content-Erstellung folgt dem Briefing direkter
Der damalige Writer konnte nun mit dem Briefing des Nutzers beginnen, ohne Research als ersten Schritt zu erzwingen. Er zeigte, ob Projektwissen aktiv war, und behandelte klare Vorgaben zu Ausschlüssen, Tonalität, Format und Themenfokus vorrangig gegenüber allgemeinen SEO-Vorschlägen. Aufbau, Entwurf und Optimierung folgten damit von Anfang an denselben Anweisungen. Ein Trust Panel machte die Grenzen eines Entwurfs sichtbar. Es zeigte fehlende Stützung, schwache Belege, geprüfte oder angepasste riskante Aussagen und Abweichungen des Optimizers von Belegen oder Nutzervorgaben. Wiederkehrende Schreibregeln ließen sich korrigieren, anheften, herabstufen oder vergessen; das aktuelle Projektbriefing konnte eine gespeicherte Regel überstimmen. Vor Review und Scoring konnte der Ablauf eine unbelegte riskante Aussage entfernen, eine unbelegte absolute Formulierung abschwächen oder sie vorsichtiger formulieren, wenn das vorhandene Projektwissen diese Änderung trug. Präzisionsänderungen, Optimizer-Neufassungen und manuelle Editor-Vorschläge hielten dieselbe Grenze ein. Sie sollten ausdrückliche Ausschlüsse respektieren und keine konkreten Aussagen ergänzen, die durch das verfügbare Projektwissen nicht gestützt waren. Qualitätsprobleme aus echten Durchläufen ließen sich zusammenfassen, ohne private Artikeltexte oder Projektwissen in einen Bericht zu kopieren. Das sichere QA-Paket erfasste schwache Belege, unbelegte Aussagen, Abweichungen des Optimizers, ignorierte Vorgaben und dünne Themenabdeckung; ein Snapshot konnte im Workspace-Verlauf gespeichert werden. Eine RAG-QA-Ansicht im Brain ergänzte Review-Warteschlange, Zusammenfassungen wiederkehrender Muster, Golden-Case-Entwürfe, Ansichten der Wissensverbindungen, dokumentierte Browser-Prüfungen und Kalibrierungspakete. Eine vorgeschlagene Qualitätsänderung musste weiterhin ausdrücklich geprüft werden, bevor sie das Live-Verhalten beeinflussen durfte. Dieser Eintrag dokumentiert den damaligen Writer- und Brain-Ablauf; diese Bereiche gehören nicht zum heutigen Kernversprechen von Contextter.
Site-Audit-Grundlage für Website-Crawls
Dieser Release führte den ersten Workspace-Ablauf für technische Website-Audits ein. Ein Team konnte eine Website hinzufügen, den Crawl konfigurieren, die erwartete Belastung des vorausbezahlten Guthabens prüfen und den Lauf anschließend starten. Der Ergebnisbereich führte URL-Inventar, gruppierte Befunde, Belege zu einzelnen URLs, interne Links und die Site-Tree-Ansicht zusammen, ohne diese erste Grundlage als vollständige Diagnose jedes technischen SEO-Problems auszugeben.
Keyword-Datenbank: Discovery, Tracking und zuverlässigere Jobs
Dieser Release verband Discovery, gespeicherte SERP-Historie, Wettbewerber-Snapshots, Score-Signale, Aktivitätsverlauf, wiederkehrende Positionsprüfungen und klarere Kostenhinweise innerhalb der Keyword-Datenbank. Ein Keyword konnte von der ersten Idee in die überwachte Auswahl wechseln, ohne zwischen getrennten Werkzeugen kopiert zu werden. Bei kostenpflichtigen Datenaktionen war der Kostenkontext besser sichtbar. Das hier beschriebene wiederkehrende Tracking gehörte zum Produktstand dieses Datums und ist keine Aussage über den heutigen Funktionsumfang von Contextter.
Keyword-Workbench mit klarerer Oberfläche
Die Keyword-Datenbank wurde für große Listen neu geordnet. Metriken, Tabellenspalten, Zeilenaktionen und Zustände der Mehrfachauswahl folgten einer klareren visuellen Reihenfolge. Chancen ließen sich vergleichen, ohne bei jedem Schritt die aktuelle Position in der Liste zu verlieren. Der Release änderte Darstellung und Bedienzustände der Workbench; eine neue Keyword-Metrik kam nicht hinzu.
Öffentliche Inhalte verlässlicher veröffentlichen
Die Veröffentlichungsprüfungen für Blog, Glossar und öffentliche Service-Hinweise wurden ausdrücklicher. Redakteure konnten fehlende Übersetzungen erkennen, einen Eintrag in der Vorschau prüfen und seinen Veröffentlichungsstatus bestätigen, bevor er auf einer öffentlichen Seite erschien. Der Release ersetzte keine redaktionelle Freigabe. Er machte unvollständige Übersetzungen und Probleme mit der Veröffentlichungsreife früher sichtbar.
Writer, Research und Brain arbeiten stabiler zusammen
Writer, Research und Digital Brain waren bei längeren Sitzungen weniger anfällig für widersprüchliche Arbeitsstände. Speichern, Wiederherstellen, KI-gestützte Änderungen, Research-Sitzungen und Brain-Ansichten berücksichtigten neuere Arbeit sorgfältiger, wenn Nutzer zwischen Planung und Schreiben wechselten. Das Update verringerte das Risiko, veralteten Kontext wiederherzustellen oder eine neuere Änderung zu überschreiben. Es versprach nicht, dass Arbeit unter allen Umständen erhalten blieb. Diese Funktionen gehörten zum damaligen Writer- und Brain-Ablauf.
Teams, Abrechnung und Freigaben wurden klarer
Dieser Release zog klarere Grenzen zwischen Teamverwaltung, Organisationsabrechnung, Einladungen, Kundenzugriff und redaktioneller Prüfung. Änderungen an Konten und Zugriffen wurden einheitlicher behandelt; Content- und Research-Arbeit durchlief einen deutlicheren Freigabezyklus. Teams konnten vor einer Aktion leichter erkennen, was auf Prüfung wartete und welcher Zugriffs- oder Abrechnungskontext galt.
Öffentliche Website und Help Center aufgeräumt
Dieser Release korrigierte Unstimmigkeiten auf der öffentlichen Website, im Hilfe-Center, im Glossar, in der Sitemap und auf lokalisierten Seiten. Navigationsbezeichnungen, Metadaten, Übersetzungen und mobile Layouts folgten verlässlicher denselben Regeln. Öffentliche Routen ließen sich dadurch leichter finden und nutzen. Es war eine Überarbeitung von Darstellung und Auffindbarkeit, keine Behauptung, sämtliche Artikel und Übersetzungen seien vollständig.
SEO-Audit und Research-Grundlagen ausgebaut
Mit diesem Release bekam Contextter seinen ersten Arbeitsbereich für Onpage-Audits. Gleichzeitig machte Research deutlicher, wenn nur unvollständige oder uneinheitliche Quelldaten vorlagen. Berichte unterschieden zwischen dem Zustand der Quellen, Befunden zu einzelnen URLs und fehlenden Belegen. Ein lückenhafter Datensatz vermittelte damit nicht dieselbe Sicherheit wie ein gut gestütztes Ergebnis. Teams konnten erkennen, wo die Belege für eine Entscheidung reichten und wo noch eine weitere Quelle oder eine neue Prüfung nötig war.
Übersichtlichere Dashboards und Produktsteuerung
Die Workspace-Dashboards wurden neu geordnet, damit wichtige Zustände auf weniger Ansichten erkennbar waren. Abrechnung und freigeschaltete Funktionen ließen sich leichter unterscheiden. Das Hilfe-Center wurde zugleich nach Onboarding, täglicher Arbeit, Teamnutzung und Problemlösung gegliedert. Der Release änderte die Darstellung vorhandener Informationen. Neue Messwerte oder automatische Empfehlungen kamen nicht hinzu.
Keyword-Datenbank als echte Workbench
Die Keyword-Datenbank vereinte Import, Tags, Cluster, gezielt angeforderte SERP-Belege, Detailansichten und Sammelaktionen in einem Arbeitsbereich. Teams konnten ein Keyword-Set zuerst ordnen, die vorhandenen Wettbewerbsbelege prüfen und anschließend entscheiden, für welche Begriffe sich eine kostenpflichtige Aktualisierung lohnte. Die gesamte Liste musste nicht mehr vorsorglich angereichert werden.
Research Intelligence und Keyword-Chancen
Die Research-Ansicht zeigte nun Suchintention, thematische Passung und fehlende Abdeckung neben erweiterten Keyword-Ideen. Hinweise wie "easy win", "competitive" und "needs more work" gruppierten die Chancen für die nächste Prüfung. Sie halfen bei der Priorisierung, waren aber keine Zusage für ein Ranking oder den tatsächlich nötigen Aufwand.
Bessere Content-Führung und Markenstimme
Der damalige Schreibprozess konnte ein genaueres Markenstimmen-Profil, passendere Vorschläge für interne Links und die im Workspace hinterlegten Standards wiederverwenden. Teams mussten dieselben Vorgaben zu Stil, Qualität und Verlinkung nicht bei jedem neuen Content-Projekt erneut formulieren. Diese Funktionen gehörten zum damaligen Writer und beschreiben nicht den heutigen Contextter-Ablauf.
Workspace-Standards und Wissensaufnahme
Neue Projekte konnten Zielscore, Autorenprofil, Sprache und erwarteten Wortumfang aus dem Workspace übernehmen. Auch Website-Inhalte wurden zuverlässiger für den Digital Brain aufgenommen. Der Writer erhielt dadurch eine beständigere Grundlage für Markenstimme und Content-Hinweise, ohne dass Teams dieselben Einstellungen für jedes Projekt neu eingeben mussten. Das waren Funktionen des damaligen Ablaufs.
Team-Workspaces und EUR-Abrechnung
Mit diesem Release kamen Organisationen, Rollen, Einladungen, Zugriffe auf Projekte und eine gemeinsame Abrechnung hinzu. Agenturen und interne Teams konnten Marken oder Kunden innerhalb einer Workspace-Struktur voneinander trennen. Die Nutzung erschien in Euro statt in abstrakten Credits. So ließ sie sich leichter mit den tatsächlichen Ausgaben vergleichen.
Digital Brain, Scoring und Optimizer wachsen zusammen
Der Digital Brain konnte verwandte Fakten nun verbinden und stärkere Quellen bevorzugen, wenn er den Writer mit Kontext versorgte. Auch die Optimierung wurde abschnittsbezogen: Eine schwache Passage ließ sich mit den Belegen für genau diesen Abschnitt überarbeiten, statt den gesamten Artikel pauschal neu zu formulieren. Diese Funktionen gehörten zum Writer- und Brain-Ablauf dieser Zeit; der Eintrag beschreibt nicht das heutige Produkt.
Research- und Qualitätsgrundlage für SEO-Content
Dieses Release legte die erste gemeinsame Grundlage für beleggestützte Content-Arbeit. Der Research-Ablauf konnte Hinweise aus Suchergebnissen, Community-Diskussionen, wissenschaftlichen Quellen, Videos und öffentlichen Webseiten zusammenführen. Ein begleitender Score zeigte Relevanz, faktische Grundlage, Lesbarkeit und grundlegende SEO-Prüfungen getrennt an. So sahen Teams, warum ein Entwurf noch Arbeit brauchte, statt nur eine unerklärte Gesamtzahl zu erhalten.
Produktoberfläche als stabile Grundlage
Mit diesem Release entstand das visuelle System der frühen Contextter-Oberfläche: kontrastreichere Flächen, einheitliche Abstände, gemeinsam genutzte Komponenten und Muster, die auch im dunklen Modus funktionierten. Dichte SEO-Daten ließen sich leichter überblicken, und beim Wechsel zwischen Projekten und dem Schreibbereich änderte sich die Oberfläche weniger stark.