Defekte Links entstehen auf jeder WordPress-Website, die länger als ein paar Monate gepflegt wird: Eine Seite wird umbenannt, ein PDF ersetzt, ein Partner stellt seine Website um, ein Bild wird in der Mediathek gelöscht. Besucher landen dann auf einer Fehlerseite, und Suchmaschinen verschwenden Zeit mit Adressen, die es nicht mehr gibt. Diese Anleitung zeigt, wie Sie defekte Links systematisch finden, entweder mit dem Plugin Broken Link Checker oder ohne Plugin mit einem kleinen Skript, und wie Sie sie sicher reparieren, einzeln im Editor oder in großer Zahl mit WP-CLI. Alle Schritte wurden im Labor mit WordPress 7.1.2 und absichtlich defekten Links durchgespielt.

Voraussetzungen

WordPress: Broken Link Checker 2.4.14.1 verlangt laut Plugin-Seite mindestens WordPress 6.2 und ist bis 7.1.2 getestet. Im Labor lief WordPress 7.1.2.
PHP: mindestens PHP 7.4 laut Plugin-Seite, im Labor PHP 8.4.
Rolle: Administrator für Installation und Einstellungen. Zum Bearbeiten von Links verlangt das Plugin das Recht, fremde Beiträge zu bearbeiten.
Zugriff: Backend genügt für den Plugin-Weg. Für das Prüfskript und WP-CLI brauchen Sie SSH.
Server: Der Server muss Anfragen an die eigene Domain zulassen (Loopback), sonst kann eine lokale Prüfung interne Links nicht erreichen.
Backup: Eine aktuelle Sicherung der Datenbank, bevor Sie Links in großer Zahl ändern. Die Anleitung WordPress-Datenbank mit WP-CLI sichern und wiederherstellen zeigt, wie das geht.

Schritt 1: Entscheiden, welcher Weg zu Ihrer Website passt

Es gibt drei sinnvolle Wege, und sie schließen sich nicht aus:

Weg	Stärke	Grenze
Broken Link Checker, lokal	findet interne und externe Links in Beiträgen, Seiten und Kommentaren, Reparatur direkt im Backend	belastet den eigenen Server, braucht funktionierende Loopback-Anfragen
Broken Link Checker, Cloud	Prüfung läuft auf Servern des Anbieters WPMU DEV	braucht laut Plugin-Seite ein kostenloses Hub-Konto bei WPMU DEV, Daten gehen an einen Dritten
Skript mit curl	kein Plugin, keine Datenbanktabellen, gut für Stichproben	prüft nur, was in der ausgelieferten HTML-Seite steht, keine Reparatur

Für kleine Unternehmenswebsites ist der lokale Modus meist die beste Wahl: Die Daten bleiben auf Ihrem Server, und für einige hundert Links reicht die Leistung. Diese Anleitung beschreibt deshalb den lokalen Modus. Den Cloud-Modus sollten Sie erst nach einer Prüfung im Sinne des Datenschutzes nutzen, weil dabei Inhalte Ihrer Website an einen externen Dienst gehen.

Verifizieren: Sie wissen, ob Sie SSH-Zugang haben und ob der Plugin-Weg oder das Skript für Sie in Frage kommt.

Schritt 2: Broken Link Checker installieren und lokal einrichten

Installieren Sie unter Plugins > Plugin hinzufügen das Plugin „Broken Link Checker“ von WPMU DEV und aktivieren Sie es. Im Menü erscheint ein neuer Eintrag „Link Checker“ mit den Unterpunkten „Cloud (neu)“ und „Lokal (alt)“. Öffnen Sie „Lokal (alt)“. Die Seite heißt „Lokaler Broken Link Checker“ und hat die Reiter „Fehlerhafte Links“ und „Einstellungen“.

Unter „Einstellungen“ sind im Reiter „Allgemein“ diese Punkte wichtig:

Linküberprüfung: Prüfintervall in Stunden. Im Labor stand der Standardwert auf 72 Stunden. Neue Links prüft das Plugin laut Beschreibung sofort.
E-Mail-Benachrichtigungen: „Dem Administrator eine E-Mail-Benachrichtigung senden, wenn neue fehlerhafte Links erkannt werden“ ist standardmäßig aktiv. Im Test kam eine E-Mail mit dem Betreff „[Websitename] Fehlerhafte Links erkannt“ und einer Liste mit Linktext, Adresse und Quelle.
Linkanpassungen: Das Plugin kann defekte Links auf der Website durchgestrichen darstellen und Suchmaschinen anweisen, ihnen nicht zu folgen. Das ist eine Übergangslösung, keine Reparatur.

Im Reiter „Linksuche in“ legen Sie fest, wo das Plugin sucht: Beiträge, Seiten, Kommentare, individuelle Felder und weitere Inhaltstypen. Im Reiter „Erweitert“ finden Sie „Zeitüberschreitung“ und „Server-Auslastungsgrenze“. Die Prüfung pausiert, wenn die Serverlast diesen Wert überschreitet. Die „Ziel-Ressourcenauslastung“ stand im Test auf 25 Prozent. Auf kleinem Webhosting sollten Sie diese Werte nicht erhöhen.

Die Prüfung läuft über WP-Cron: Im Labor legte das Plugin die geplanten Aufgaben blc_cron_check_links (alle 10 Minuten), blc_cron_email_notifications und blc_cron_database_maintenance (täglich) an. Auf Websites mit wenig Besuchern dauert der erste Durchlauf deshalb entsprechend länger.

Verifizieren: Unter Link Checker > Lokal (alt) zeigt die Liste Zähler für „Alle“, „Fehlerhaft“, „Warnungen“, „Weiterleitungen“ und „Verworfen“. Nach einigen Minuten sollte die Zahl bei „Alle“ größer als null sein.

Schritt 3: Ergebnisse lesen und Fehlalarme erkennen

Im Labor wurde ein Beitrag mit einem funktionierenden internen Link, zwei defekten internen Links und einem fehlenden Bild angelegt. Der erste Durchlauf lieferte ein irreführendes Ergebnis: Alle vier Links, auch der funktionierende, standen als Warnung mit dem Status „Verbindung fehlgeschlagen“ in der Liste. Das Protokoll zu jedem Link zeigte die Ursache:

Failed to connect to localhost:80 after 0 ms: Could not connect to server [Error #7]
Severity: Warning
Reason: This is probably a false positive. The plugin could not connect to your site.
That usually means that your hosting provider has disabled loopback connections.

Der Server konnte sich selbst nicht erreichen. Das kommt bei Hostern mit Firewall-Regeln, hinter Proxys oder in Containern vor. Nachdem die Verbindung im Labor funktionierte, ergab ein neuer Durchlauf das richtige Bild: HTTP-Code 200 für den funktionierenden Link, 404 und „fehlerhaft“ für die anderen drei.

Daraus folgt: Sehen Sie viele Warnungen mit Fehler 7 oder Zeitüberschreitungen bei internen Links, prüfen Sie zuerst unter Werkzeuge > Website-Zustand, ob der Test für Loopback-Anfragen fehlschlägt. Das ist dann eine Aufgabe für Ihren Hoster, nicht für Ihre Inhalte.

Bei externen Links sind Warnungen ebenfalls häufig. Manche Websites blockieren automatisierte Abrufe oder antworten langsam. Prüfen Sie jeden gemeldeten externen Link einmal selbst im Browser, bevor Sie ihn ändern. Stimmt der Link, markieren Sie ihn als „Nicht fehlerhaft“ oder „Verwerfen“.

Verifizieren: Öffnen Sie in der Liste den Filter „Fehlerhaft“. Jeder Eintrag zeigt einen HTTP-Code wie 404 oder 410. Einträge mit Code 0 und „Verbindung fehlgeschlagen“ behandeln Sie wie in diesem Schritt beschrieben.

Schritt 4: Defekte Links reparieren

Für jeden defekten Link haben Sie drei sinnvolle Möglichkeiten. Die Reihenfolge ist zugleich die Rangfolge:

Richtiges Ziel eintragen: Gibt es die Seite unter neuer Adresse, tragen Sie diese ein. Im Plugin über „URL bearbeiten“.
Weiterleitung einrichten: Zeigen viele externe Websites auf die alte Adresse, richten Sie zusätzlich eine 301-Weiterleitung ein, damit auch fremde Links weiter funktionieren.
Link entfernen: Gibt es keinen Ersatz, entfernen Sie den Link und lassen den Text stehen. Im Plugin über „Link entfernen“.

Beide Plugin-Aktionen ändern den Beitragsinhalt direkt in der Datenbank. Im Labor ersetzte „URL bearbeiten“ die Adresse /alte-preisliste/ durch /leistungen/, der Linktext „Preisliste“ blieb erhalten. „Link entfernen“ machte aus <a href="/kontakt-alt/">Kontakt</a> einfachen Text „Kontakt“. WordPress legte bei beiden Änderungen eine neue Revision an, sodass Sie im Editor über „Revisionen“ zurückkehren können.

Fehlende Bilder erscheinen ebenfalls als defekte Links. Hier hilft meist nur, das Bild neu hochzuladen und im Editor auszutauschen. Prüfen Sie vorher in der Mediathek, ob die Datei nur umbenannt wurde.

Verifizieren: Öffnen Sie den reparierten Beitrag auf der Website und klicken Sie den Link an. Im Filter „Fehlerhaft“ des Plugins verschwindet der Eintrag. Unter „Revisionen“ im Editor ist die Änderung sichtbar.

Schritt 5: Viele gleiche Fehler mit WP-CLI beheben

Ist eine ganze Gruppe von Links betroffen, etwa nach dem Umbenennen einer Seite, die in dutzenden Beiträgen verlinkt ist, arbeiten Sie effizienter mit WP-CLI. Suchen Sie zuerst, wo die alte Adresse vorkommt:

wp db search 'alte-preisliste' --stats

Führen Sie dann einen Probelauf aus. --dry-run zeigt, wie viele Ersetzungen erfolgen würden, ohne etwas zu ändern:

wp search-replace 'https://www.example.com/alte-preisliste/' 'https://www.example.com/leistungen/' wp_posts --include-columns=post_content --dry-run

Im Labor meldete der Probelauf für die Adresse eines fehlenden Bildes „Success: 5 replacements to be made.“, weil die Adresse neben dem Beitrag auch in dessen Revisionen stand. Stimmt die Zahl mit Ihrer Erwartung überein, sichern Sie die Datenbank und wiederholen den Befehl ohne --dry-run.

Verwenden Sie für solche Änderungen immer wp search-replace und nicht ein SQL-Update von Hand. Laut WP-CLI-Handbuch behandelt der Befehl serialisierte Daten korrekt, die ein einfaches SQL-Replace beschädigen würde. Geben Sie die vollständige Adresse samt Schrägstrich an, damit nicht versehentlich ähnliche Adressen mit ersetzt werden.

Verifizieren: wp db search 'alte-preisliste' liefert nach der Ersetzung keine Treffer mehr in post_content der veröffentlichten Beiträge.

Schritt 6: Ohne Plugin prüfen und regelmäßig wiederholen

Wenn Sie kein dauerhaftes Plugin möchten, prüft ein kurzes Skript die internen Links aller Beiträge. Es liest die XML-Sitemap, die WordPress seit Version 5.5 unter /wp-sitemap.xml bereitstellt, ruft jede Seite ab und testet jeden internen Link. Ersetzen Sie die Adresse durch Ihre eigene:

#!/bin/sh
# Interne Links aller Beiträge aus der Sitemap prüfen
SITE="https://www.example.com"
curl -s "$SITE/wp-sitemap-posts-post-1.xml" | grep -o "<loc>[^<]*" | sed "s/<loc>//" |
while read -r seite; do
  curl -s "$seite" | grep -o "href=\"$SITE[^\"]*\"" | cut -d\" -f2 |
  while read -r link; do
    code=$(curl -s -o /dev/null -w "%{http_code}" "$link")
    [ "$code" = "200" ] || echo "$code $link (auf $seite)"
  done
done | sort -u

Im Labor gab das Skript genau eine Zeile aus: 404 http://localhost/gibt-es-nicht/ (auf http://localhost/zweiter/). Für Seiten ersetzen Sie posts-post durch posts-page. Das Skript folgt keinen Weiterleitungen, deshalb erscheinen auch 301-Antworten. Das ist gewollt, denn interne Links auf Weiterleitungen sollten Sie ohnehin auf das Endziel umstellen.

Links sind eine Daueraufgabe: Jede umbenannte Seite, jede Plugin-Umstellung und jede fremde Website kann neue Fehler erzeugen. Eine Prüfung pro Quartal reicht für die meisten Unternehmenswebsites. Diese Termine lassen sich gut mit den übrigen Pflegeaufgaben bündeln. Wer Updates, Backups und Sicherheit nicht selbst übernehmen möchte, findet bei der WordPress-Wartung von wordpressupdate.de Unterstützung: Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung, wöchentliche Backups auf externen Speicher und die Pflege einer Firewall.

Verifizieren: Das Skript läuft ohne Ausgabe durch, wenn alle internen Links mit 200 antworten.

Typische Fehler

Alle Links „Verbindung fehlgeschlagen“, Code 0: Loopback blockiert, wie in Schritt 3. Website-Zustand prüfen und den Hoster fragen.
Prüfung kommt nicht voran: WP-Cron läuft nur bei Besuchen. Auf ruhigen Websites oder bei deaktiviertem WP-Cron ohne Server-Cronjob stockt der Durchlauf.
Server wird langsam: „Server-Auslastungsgrenze“ und „Ziel-Ressourcenauslastung“ senken oder Prüfintervall verlängern.
Nach dem Löschen bleiben Reste: Im Labor entfernte die Deinstallation die Tabellen wp_blc_* und fast alle Optionen, die Option wpmudev_blc_last_db_upgrade blieb stehen. Sie ist harmlos und lässt sich mit wp option delete wpmudev_blc_last_db_upgrade entfernen.
Links in Menüs oder Widgets fehlen im Bericht: Das Plugin durchsucht nur die unter „Linksuche in“ gewählten Bereiche. Menüs und Theme-Vorlagen prüfen Sie mit dem Skript aus Schritt 6, das die ausgelieferte Seite liest.

Häufige Fragen

Schaden defekte Links dem Ranking?

Einzelne defekte Links sind vor allem ein Problem für Besucher. Wer auf einer Fehlerseite landet, verlässt die Website häufig. Reparieren Sie deshalb zuerst Links auf wichtigen Seiten wie Startseite, Leistungen und Kontakt.

Soll ich das Plugin dauerhaft aktiv lassen?

Das hängt von der Größe ab. Auf Websites mit wenigen Änderungen genügt eine Prüfung pro Quartal. Danach deaktivieren Sie das Plugin wieder und sparen Serverlast.

Was ist mit Links in PDF-Dateien?

Die hier beschriebenen Wege prüfen nur HTML-Inhalte. Links in PDFs müssen Sie in der Quelldatei ändern und das PDF neu hochladen.

Hilft ein Page-Cache bei der Prüfung?

Er kann stören, weil gecachte Seiten alte Links noch eine Weile zeigen. Leeren Sie nach Reparaturen den Cache. Wie das geht, steht in der Anleitung zum Page-Caching in WordPress.

Testumfang

In unserem Test unter WordPress 7.1.2 hat Broken Link Checker im lokalen Modus funktionierende und defekte interne Links sowie ein fehlendes Bild korrekt erkannt. Auffällig war ein Fehlalarm durch eine blockierte Loopback-Verbindung, dessen Ursache sich im Protokoll nachlesen ließ. Den Cloud-Modus, externe Links ins Internet und sehr große Websites haben wir nicht geprüft, dort sollten Sie zuerst auf einer Kopie testen.

Fazit

Defekte Links finden Sie am einfachsten mit Broken Link Checker im lokalen Modus. Achten Sie im ersten Durchlauf auf Fehlalarme durch blockierte Loopback-Anfragen und reparieren Sie in der Rangfolge richtiges Ziel, Weiterleitung, Entfernen. Für viele gleiche Fehler ist wp search-replace mit Probelauf der sichere Weg, für regelmäßige Stichproben ohne Plugin genügt das Skript. Wer die übrige Pflege der Website abgeben möchte, kann dafür die WordPress-Wartung mit persönlicher Betreuung nutzen.

Weiterführende Anleitungen und Quellen

Weiterführende Anleitungen:

Quellen: