So Führen Sie eine Broken-Link- und Fehlerprüfung durch: Tools, Prioritäten und Workflows

Ein kaputter Link ist jeder Hyperlink, der nicht zu einer erreichbaren, lebenden Seite auflöst. Aus Sicht einer Suchmaschine schaffen kaputte Links drei unterschiedliche Probleme: Sie verschwenden Crawl-Budget auf tote Endpunkte, sie unterbrechen den PageRank-Fluss zwischen Seiten, und sie signalisieren Ranking-Algorithmen geringe Inhaltsqualität. Aus Nutzersicht untergraben sie das Vertrauen — ein Besucher, der auf einen Link klickt und auf einer 404 landet, verlässt die Seite eher komplett.

Crawl-Budget und PageRank-Verlust

Googlebot hat ein festes Crawl-Budget pro Domain — eine Grenze, wie viele Seiten er in einem bestimmten Zeitraum crawlt. Jede Anfrage an eine kaputte URL verbraucht dieses Budget und liefert nichts Nützliches zurück. Auf großen Seiten mit Tausenden Seiten können kaputte Links einen bedeutenden Teil der Crawl-Zuteilung verbrauchen, sodass neu veröffentlichte oder aktualisierte Seiten wochenlang unentdeckt bleiben. Das zweite Problem — der PageRank-Verlust — ist subtiler: Link-Equity fließt durch Links nach außen, kann aber nicht in eine 404-Seite hineinfließen und geht somit effektiv verloren statt umverteilt zu werden.

Der Kaskadeneffekt von Site-Migrationen

Die meisten kaputten Links entstehen nicht allmählich — sie kommen schubweise bei URL-Restrukturierungen, CMS-Migrationen, Domainwechseln und Seitenlöschungen. Eine Website, die von `/blog/artikel-titel` zu `/artikel/artikel-titel` wechselt, ohne 301-Redirects einzurichten, bricht alle internen und externen Links zu jeder betroffenen URL gleichzeitig. Eine vollständige Prüfung unmittelbar nach jeder Strukturänderung findet die Schäden, bevor Crawler den kaputten Zustand indexieren.

• Verschwendetes Crawl-Budget: Jede 404-Antwort verbraucht Crawl-Kontingent ohne Indexierungsnutzen.
• PageRank-Verlust: Auf eine tote URL gesendetes Link-Equity geht verloren, statt über die Seite umverteilt zu werden.
• Qualitätssignale: Seiten mit hoher Dichte kaputter Links werden in Ranking-Modellen mit geringerer Inhaltsqualität assoziiert.
• Nutzererlebnis: Ein Besucher, der auf einen toten Link klickt, bricht die Sitzung deutlich häufiger ab.
• Beschädigte Anker-Signale: Ankertext interner Links hilft Google, Seitenthemen zu verstehen — tote Links beseitigen dieses Signal.

Eine vollständige Broken-Link- und Fehlerprüfung deckt fünf unterschiedliche Problemkategorien ab. Jede Kategorie erfordert ein anderes Tool und erzeugt andere Korrekturarten. Das Gesamtbild vor Beginn zu verstehen, verhindert den häufigen Fehler, eine Broken-Link-Prüfung als bloßes „tote URLs finden“ zu behandeln — es gibt vier weitere Fehlertypen, die genauso schädlich und oft übersehen sind.

Die fünf Fehlerkategorien

• Kaputte interne Links: Links zwischen Seiten Ihrer eigenen Website, die auf gelöschte, umbenannte oder verschobene Seiten zeigen, einschließlich kaputter Anker-Fragment-Links (`#sektions-id`).
• Kaputte externe Links: Ausgehende Links zu Dritt-URLs, die Fehler zurückgeben, fehlerhaft sind, HTTP statt HTTPS verwenden oder auf abgelaufene Domains zeigen.
• Redirect-Ketten und -Schleifen: URLs, die über mehrere Zwischensprünge redirecten (Kette) oder zyklisch redirecten (Schleife), was Crawl-Budget verschwendet und Link-Equity mindert.
• Canonical-Konflikte: Seiten mit Canonical-Tags, die auf die falsche URL zeigen, relative Pfade verwenden, Nicht-HTTPS-Ziele referenzieren oder sich falsch selbst referenzieren.
• Sitemap- und robots.txt-Fehler: Sitemaps mit noindex-Seiten, fehlerhaftem XML, ungültigen URLs oder fehlenden Pflichtelementen; robots.txt-Dateien mit Direktiven, die Schlüsselseiten blockieren.

Eine Broken-Link-Prüfung ist keine Einmalaufgabe — sie ist eine wiederkehrende Qualitätskontrolle, die nach jeder bedeutenden Inhaltsänderung und jedem Deployment laufen sollte.

Kaputte interne Links fallen in zwei Kategorien: kaputte Seitenlinks (die Ziel-URL liefert eine 404 oder wurde von der Seite entfernt) und kaputte Fragment-Links (die Seite lädt korrekt, aber die `#anker-id` existiert auf der Seite nicht). Der zweite Typ wird beständig zu wenig erkannt, weil Standard-Crawler nur prüfen, ob eine Seite lädt — sie verifizieren nicht, ob das angegebene Fragment-Ziel im geladenen HTML existiert.

Kaputte externe Links zeigen auf Dritt-URLs, die Sie nicht kontrollieren. Die häufigsten Ursachen: Websites gehen offline, Seiten werden gelöscht, URLs ändern ihre Struktur, ohne den alten Pfad zu erhalten, und Domains laufen ab. Aus SEO-Sicht sind kaputte externe Links ein Qualitätssignal — eine Seite voller toter ausgehender Referenzen wirkt veraltet und unzuverlässig. Aus Nutzererlebnis-Sicht sind sie schlicht frustrierend.

Was der Prüfer für kaputte externe Links erkennt

Fügen Sie den HTML-Code Ihrer Seite in den Prüfer für kaputte externe Links ein, und das Tool analysiert jedes ausgehende `href`-Attribut, das auf eine externe Domain zeigt. Es markiert fehlerhafte URLs (fehlendes Protokoll, ungültige Zeichen, falsch kodierte Pfadsegmente), unsichere HTTP-Links auf HTTPS-Seiten und verdächtige Link-Muster, die mit minderwertigen ausgehenden Link-Profilen assoziiert sind. Die gesamte Analyse erfolgt in Ihrem Browser — das Tool stellt keine ausgehenden HTTP-Anfragen an die verlinkten URLs, was es schnell und privat macht, bedeutet aber, dass Sie separat verifizieren müssen, ob die markierten URLs tatsächlich Fehler zurückgeben.

Wann man einen kaputten externen Link ersetzt oder entfernt

Für jeden gefundenen kaputten externen Link lautet der Entscheidungsbaum: Existiert ein Ersatz unter einer anderen URL? Wenn ja, aktualisieren Sie den Link. Wenn nein, prüfen Sie, ob die Wayback Machine eine archivierte Version hat — verlinken Sie `web.archive.org/web/*/url` als archivierte Referenz. Existiert beides nicht und ist der Link nur lose relevant, entfernen Sie ihn. Lassen Sie nie einen kaputten externen Link stehen — er liefert Nutzern wie Crawlern negativen Wert.

Redirect-Ketten und Canonical-Tag-Konflikte sind zwei der wirkungsvollsten technischen SEO-Fehler, weil sie direkt beeinflussen, welche Seite Google zu indexieren entscheidet und wie viel Link-Equity jede Seite akkumuliert. Keiner der Fehler erzeugt ein sichtbares Nutzerproblem — beide sind für Besucher unsichtbar — weshalb sie monate- oder jahrelang unbemerkt auf Seiten bestehen.

Redirect-Ketten erkennen und beheben

Eine Redirect-Kette entsteht, wenn eine URL einen Redirect besitzt, der selbst wieder redirectet — eine Sprungfolge vor dem endgültigen Ziel. Googles Crawler folgen Ketten bis zu einer Grenze, aber jeder zusätzliche Sprung verringert den PageRank, der von der Original-URL zum Ziel übertragen wird. Eine Kette aus drei Redirects überträgt messbar weniger Equity als eine einzige direkte 301.

Der Redirect-Ketten-Prüfer analysiert Ihre Redirect-Map oder Server-Logs und identifiziert Ketten mit mehr als einem Sprung, Redirect-Schleifen (URL A → B → A) und gemischte HTTP/HTTPS-Sequenzen. Die Lösung für eine Kette ist stets, die Quelle direkt auf die finale Ziel-URL umzuleiten und alle Zwischenschritte zu umgehen.

Canonical-Tag-Prüfung

Ein Canonical-Tag sagt Suchmaschinen, welche Version einer Seite für die Indexierung bevorzugt wird. Häufige Canonical-Fehler: eine Seite, die auf eine nicht existierende URL canonicalisiert, ein Canonical-Tag mit relativem Pfad statt absoluter URL, eine Canonical, die auf eine HTTP-URL zeigt, obwohl die Seite HTTPS nutzt, und eine Seite, die auf eine andere Seite canonicalisiert, die selbst zurückcanonicalisiert — eine Canonical-Schleife. Jedes davon kann dazu führen, dass Google die falsche Version einer Seite indexiert oder dem Canonical-Signal ganz misstraut.

Der Canonical-URL-Prüfer validiert Canonical-Tags und URL-Zuordnungen auf all diese Konfliktmuster. Führen Sie ihn auf jeder Seite aus, wo Sie Indexierungsprobleme vermuten, auf allen paginierten Serienseiten (häufig falsch konfiguriert) und auf jeder Seite, die von einer alten URL migriert wurde.

Ihre Sitemap sagt Suchmaschinen, welche Seiten existieren und gecrawlt werden sollten. Ihre robots.txt sagt Crawlern, welche Pfade sie aufrufen dürfen. Beide Dateien sind im Prinzip simpel, aber überraschend leicht falsch zu konfigurieren — und Fehler in einer der beiden können dazu führen, dass wichtige Seiten ignoriert oder schlimmstens aktiv blockiert werden.

Was Sie in Ihrer Sitemap prüfen sollten

• Noindex-Seiten enthalten: Jede URL in der Sitemap mit zusätzlicher `noindex`-Robots-Direktive sendet ein widersprüchliches Signal. Entfernen Sie noindex-Seiten aus der Sitemap.
• HTTP-URLs auf einer HTTPS-Seite: Jede URL in Ihrer Sitemap sollte das HTTPS-Protokoll verwenden. Eine HTTP-URL in der Sitemap einer HTTPS-Domain zwingt den Crawler, bei jedem Crawl dieser URL einem Redirect zu folgen.
• 4xx- und 5xx-URLs: Sitemaps sollten nur lebende, erreichbare Seiten enthalten. Eine kaputte URL in der Sitemap verschwendet bei jeder Prüfung durch Googlebot Crawl-Budget.
• Fehlende Pflichtelemente: Das Sitemap-Protokoll verlangt einen `<urlset>`-Wrapper und `<loc>`-Elemente für jede URL. Fehlen sie, ist die Sitemap unparsebar.
• Überschreiten des 50.000-URL-Limits: Eine einzelne Sitemap-Datei darf nicht mehr als 50.000 URLs enthalten. Nutzen Sie für größere Seiten eine Sitemap-Index-Datei und mehrere Teil-Dateien.

Der Sitemap-XML-Validator prüft all diese Struktur- und Protokollkonformitätsprobleme anhand eines eingefügten Sitemap-Dateiinhalts. Keine URL wird abgerufen — die Validierung ist rein strukturell, was sie sicher macht für Sitemaps mit internen URLs, die Sie nicht preisgeben wollen. Für Sitemaps über dem Größenlimit zerlegt der Sitemap-Index-Splitter die Datei in konforme Teile und erzeugt die Index-Datei automatisch.

robots.txt-Prüfung

Die robots.txt-Disallow-Direktive ist ein stumpfes Instrument — eine einzige falsch konfigurierte Regel kann eine ganze Sektion Ihrer Website vom Crawl aussperren. Die häufigsten robots.txt-Fehler: eine `Disallow: /`-Direktive, die die gesamte Seite blockiert (oft ein Überbleibsel aus der Staging-Umgebung), das Blockieren von CSS- oder JavaScript-Dateien, die Google zum Rendern braucht, und widersprüchliche Allow/Disallow-Regeln, bei denen unerwartet die restriktivere Regel Vorrang gewinnt.

Der Robots.txt-Validator prüft Ihre robots.txt-Datei auf Syntaxfehler, ungültige Direktiven, Pfadprobleme und strukturelle Best Practices. Fügen Sie den Dateiinhalt ein — ein Live-Abruf Ihrer Domain ist nie nötig — und der Validator meldet jedes Problem mit einer allgemeinverständlichen Beschreibung der potenziellen Auswirkung.

Eine Broken-Link- und Fehlerprüfung erzeugt Befunde in fünf Kategorien, und nicht alle Befunde sind gleich wichtig. Alles gleichzeitig zu beheben ist auf jeder Seite mit mehr als ein paar Dutzend Seiten unpraktisch. Ein priorisierter Workflow konzentriert die Mühe zuerst auf die Fehler mit dem höchsten SEO- und Nutzererlebnis-Impact und arbeitet über nachfolgende Sprints zu niedriger priorisierten Bereinigungen hinunter.

Empfohlene Prüf-Reihenfolge

1. Beheben Sie kaputte interne Links auf stark frequentierten Seiten und Navigationsmenüs — sie wirken sofort auf Nutzer und PageRank-Verteilung.
2. Beheben Sie Canonical-Konflikte auf Ihren wichtigsten Seiten — falsche Canonicals lassen die falsche URL indexieren und verdrängen Ihre Zielseite direkt aus den Rankings.
3. Konsolidieren Sie Redirect-Ketten zu einsprüngigen 301s — das stellt PageRank zurück, der derzeit entlang der Kette verdünnt wird.
4. Aktualisieren oder entfernen Sie kaputte externe Links — geringere Dringlichkeit als interne Probleme, aber ein messbares Qualitätssignal.
5. Beheben Sie Sitemap-Fehler — stellt sicher, dass neu veröffentlichte Seiten effizient entdeckt werden.
6. Beheben Sie robots.txt-Fehler — kritisch, wenn Blockierung vermutet wird, sonst weniger dringend als das Vorherige.

Einen wiederkehrenden Prüfplan aufbauen

Für regelmäßig publizierende Seiten fängt eine monatliche Prüf-Kadenz die Ansammlung, bevor sie sich verstärkt. Für Seiten in Migration oder Redesign: führen Sie eine Prüfung unmittelbar vor der Änderung durch, um eine Basislinie zu setzen, und erneut unmittelbar danach, um zu verifizieren, dass jeder Redirect steht. Automatisierte Prüfungen in Ihrer Deployment-Pipeline finden neu eingeführte kaputte Links, bevor sie Produktion erreichen — die meisten CI/CD-Frameworks unterstützen einfache URL-Validierungsskripte als Post-Deployment-Schritt.

Link-Prüfungen mit einem vollständigen SEO-Check kombinieren

Eine Broken-Link-Prüfung ist eine Komponente einer breiteren technischen SEO-Überprüfung. Sobald Link- und Redirect-Probleme gelöst sind, erweitern Sie die Prüfung auf Meta-Tags mit dem Meta-Tag-Analyzer, auf Datenstruktur-Gültigkeit mit dem Structured-Data-Validator und auf HTML-Qualität mit dem HTML-Validator. Diese vier Prüfungen zusammen decken die häufigsten technischen SEO-Probleme ab, die gut geschriebenen Inhalt davon abhalten, sein volles Potenzial zu ranken.