Technische SEO-Audit-Checkliste

Notiere Hosts, Protokolle, Verzeichnisse, Parameterregeln und Seitentypen, die Du prüfst. Entscheide bewusst, ob JavaScript gerendert wird, ob Login-Bereiche gehören und ob robots.txt respektiert wird. Halte Datum und Einstellungen fest. Sonst kann ein Unterschied zwischen zwei Crawls schlicht von anderen Tool-Einstellungen stammen.

Nimm zentrale Vorlagen als Stichprobe: Startseite, Kategorie, Produkt oder Angebot, Artikel, Suche, Pagination und Fehlerseite. Ein Crawl ist ein Modell Deiner Website, nicht die Website selbst. Vergleiche Resultate mit Browser, HTTP-Antwort und bei Bedarf mobiler Darstellung. Damit vermeidest Du Schlussfolgerungen, die nur auf einer Tool-Interpretation beruhen.

• URL-Muster ein- und ausschliessen.
• Kritische Seiten als Baseline dokumentieren.
• Zugriffsgrenzen und Crawl-Einstellungen festhalten.

Prüfe, ob wichtige Seiten über normale interne Links erreichbar sind und ob diese Links die beabsichtigte HTTP-Antwort liefern. Untersuche kaputte Links, Ketten und Schleifen bei Weiterleitungen sowie Links auf nicht-kanonische Varianten. Eine Weiterleitung ist nicht grundsätzlich falsch. Entscheidend ist, ob ihr Ziel dem früheren Zweck entspricht und ob sich unnötige Ketten kürzen lassen.

Vergleiche intern gefundene URLs mit Sitemaps und Deiner Informationsarchitektur. Verwaiste Seiten sind für Menschen und Crawler schwer auffindbar, während endlose Filter oder Session-Parameter Crawl-Aufmerksamkeit binden können. Entferne kein Muster nur wegen seiner Menge: Kläre zuerst, ob es eine sinnvolle Nutzerreise oder eine bewusst indexierbare Sammlung abbildet.

• 200-, 3xx-, 4xx- und 5xx-Muster je Vorlage testen.
• Wichtige, tief verlinkte und verwaiste Seiten finden.
• Filter, Parameter und Pagination kontextbezogen prüfen.

Kontrolliere pro wichtigem URL-Typ robots-Meta-Tags, X-Robots-Tag-Header, Canonical-Elemente und die finale Antwort nach Weiterleitungen. Ein Canonical ist ein Hinweis zur Konsolidierung, keine Universalreparatur. Er sollte auf eine erreichbare, indexierbare Seite mit gleichem oder sehr ähnlichem Inhalt zeigen und zu internen Links sowie Sitemaps passen.

Nutze URL-Prüfung und Indexierungsberichte der Search Console als einen Beleg für verifizierte Properties. Sie können Googles gewählten Canonical oder einen Ausschlussgrund zeigen, sind aber kein Echtzeit-Audit aller URLs. Ist eine Seite bewusst ausgeschlossen, dokumentierst Du den Grund. Ist sie es nicht, prüfst Du Status, Direktiven, Canonical, Links und gerenderten Inhalt vor einer Änderung.

• robots.txt auf Konflikte mit gewünschtem Crawling prüfen.
• noindex, Canonicals und Header auf Live-Seiten kontrollieren.
• In Sitemaps nur kanonische, gewollte URLs führen.

Jede zentrale Seite braucht eine klare Aufgabe sowie einen stimmigen Titel, eine Hauptüberschrift und sichtbaren Inhalt. Doppelte Titel weisen oft auf Vorlagen hin, aber Einzigartigkeit allein ist keine Qualität. Schau auf Suchergebnis, Zielgruppe und Nutzen der Seite. Beschreibende Linktexte und sinnvolle Alternativtexte helfen, ersetzen jedoch keinen hilfreichen Inhalt.

Validiere strukturierte Daten gegen sichtbare Angaben und passendes Vokabular. Markup beschreibt Inhalt, verspricht aber kein Rich Result. Erfinde keine Eigenschaften und nutze Schema nicht als Ersatz für fehlende Informationen. Nach Vorlagen-Änderungen prüfst Du repräsentative Seiten und die JSON-LD-Syntax, danach beobachtest Du vorhandene Enhancement-Berichte in der Search Console.

• Titel, H1 und Seitennutzen zusammen beurteilen.
• Doppelte, dünne und leer gerenderte Vorlagen finden.
• Markup mit sichtbarem Inhalt und Schema.org abgleichen.

Felddaten zeigen erlebte Performance, Labortools helfen bei der Ursachenanalyse. Core Web Vitals betreffen Laden, Reaktion und visuelle Stabilität, werden aber auch von Gerät, Netzwerk, Cache und Nutzungspfad beeinflusst. Ein guter Lab-Score beweist nicht, dass alle Besucher dieselbe Erfahrung haben. Ein schlechter Lauf ist ein Anlass zur Untersuchung, kein Urteil.

Prüfe Muster hinter langsamen Seiten: blockierende Ressourcen, grosse Bilder, ungenutztes JavaScript, Drittanbieter-Tags, Serverantwort und nachladende Elemente. Teste relevante Vorlagen statt nur die Startseite. Sprich Änderungen mit der Entwicklung ab, weil Cache, Bildverarbeitung und Script-Loading auch Funktion, Datenschutz und Messung betreffen können.

• Feldbeobachtung und Labordiagnose unterscheiden.
• Wichtige Vorlagen und Gerätesituationen testen.
• Nach Deployments erneut prüfen, ohne Ranking-Versprechen.

Bei mehrsprachigen Websites braucht jede Variante echten Nutzen in ihrer Sprache, und der Sprachwechsel muss für Menschen erreichbar bleiben. Setze hreflang nur für gleichwertige Alternativen ein, mit gültigen URLs und wechselseitigen Verweisen inklusive Selbstreferenz. Ein generischer Sprachumschalter oder Länderredirect darf Nutzern und Crawlern den Weg zur passenden Variante nicht versperren.

Schweizer Standarddeutsch verdient dieselbe redaktionelle Sorgfalt wie jede andere Locale: Schreib natürlich für Deine Zielgruppe, beachte lokale Kontakt- und Rechtsangaben und lass Dich nicht auf Wortersatz durch Maschinen. Teste hreflang-Cluster nach Releases seitengenau. Ein fehlender Rückverweis kann den Cluster stören, deshalb prüfst Du Produkt-, Content- und Nutzungsseiten.

• ISO-Sprachcodes und optionalen Regionscode korrekt verwenden.
• Alternativen crawlbar und canonical-konsistent halten.
• Rückverweise und den Sprachwechsel testen.