Technisches SEO ermöglicht Suchmaschinen, die gewünschten Seiten zu entdecken, abzurufen und zu verstehen. Beginnen Sie mit erreichbaren URLs, korrekten Statuscodes und widerspruchsfreien Indexierungssignalen. Verbinden Sie diese Seiten anschließend durch eine hilfreiche Navigation. Eine schnelle Seite mit falschem Canonical oder versehentlichem noindex hat weiterhin ein grundlegendes Sichtbarkeitsproblem.
Dieser Leitfaden vermittelt Grundlagen für Entwickler und Websitebetreiber, keine Ranking-Garantie. Sichtbarkeit hängt auch von Inhalt und Relevanz ab. Das Ziel hier ist enger und überprüfbar: Die vorgesehene Seite soll den vorgesehenen Inhalt mit übereinstimmenden Signalen zu Identität und Zweck ausliefern.
Trennen Sie Entdeckung, Crawling, Indexierung und Ranking
Entdeckung bedeutet, dass eine Suchmaschine eine URL kennenlernt, etwa durch einen Link oder eine Sitemap. Crawling ist der Abruf dieser Adresse. Beim Rendering kann JavaScript ausgeführt werden, um den weiterverarbeiteten Inhalt zu erzeugen. Indexierung umfasst Inhaltsanalyse und die Entscheidung über seine Darstellung im Index. Ranking ist die spätere Auswahl und Reihenfolge von Ergebnissen für eine Suchanfrage.
Diese Schritte sind voneinander zu unterscheiden. Ein Sitemap-Eintrag wird nicht zwangsläufig sofort gecrawlt; eine erfolgreich abgerufene Seite wird nicht garantiert indexiert. Eine indexierte Seite erscheint auch nicht automatisch für den gewünschten Suchbegriff. Bestimmen Sie zunächst, an welcher Stelle die Belege enden, bevor Sie unabhängige Einstellungen verändern.
Wählen Sie repräsentative Vorlagen: Startseite, Kategorie, Artikel oder Produkt, Paginierung, Sprachvariante, Weiterleitung und nicht vorhandene Seite. Prüfen Sie konkrete Beispiele und ihre Erzeugungsregeln. Eine korrekt konfigurierte Startseite beweist nicht, dass Tausende parametrisierte URLs richtig funktionieren.
Notieren Sie pro Beispiel erwarteten Status, Indexierbarkeit, Canonical und Herkunft interner Links. Vergleichen Sie diese Erwartung mit HTTP-Antwort und Search Console. Ein solches Inventar ist hilfreicher als eine lange Warnungsliste ohne Entscheidung darüber, was die einzelne URL eigentlich leisten soll.
Verwenden Sie robots.txt für Crawling, nicht als Zugriffsschutz
Eine robots.txt weist unterstützte Crawler an, welche Ressourcen sie anfordern dürfen. Sie authentifiziert keine Besucher und schützt keine vertraulichen Inhalte. Eine gesperrte URL kann über Links bekannt bleiben. Wird der Abruf blockiert, kann Google die Anweisungen innerhalb der Seite nicht sehen.
Diese beispielhafte robots.txt im Stammverzeichnis sperrt einen internen Suchpfad und nennt eine Sitemap:
User-agent: *
Disallow: /internal-search/
Sitemap: https://example.com/sitemap.xmlDas Beispiel ist keine pauschale Empfehlung, sämtliche Suchseiten zu sperren. Entscheiden Sie, ob diese Seiten Crawling-Steuerung, einen Indexausschluss oder eine andere URL-Strategie benötigen. Soll noindex eine Seite ausschließen, muss Google diese Anweisung abrufen können. Eine vorherige Sperre kann genau die notwendige Prüfung verhindern.
Sperren Sie keine CSS-, JavaScript- oder Bildressourcen, die wichtiges öffentliches Material zum Rendern benötigt. Eine Regel für ein altes Asset-Verzeichnis kann nach einem Deployment aktuelle Vorlagen treffen. Kontrollieren Sie den konkreten Hostnamen, das Protokoll und den Pfad. Weitreichende Platzhalter dürfen nicht mehr erfassen als geplant.
Vertrauliche Inhalte benötigen echte Zugriffskontrollen. Für eine öffentliche, weiterhin nutzbare Seite, die nicht in der Suche erscheinen soll, verwenden Sie eine Indexierungsanweisung. Google unterstützt dieses Meta-Element im Kopf einer crawlbaren Seite:
<meta name="robots" content="noindex">Der HTTP-Header X-Robots-Tag kann entsprechende Anweisungen auch für PDF-Dateien und andere Ressourcen ausdrücken. Prüfen Sie Header und Markup gemeinsam. Widersprüche können ein restriktiveres Ergebnis erzeugen, als ein einzelnes sichtbares Element vermuten lässt. Die standardmäßige Indexierungserlaubnis erfordert kein zusätzliches index auf jeder Seite.
Lassen Sie Statuscodes das wirkliche Ergebnis beschreiben
Die Serverantwort sollte zwischen nützlichem Inhalt, einer verschobenen Seite, fehlendem Inhalt und einem vorübergehenden Ausfall unterscheiden. Liefert jeder Pfad dieselbe erfolgreiche Anwendungshülle, bleiben diese Unterschiede möglicherweise bis zur JavaScript-Ausführung verborgen. Das erschwert Fehlersuche und Suchverarbeitung.
Diese Tabelle dient als Entscheidungshilfe, nicht als Ersatz für das HTTP-Verhalten Ihrer Anwendung:
| Situation | Typische Antwort | Was zu prüfen ist |
|---|---|---|
| Verfügbare nützliche Seite | 200 |
Der Inhalt entspricht der Erwartung |
| Dauerhaft verschobenes Äquivalent | 301 oder 308 |
Das Ziel ist der passende Ersatz |
| Vorübergehende Verschiebung | 302 oder 307 |
Die vorübergehende Wirkung ist beabsichtigt |
| Fehlender oder entfernter Inhalt | 404 oder 410 |
Keine irrelevante Erfolgsseite ersetzt ihn |
| Vorübergehender Serverfehler | Passender 5xx-Status |
Überwachung erkennt und behebt den Ausfall |
Eine 200-Antwort, die nur einen Fehlertext enthält, kann als Soft 404 gelten. Ein anderer Text bei unveränderter Antwort beseitigt den Widerspruch nicht. Ebenso wird die Startseite nicht zum passenden Ersatz für jedes entfernte Produkt, nur weil sämtliche alten URLs dorthin weiterleiten.
Bevorzugen Sie eine direkte Weiterleitung zur endgültigen gleichwertigen Adresse. Ketten verursachen weitere Anfragen, erschweren Tests und bieten zusätzliche Möglichkeiten für widersprüchliche Regeln. Prüfen Sie Parameter, alte Regeln für abschließende Schrägstriche und HTTP-zu-HTTPS-Wechsel. Behalten Sie historische URLs bei, wenn sie weiterhin passenden Inhalt liefern. Ein neues Design verlangt keine neue Adresse.
Untersuchen Sie anhaltende Serverfehler vor kleineren Metadatenkorrekturen. Der Leitfaden zur Serverantwortzeit unterscheidet Ursprungsverzögerungen und Auslieferungsprobleme, die Besucher und zuverlässige Abrufe betreffen.
Stimmen Sie Canonicals mit Links und Weiterleitungen ab
Kanonisierung bestimmt den bevorzugten Vertreter unter doppelten oder sehr ähnlichen Seiten. Ein Canonical ist ein Signal, kein Befehl, der alle anderen Belege überstimmt. Google kann eine andere Adresse auswählen, wenn Inhalte und Signale dorthin weisen.
Dieses HTML legt das beabsichtigte Canonical einer Beispielanleitung fest:
<link rel="canonical" href="https://example.com/guides/caching/">Verwenden Sie eine absolute URL und dieselbe Entscheidung in Markup, internen Links, Weiterleitungen und Sitemap. Nennt die Sitemap eine Adresse, das Template eine andere und die Navigation eine dritte, liegt der Fehler in der Architektur. Ein weiteres Tag löst diesen Widerspruch nicht.
Ein selbstreferenzielles Canonical kann die Identität der bevorzugten Seite ausdrücklich festhalten. Tracking-Varianten können bei gleichwertigem Inhalt auf diese Seite verweisen. Kanonisieren Sie einen eigenständigen Artikel nicht auf eine Kategorie, nur weil diese wirtschaftlich wichtiger erscheint. Canonicals vereinigen keine unterschiedlichen Suchabsichten und ersetzen keinen fehlenden Inhalt.
Auch Übersetzungen erfordern Sorgfalt. Eine vollständig lokalisierte Seite hat üblicherweise eine eigene kanonische Identität; hreflang beschreibt ihre Sprachausgaben. Verweisen sämtliche Übersetzungen kanonisch auf Englisch, untergräbt dies die gewünschte Trennung. Regionale Duplikate derselben Sprache können eine speziellere Regel brauchen, die sich aus Inhalt und Zielgruppe ableitet.
Vergleichen Sie in Search Console das angegebene mit dem von Google ausgewählten Canonical. Eine Abweichung ist der Beginn einer Untersuchung. Prüfen Sie Weiterleitungen, doppelte Inhalte, widersprüchliche Links und ältere Crawling-Daten, bevor Sie wiederholt Indexierung beantragen.
Erstellen Sie Sitemaps aus tatsächlich gewünschten Indexseiten
Eine XML-Sitemap unterstützt die Entdeckung und liefert ein Kanonisierungssignal. Sie ist kein Indexierungsbefehl. Nehmen Sie bevorzugte, erreichbare URLs auf, die in die Suche gehören. Offensichtliche Weiterleitungen, Fehlerseiten und bewusst mit noindex markierte Seiten gehören nicht hinein.
Erzeugen Sie die Sitemap aus demselben Inhaltsinventar, das die Website veröffentlicht. Eine zusätzliche manuelle Liste kann abweichen: Gelöschte Seiten bleiben enthalten, neue Bereiche fehlen. Prüfen Sie nach dem Deployment Stichproben auf Hostname, HTTPS, Sprachpräfix und Schrägstrichkonvention.
Verwenden Sie lastmod nur für tatsächliche relevante Änderungen. Alle Daten bei jedem Build zu ersetzen macht die Angabe weniger aussagekräftig. Eine neue Jahreszahl im Footer entspricht keiner inhaltlichen Überarbeitung aller Seiten. Verknüpfen Sie Veröffentlichungs- und Änderungsdaten mit echten Inhaltsereignissen.
Reichen Sie die Sitemap in Search Console ein und beurteilen Sie Verarbeitungsfehler sowie entdeckte URL-Zahlen im Zusammenhang. Erfolgreiche Verarbeitung beweist keine vollständige Indexierung. Untersuchen Sie wichtige Ausnahmen einzeln und vergleichen Sie ähnliche Vorlagen, bevor Sie jeden Ausschluss als Fehler behandeln.
Verbinden Sie wichtige Seiten durch nützliche Links
Crawler und Leser benötigen einen Weg zu hilfreichen Seiten. Verwenden Sie normale Links mit beschreibendem Text und echten Zieladressen. Eine Karte mit ausschließlich JavaScript-gesteuertem Klick kann für Menschen funktionieren, aber einen schwachen Entdeckungsweg bieten. Ein zugrunde liegender Anker ist die verlässliche Basis.
Ordnen Sie Kategorien nach Aufgaben der Leser und ergänzen Sie Kontextlinks zu Voraussetzungen oder nächsten Schritten. Die Sammlung zu technischem SEO zeigt einen thematischen Weg zwischen verwandten Anleitungen. Navigation sollte die Struktur erklären und nicht nur alle URLs in einem ungegliederten Block zeigen.
Crawling-Tiefe ist ein Diagnosewert, keine allgemeine Zahlenregel. Eine wertvolle Seite hinter vielen unnötigen Schritten verdient Aufmerksamkeit. Es gibt jedoch keine feste Klickzahl, die Indexierung oder Rankings garantiert. Suchen Sie nach verwaisten Seiten, defekter Paginierung und Kategorien, die ausschließlich über die interne Suche erreichbar sind.
Untersuchen Sie bei großen Katalogen Filter und Sortierungen. Gezielte Einstiegsseiten können einen Suchbedarf bedienen; unbegrenzte Parameterkombinationen erzeugen möglicherweise zahlreiche Fast-Duplikate. Bestimmen Sie, welche Kombinationen stabile indexierbare Seiten verdienen, und richten Sie Links, Canonicals und Crawling-Steuerung daran aus.
Kaschieren Sie fehlende Navigation nicht durch zusätzliche Sitemap-Einträge. Die Sitemap kann eine Adresse bekannt machen, repariert jedoch weder den Nutzerweg noch den Linkkontext. Prüfen Sie wichtige Seiten von der Startseite und von der Kategorie aus, in der Besucher sie erwarten würden.
Beschreiben Sie Sprachausgaben, ohne sie zusammenzuführen
hreflang hilft Google, gleichwertige Sprach- oder Regionalfassungen zuzuordnen. Es übersetzt nichts und ersetzt keine sinnvolle Lokalisierung. Jede Alternative benötigt eine stabile erreichbare URL und Rückverweise auf die anderen Mitglieder derselben Gruppe.
Dieses vereinfachte englisch-spanische Beispiel nennt zusätzlich ein Ausweichziel:
<link rel="alternate" hreflang="en" href="https://example.com/guides/caching/">
<link rel="alternate" hreflang="es" href="https://example.com/es/guides/caching/">
<link rel="alternate" hreflang="x-default" href="https://example.com/guides/caching/">Platzieren Sie auf beiden gleichwertigen Seiten denselben vollständigen Satz einschließlich des jeweiligen Selbsteintrags. x-default ist ein optionales Ziel für Nutzer, deren Sprache oder Region keiner angegebenen Variante entspricht. Verwenden Sie gültige Sprachcodes und bei Bedarf Regionscodes. Eine Region allein ist keine Sprache.
Verknüpfen Sie keine unterschiedlichen Seiten allein aufgrund derselben Navigationsposition. Eine englische Kategorie und eine spanische Startseite sind keine gleichwertigen Übersetzungen. Halten Sie das Canonical jeder Fassung mit dem Ziel ihres Alternate-Eintrags konsistent und prüfen Sie unerwartete Weiterleitungen.
Bieten Sie außerdem sichtbare Sprachlinks an. Erzwungene Weiterleitungen allein anhand vermuteter Sprache oder Region können alternative Fassungen schwer erreichbar und prüfbar machen. Besucher sollten eine Version wählen und Crawler sie direkt abrufen können.
Ergänzen Sie strukturierte Daten passend zum sichtbaren Inhalt
Strukturierte Daten beschreiben Entitäten und Seiteninhalte maschinenlesbar. Wählen Sie einen geeigneten unterstützten Typ und erfüllen Sie Pflichtfelder mit tatsächlichen Informationen. Gültiges JSON klärt nur die Syntax; Richtigkeit und Berechtigung für die Darstellung bleiben erforderlich.
Artikel-Markup sollte beispielsweise den angezeigten Artikel beschreiben. Produkt-Markup darf keine Verfügbarkeit oder Bewertungen erfinden. Ergänzen Sie keine Sterne, Personen oder Unternehmensdaten bloß deshalb, weil ein Template ein Feld erwartet. Lassen Sie unbelegte Angaben weg und korrigieren Sie die Vorlage.
Verwenden Sie den Rich Results Test für unterstützte Google-Ergebnisfunktionen und bewerten Sie Fehler im Kontext des gewählten Typs. Ein bestandener Test garantiert weder ein Rich Result noch die Indexierung. Halten Sie Markup und sichtbare Änderungen synchron, besonders wenn Preise, Verfügbarkeit oder Datumsangaben getrennt erzeugt werden.
Prüfen Sie mobile Inhalte und Leistung getrennt
Google verwendet hauptsächlich den Inhalt der mobilen Fassung für die Indexierung. Wichtige Texte, Überschriften, Links, Bilder und strukturierte Daten müssen auch mobil verfügbar bleiben. Ein kompaktes Layout darf Inhalte umordnen. Wesentliche Erklärungen zu entfernen oder erst nach einer Interaktion abzurufen erzeugt jedoch ein anderes Suchdokument.
Prüfen Sie zusätzlich die Nutzung: lesbaren Text, bedienbare Elemente, stabile Layouts und schnelle Reaktionen. Gute Core Web Vitals unterstützen die Erfahrung, ersetzen jedoch keine Zugänglichkeit, Relevanz oder Indexierbarkeit. Der Leitfaden zu Core Web Vitals und Rankings trennt Leistungssignale von Ranking-Versprechen.
Eine schnelle statische Antwort kann mit einer langsamen interaktiven Seite zusammenfallen. Ebenso kann eine gute Leistungsbewertung eine Seite betreffen, deren Hauptinhalt in Googles Rendering fehlt. Wird wesentlicher Inhalt durch JavaScript geliefert, folgen Sie dem Ablauf für Rendering und JavaScript-SEO, statt Indexierbarkeit aus Geschwindigkeit abzuleiten.
Machen Sie das Audit zu einer wiederholbaren Release-Prüfung
Speichern Sie bei einer wichtigen URL Header und Antwortinhalt, bevor Sie das Rendering untersuchen. Dieser Befehl ruft die Beispielseite mit einer normalen GET-Anfrage ab:
curl -sS -D response-headers.txt -o response.html https://example.com/guides/caching/Die Dateien zeigen Status und ursprüngliches HTML, nicht den endgültigen JavaScript-DOM. Vergleichen Sie sie mit dem Browser und, falls verfügbar, den Ergebnissen der URL-Prüfung in Search Console. Unterscheiden Sie gespeicherte Indexinformationen vom Live-Test für aktuelle Erreichbarkeit und Rendering.
Prüfen Sie Canonical, Robots-Anweisungen, wichtige Texte und Links in jeder relevanten Phase. Testen Sie anschließend eine fehlende URL, eine Weiterleitung und eine Sprachalternative derselben Vorlagenfamilie. Dadurch werden Regelfehler sichtbar, die eine einzelne erfolgreiche Seite verdecken kann.
Priorisieren Sie Zugriffs- und Antwortfehler, danach widersprüchliche Indexierungssignale, fehlenden Inhalt und defekte Entdeckungswege. Nutzen Sie für anschließende Leistungsarbeit die Performance-Checkliste. Dokumentieren Sie erwartetes Verhalten, Zuständigkeit und erneutes Testergebnis. Wiederholen Sie Vorlagenprüfungen nach Änderungen an Routing, Rendering oder Metadaten.
