URL-Audit: Was geprüft wird und wie Sie den Bericht nutzen

Was ein URL-Audit analysiert

Ein URL-Audit beginnt mit genau der URL, die Sie eingeben. Der Server ruft die Seite ab, folgt zulässigen Weiterleitungen, speichert die endgültige URL und Antwort und analysiert das HTML, das für den Audit verfügbar war.

Abhängig von der Seite und den in diesem Audit verfügbaren Nachweisen kann der Bericht unter anderem folgende Signale enthalten:

• HTTP-Status, endgültige URL, Weiterleitungen und Antwortzeit;
• Title-Tag und Meta-Description;
• Canonical-Angaben und Prüfung des Canonical-Ziels;
• indexierungsbezogene Anweisungen;
• H1-/H2-Struktur und Überschriftentexte;
• HTML-Sprache und hreflang-Angaben;
• erkannte strukturierte Daten in JSON-LD;
• Open-Graph- und Social-Preview-Felder;
• Favicon- oder Icon-Angaben;
• ausgewählte Nachweise zu Security Headers;
• ALT-Signale von Bildern;
• interne Links, Ankertext-Kontext und ausgewählte Zielprüfungen;
• Inhaltslänge und weitere seitenbezogene Prüfsignale.

Der Bericht geht nicht davon aus, dass jede erkannte Bedingung automatisch ein SEO-Problem ist. Die Bedeutung eines Signals hängt davon ab, wie eindeutig es gemessen werden kann und ob zusätzlicher Seitenkontext erforderlich ist.

Website Health ist nicht einfach die Anzahl aller Warnungen

Site SEO Audit trennt die Befunde in drei praktische Gruppen.

Issue bedeutet, dass ein objektives und umsetzbares Problem erkannt wurde. Bestätigte Issues können Website Health beeinflussen.

Needs review bedeutet, dass ein Signal erkannt wurde, das zuerst im Kontext der Seite oder des Unternehmens bewertet werden sollte. Es senkt Website Health nicht automatisch.

Opportunity ist eine optionale Verbesserungsmöglichkeit. Sie kann sinnvoll sein, aber ihr Fehlen wird nicht automatisch als Fehler bewertet.

Dadurch wird verhindert, dass ein Bericht die Bewertung nur deshalb verschlechtert, weil eine Seite nicht jede mögliche Empfehlung erfüllt.

Evidence zeigt, warum ein Befund entstanden ist

Der Bericht speichert Nachweise aus der geprüften Antwort, damit Sie sehen können, was einen Befund ausgelöst hat, anstatt nur eine allgemeine Warnung zu erhalten.

Die Evidence kann zum Beispiel den angegebenen Canonical, ein aufgelöstes Canonical-Ziel, erkannte Überschriftentexte, eine Bildquelle mit ihrem ALT-Status oder ein internes Ziel zeigen, das weitergeleitet wurde oder nicht erreichbar war.

Einige unterstützende Prüfungen sind absichtlich begrenzt. Ein fokussierter URL-Audit kann ausgewählte Canonical-, hreflang- oder interne Ziele prüfen, wird dadurch aber nicht zu einem unbegrenzten Crawl der gesamten Website.

Erreichbare und unauffällige Ziele werden häufig zusammengefasst, statt einzeln aufgelistet zu werden. Detaillierte Zeilen sind vor allem bei Weiterleitungen, nicht erreichbaren Zielen, mehrdeutigen Angaben oder prüfbedürftigen Fällen sinnvoll.

Ältere gespeicherte Audits können weniger detaillierte Evidence enthalten, wenn sie vor einer neueren Nachweisstruktur erstellt wurden. Führen Sie einen Re-scan aus, wenn Sie das aktuelle Prüfmodell und aktuelle Nachweise benötigen.

Ohne Konto starten und im Workspace weiterarbeiten

Sie können einen Gast-URL-Audit starten, ohne zuerst ein Konto zu erstellen.

Der erste Bericht soll das Seitenergebnis und wichtige Prioritätssignale zeigen, bevor eine Registrierung erforderlich ist. Das Konto wird für den vollständigen Arbeitsablauf rund um den Audit verwendet, einschließlich vollständiger Fix Queue, gespeicherter Evidence, Verlauf und Re-scan.

Gespeicherte Audits eines Mitglieds bleiben im Bereich SEO Audits entsprechend den Verlaufsregeln des aktuellen Tarifs verfügbar.

Re-scan überprüft die Seite nach einer Änderung

Ein Re-scan führt den URL-Audit erneut aus, anstatt davon auszugehen, dass eine umgesetzte Änderung funktioniert hat.

Der Vergleich kann zeigen, welche Befunde verschwunden sind, welche weiterhin bestehen und welche im neuen Audit hinzugekommen sind. Dadurch entsteht der Arbeitsablauf:

Audit → Evidence prüfen → beheben → Re-scan → vergleichen.

Ein Re-scan verwendet einen URL-Audit-Credit. Ein fehlgeschlagener Seitenabruf verbraucht keinen erfolgreichen Audit-Credit.

Die Anzahl verfügbarer URL-Audit-Credits hängt vom aktiven Tarif ab. Verwenden Sie Plans & Limits für den aktuellen Umfang, statt sich auf Angaben in einem älteren gespeicherten Bericht zu verlassen.

URL Audit und Site Scan lösen unterschiedliche Aufgaben

URL Audit ist eine fokussierte Diagnose auf Seitenebene.

Site Scan ist der Mehrseiten-Workflow für ein verifiziertes Project. Er ist dafür vorgesehen, mehrere URLs zu untersuchen, die Abdeckung zu zeigen, wiederkehrende Befunde zu erkennen und websiteweite Muster sowie Veränderungen zu analysieren.

Ein URL-Audit kann für die Validierung von Seitennachweisen eine begrenzte Anzahl zusätzlicher Anfragen durchführen. Dadurch wird er jedoch nicht zu einem vollständigen Website-Crawl.

Verwenden Sie URL Audit, wenn eine wichtige Seite detailliert untersucht werden soll. Verwenden Sie Site Scan, wenn Sie feststellen möchten, wie sich ein Problem auf mehrere Seiten der Website verteilt.

Was ein URL-Audit nicht garantieren kann

Ein automatisierter Audit liefert Nachweise, aber keine Garantie für Rankings oder vollständige SEO-Korrektheit.

Der Kern-Audit analysiert die Antwort und das HTML, die dem Server zur Verfügung stehen. Inhalte oder Zustände, die ausschließlich nach einer Interaktion im Browser entstehen, können daher nicht immer genauso dargestellt werden wie in einer vollständig gerenderten Nutzersitzung.

Auch eine Empfehlung kann menschlichen Kontext erfordern. Eine kurze Seite ist nicht automatisch schlecht, ein langer Titel ist nicht automatisch falsch und das Vorhandensein strukturierter Daten beweist nicht, dass das Markup für diese Seite geeignet ist.

Bearbeiten Sie zuerst bestätigte Probleme, prüfen Sie anschließend kontextabhängige Signale und verwenden Sie Website Health als Priorisierungshilfe, nicht als Selbstzweck.

Gehen Sie bei der Prüfung eines URL-Audits so vor:

• bestätigen Sie, dass die endgültig geprüfte URL der Seite entspricht, die Sie testen wollten;
• prüfen Sie zuerst den HTTP-Status und mögliche Weiterleitungen;
• bearbeiten Sie bestätigte Issues vor optionalen Verbesserungen;
• öffnen Sie Evidence, bevor Sie die Seite ändern, damit klar ist, was tatsächlich erkannt wurde;
• bewerten Sie Needs-review-Befunde im Kontext des Zwecks der Seite;
• prüfen Sie bei Bedarf Canonical, Indexierbarkeit, Überschriften, Sprache, Links, Bilder und weitere gespeicherte Seitensignale;
• nehmen Sie eine gezielte Änderung vor, statt mehrere unabhängige Dinge gleichzeitig zu verändern;
• führen Sie nach der Veröffentlichung der Änderung einen Re-scan aus;
• vergleichen Sie behobene, verbleibende und neue Befunde;
• wechseln Sie zu Site Scan, wenn dasselbe Problem wahrscheinlich viele URLs betrifft.

Optimieren Sie nicht ausschließlich für eine höhere Website-Health-Zahl. Das sinnvolle Ergebnis ist eine Seite mit weniger bestätigten Problemen, klareren Nachweisen und Änderungen, deren Wirkung überprüft werden kann.