Interne 301- und 404-Links in WordPress per Bulk fixen

Der Plan passte in einen Satz: alle internen Links aus der Datenbank holen, ihren Status prüfen und für jeden veralteten Link programmatisch die neue Adresse finden. Der Shop dahinter gehört einem Kunden und läuft mit WordPress und WooCommerce in 3 Sprachen. In den letzten Jahren hat er mehrere URL-Umstellungen hinter sich, und jede davon hat saubere 301-Weiterleitungen bekommen. Die internen Links in den Inhalten zeigten trotzdem weiter auf die alten Adressen.

Bei der ersten Inventur kamen 9.449 interne Links nicht direkt auf ihrem Ziel an. 7.217 davon gingen auf ein WPML-Problem zurück, das einen eigenen Beitrag bekommen hat: WPML-Links zeigen auf die falsche Sprache. Hier geht es um die übrigen 2.232 und damit um klassisches technisches SEO. Das sind die Altlasten, die sich nach jeder URL-Umstellung ansammeln, wenn niemand die Inhalte mitzieht: alte URL-Schemata, umbenannte Bereiche, Weiterleitungen auf Bilder und Ziele, die es gar nicht mehr gibt.

Von außen sieht man davon fast nichts, und gerade deswegen fallen solche Links so lange niemandem auf.

Das Projekt in Zahlen

Punkt	Details
System	WordPress 6.9, WooCommerce 11.0, Theme Flatsome, Cache mit WP Rocket, mehrsprachig mit WPML (Deutsch, Englisch, Spanisch)
Umfang	37.703 interne Link-Einbindungen in 3.420 Inhalten, verteilt auf nur 2.932 verschiedene Adressen
Ausgangslage	9.449 Einbindungen (25,1 %) nicht direkt erreichbar, davon 2.232 klassische veraltete Links ohne den WPML-Sonderfall
Problemtypen	alte Stadtseiten-URLs, alte Produkt- und Kategorie-URLs, Weiterleitungen auf Bilder und Theme-Bausteine, ID-Parameter, altes URL-Schema, umbenannter Bereich, fehlender Schrägstrich, Blogartikel ohne /blog/
Vorgehen	Inventur aus der Datenbank, Live-Prüfung ohne Weiterleitungsfolge, 453 Einzelentscheidungen, Ersetzung in mehreren Läufen mit Simulation, Trockenlauf und Sicherung
Ergebnis	0 veraltete interne Links im Abschlusstest, 58 Links bewusst entfernt statt ersetzt
Zeitraum	Oktober 2026 (Inventur am 8., letzter Lauf am 12.)

Woher kommen so viele veraltete interne Links?

Aus ganz normalen Entscheidungen. Keine davon war ein Fehler, jede hatte einen nachvollziehbaren Grund. In diesem Shop kamen über die Zeit 5 Umstellungen zusammen:

• Die Stadtseiten gingen zuerst schnell und pragmatisch online, um zu sehen, ob sie überhaupt wirken. Als klar war, dass sie sich lohnen, zogen sie für mehr Ordnung und bessere Landingpage-Strukturen in ein eigenes Verzeichnis. Aus /leistung-stadt/ wurde /staedte/stadt/.
• Ein Angebotsbereich bekam einen neuen Namen. Inhaltlich blieb es dasselbe Angebot, aber der neue Begriff passt besser zum Geschäftsmodell, und es lassen sich bessere Landingpages dafür bauen.
• Die Kategorie-Basis in WooCommerce wurde geändert, also der feste Teil der Adresse vor Produkten und Kategorien. So eine Änderung erzeugt auf einen Schlag Weiterleitungen für jedes einzelne Produkt und jede Kategorie.
• Der Blog bekam ein /blog/ vor jedem Artikel. Damit lässt sich seine Performance in der Search Console getrennt vom Shop auswerten.
• WPML hat beim Übersetzen der Slugs (also des URL-Teils eines Inhalts) kein festes Muster eingehalten. Auf Deutsch folgten die Adressen einem einheitlichen Schema, auf Englisch und Spanisch war es mehr oder weniger gewürfelt. Ein großer Teil der 301-Weiterleitungen ist genau daraus entstanden.

Für Besucher hat das meistens funktioniert, weil jede Umstellung ihre 301-Weiterleitungen bekommen hatte, so wie es sich gehört. Nur die internen Links in Beiträgen, Seiten, Produkten und Theme-Bausteinen sind dabei stehen geblieben. Bei 3.420 Inhalten mit internen Links lässt sich das von Hand auch nicht nachziehen. So kam mit jeder Umstellung eine neue Schicht Altlinks dazu.

Warum sieht man interne 301-Weiterleitungen nicht?

Bevor irgendetwas geprüft war, hatte ich eine Frage, die sich später als die wichtigste des Projekts herausgestellt hat. Sieht man bei so einer Prüfung überhaupt, ob es eine 301 war? Am Ende kommt ja ggf. eine 200 raus.

Meine erste Idee war Playwright, also ein ferngesteuerter Browser, der jede Adresse aufruft. Das hätte funktioniert und trotzdem das Falsche gemessen. Ein Browser folgt nämlich jeder Weiterleitung automatisch und meldet am Ende die Seite, auf der er gelandet ist. Ein normaler Crawler macht es genauso. Ein Link auf eine alte Adresse sieht damit aus wie jeder andere: „200 OK“, alles in Ordnung.

Claude Code, der KI-Assistent, mit dem ich das Projekt umgesetzt habe, hat an der Stelle einen besseren Weg vorgeschlagen. Für diese Frage braucht es gar keinen Browser. Ein einfacher Abruf, der Weiterleitungen bewusst nicht folgt, zeigt für jede Station den Statuscode und das nächste Ziel. Das ist schneller und beantwortet genau die Frage, um die es geht. Für jede Adresse entsteht so eine Weiterleitungskette wie 301 /alt/ → 200 /neu/, bei Bedarf über mehrere Sprünge.

Und was kostet so ein Umweg? Weniger, als man vielleicht denkt. Google gibt über eine 301 den Großteil der Signale weiter, ein einzelner interner Link über eine Weiterleitung ist damit kein Drama. Teuer wird es woanders: bei Links, die auf einem 404 enden, bei Weiterleitungen, die auf einer Bilddatei landen, und bei der Masse. Jeder Umweg ist ein zusätzlicher Abruf beim Crawling, und bei 2.232 Links summiert sich das.

Warum die Links aus der Datenbank kamen und nicht von einem Crawler

Für die Inventur gab es 2 Wege: die Website von außen crawlen oder die Links direkt aus der Datenbank lesen. Ich habe mich für die Datenbank entschieden. Das liegt v.a. an 2 Dingen:

1. Ein Crawler findet nur, was verlinkt und erreichbar ist. In der Datenbank stehen alle veröffentlichten Inhalte, auch Theme-Bausteine, Vorlagen und Sidebars, die als eigene Seite nie auftauchen.
2. Aus der Datenbank weiß man für jeden Link, in welchem Inhalt und an welcher Stelle er steht. Genau das braucht man später, um ihn dort auch zu ersetzen. Ein Crawler zeigt dagegen nur die Seite, auf der ein Link zu sehen ist. Bei einem Baustein, der auf vielen Seiten eingebunden ist, führt das ziemlich in die Irre.

Der eigentliche Zeitgewinn steckte dann in einer einzigen Zahl. Die 37.703 Link-Einbindungen verteilten sich auf nur 2.932 verschiedene Adressen (762 davon mit Parametern, z.B. Filter-URLs). Es reicht nämlich, jede Adresse nur einmal zu prüfen, und das Ergebnis gilt für alle Einbindungen mit dieser Adresse. Das spart über 90 % der Abrufe. Der komplette Prüflauf hat damit ca. 10-12 Minuten gedauert.

2 Hinweise aus der Vorbereitung haben den Rahmen gesetzt, und beide kamen von der KI. Erstens stehen nicht alle Links in den Inhalten. Menüs, Widgets, Theme-Einstellungen und eigene Felder liegen an anderer Stelle in der Datenbank. Die waren bewusst nicht Teil dieses Projekts, darum kümmert sich jemand anders. Zweitens enthält bei WooCommerce ein Export der Beitragstabelle nicht nur Seiten und Produkte, sondern auch Bestellungen und Formulareingänge. Ausgewertet habe ich deswegen nur veröffentlichte Inhalte, verarbeitet wurde alles lokal, und die Exporte sind inzwischen gelöscht.

Was hat die Inventur gezeigt?

Von den 2.932 verlinkten Adressen kamen 1.234 nicht direkt mit einer 200 an. So haben sie sich nach Status verteilt:

Status	Adressen	Einbindungen
200 direkt	1.698	28.254
301 → 200	1.173	9.237
302 → 200	18	94
404	34	106
301 → 404	9	12

In diesen Zahlen steckt noch der WPML-Sonderfall mit seinen 7.217 Einbindungen. Ohne ihn bleiben 2.232 veraltete Links, und die haben sich auf 10 Problemtypen verteilt:

Problemtyp	Einbindungen	Beispiel (neutralisiert)
Alte Stadtseiten-URL	811 (davon 11 als 404)	/leistung-stadt/
Alte Produkt- oder Kategorie-URL	523 (teils per 302)	/produktgruppe-alt/
Weiterleitung auf eine Bilddatei	367	alte Seite → .jpg
Weiterleitung auf einen Theme-Baustein	93	alte Seite → Flatsome-Block, später → .webp
ID- oder Typ-Parameter	157	/?attachment_id=…, /?post_type=product&p=…
Altes URL-Schema	85	/alte-basis-schlagwort/…
Umbenannter Angebotsbereich	72	/bereich-alt/…
Fehlender Schrägstrich	27	/kontakt
Blogartikel ohne /blog/	4	/artikelname/
Sonstige	93	alte Formular- und Serviceseiten, teils per 302

Wie unterschiedlich „veraltet“ sein kann, zeigen schon die kleinen Posten. Der fehlende Schrägstrich ist harmlos: /kontakt leitet per 301 auf /kontakt/ weiter, das Ziel stimmt, nur der Umweg ist überflüssig. Die Parameter-Links sind ein anderes Kaliber. ?attachment_id= zeigt auf die Anhangseite eines Bildes, ?post_type=product&p= auf ein Produkt über seine interne ID. Wohin so ein Link wirklich führt, sieht man ihm nämlich nicht an. Und die Weiterleitungen auf Bilder und Theme-Bausteine sind ein Paradebeispiel dafür, warum eine funktionierende Weiterleitung noch lange kein richtiges Ziel ist.

Ist das Ende der Weiterleitung automatisch das richtige Ziel?

Der naheliegende Gedanke bei einer 301 ist: Die Weiterleitung kennt das neue Ziel ja schon. Also ersetzt man den alten Link einfach durch das Ende der Kette. Für einen großen Teil der Links stimmt das auch. Für einen überraschend großen Teil aber nicht.

Bei 453 der 1.234 Adressen endete die Kette nicht auf einer echten Seite. Sie endete auf einer Bilddatei, auf einem internen Flatsome-Block (einem wiederverwendbaren Baustein des Themes, der nie als eigene Seite gedacht war), auf einer URL mit Parametern oder auf einem 404. Eine alte spanische URL leitete z.B. direkt auf eine .jpg-Datei weiter. Eine andere zeigte zuerst auf einen Theme-Baustein und später auf eine .webp-Datei.

Wer solche Links blind durch das Ende der Kette ersetzt, verlinkt danach direkt auf ein nacktes Bild. Jeder Linkcheck meldet dann eine 200. Gelöst ist das Problem damit nicht, es ist nur unsichtbar geworden, und für Besucher ist der Link genauso nutzlos wie vorher.

Aus demselben Grund kam auch ein globales Suchen und Ersetzen über die ganze Datenbank nicht infrage, so schnell es gewesen wäre. Es ersetzt eine alte Adresse überall durch dieselbe neue, egal ob das Ziel final ist und egal, in welcher Sprache der Beitrag geschrieben ist.

Zur Unterscheidung lief zuerst eine gründliche Analyse jedes einzelnen Ziels. Das hat mir zu lange gedauert, und so tief muss es auch gar nicht gehen. Stattdessen habe ich eine einfache Regel festgelegt: Final ist ein Ziel nur, wenn die Kette mit 200 auf einer echten Seite endet. Keine Datei, keine Parameter in der Adresse, kein Theme-Baustein. Das lässt sich an der Ziel-URL selbst ablesen und braucht keine Tiefenanalyse.

Ergebnis: 781 Adressen mit 5.694 Einbindungen waren final, 453 Adressen mit 3.755 Einbindungen nicht (beides noch inkl. WPML-Fall). Durchgesehen habe ich die finalen Ziele alle selbst, bevor auch nur eins davon in eine Ersetzung ging. Gepasst haben alle. Dass auch ein finales Ziel in der falschen Sprache liegen kann, ist eine eigene Geschichte, die im Beitrag zu WPML und falscher Sprache steht.

Wie lief die Bereinigung der veralteten Links?

Bereinigt wurde per Bulk-Fix in mehreren Läufen, alle direkt in der Datenbank des laufenden Shops, und die Reihenfolge war dabei kein Zufall.

Zuerst die Links, bei denen sich für Besucher nichts ändert

Ein Link mit finalem Ziel landet nach der Ersetzung exakt auf derselben Seite wie vorher, nur ohne Umweg. Für Besucher ändert sich nichts, und das macht diese Gruppe so risikoarm. Deswegen kam sie zuerst dran, noch vor allen Einzelfällen.

Zu dem Zeitpunkt war der WPML-Sonderfall schon erledigt, übrig waren 429 finale Adressen in 393 Beiträgen. Der Trockenlauf meldete 1.305 Ersetzungen in 309 Beiträgen und 0 Fehler, exakt so viele wie die Simulation vorher. 308 weitere Links hat das Werkzeug bewusst übersprungen und für später aufgehoben, weil ihr Ziel in einer anderen Sprache lag als der Beitrag. Bei jeder Ersetzung blieb die Form des Links erhalten: Relativ blieb relativ, absolut blieb absolut, und eine Sprungmarke am Ende blieb stehen.

Wie viel dieser eine Schritt bewegt hat, zeigt der Vergleich je Problemtyp (Stand 12. Oktober, mit 6 Links mehr als bei der ersten Inventur):

Problemtyp	Vorher	Nach dem ersten Schritt
Alte Stadtseiten-URL	811	251
Alte Produkt- oder Kategorie-URL	525	30
Weiterleitung auf Datei, Bild oder Baustein	460	460
ID- oder Typ-Parameter	157	129
Sonstige	97	36
Altes URL-Schema	85	9
Umbenannter Angebotsbereich	72	18
Fehlender Schrägstrich	27	0
Blogartikel ohne /blog/	4	0
Gesamt	2.238	933

Neu kaputt gegangen ist dabei kein einziger Link. Die 460 Weiterleitungen auf Dateien, Bilder und Bausteine sind mit Absicht unverändert geblieben. Für sie gab es am Ende der Kette kein brauchbares Ziel, also brauchte jeder Fall eine eigene Entscheidung.

453 Einzelentscheidungen statt Massenersetzung

Für die 453 nicht finalen Adressen hatte ich eine klare Vorgabe: kein fehleranfälliges maschinelles Abarbeiten. Ein Algorithmus, der für einen Bild-Link automatisch „irgendeine passende Seite“ sucht, liegt bei einem Teil der Fälle daneben. Und solche Fehler findet später niemand mehr, weil der Link nämlich eine 200 liefert.

Jede Adresse bekam deswegen eine eigene Empfehlung mit Begründung. Grundlage waren die Sitemap mit 3.109 URLs als Liste aller echten Ziele, der Linktext, eine Beispielseite mit dem Link und bei Produkten der Titel aus der Datenbank. Für 428 Adressen war der Link auf einer Live-Seite im HTML bestätigt. Die übrigen 25 standen nur in Vorlagen oder Bausteinen und bekamen stattdessen einen Link ins Backend. Alle 464 empfohlenen Ziele wurden live geprüft, 19 Fälle waren zum Gegenlesen markiert.

Ein paar Regeln haben sich dabei schnell herauskristallisiert:

• Bei Links auf Bilder oder Anhänge verrät der Linktext, wohin der Link eigentlich sollte. Er entscheidet über das Ziel, nicht das Bild.
• In 69 Fällen war eine Kategorie das bessere Ziel als ein einzelnes Produkt.
• Alte Stadtseiten-URLs gingen auf die passende neue Stadtseite.
• Ein Produkt, das auf privat gestellt war und nur noch ein 404 lieferte, wurde durch die passende Kategorie ersetzt.
• Für Produkte, die nicht mehr im Sortiment sind, gab es kein sinnvolles Ziel. Diese Links wurden entfernt.

Umgesetzt wurden die Entscheidungen im letzten großen Lauf. Dort kamen 135 Adressen mit 678 Einbindungen zusammen, deren Kette auf einem Bild, einem Baustein, einem Parameter oder einem 404 endete. Dazu kamen die 308 übersprungenen Links mit Ziel in der falschen Sprache. Wo eine Adresse in mehreren Sprachen verlinkt war, bekam jede Sprache ihr eigenes Ziel.

Manche Links ersetzt man besser gar nicht

Ein Bereich hat gezeigt, dass das richtige Ziel manchmal gar kein Ziel ist. Vom umbenannten Angebotsbereich gab es noch alte Seiten, die mit dem neuen Bereich zusammengelegt werden sollten (inzwischen ist das passiert). Die Links dorthin auf die aktuelle Adresse umzustellen, hätte das Problem nur verschoben. Spätestens nach der Zusammenlegung hätte es wieder interne Links über 301 gegeben. Also habe ich entschieden, sie zu entfernen.

Das betraf 55 Links, und ganz so banal wie „Link löschen“ ist das in der Praxis nicht, denn ein Link steht selten für sich allein:

• 39 waren Listenpunkte, die nur aus dem Link bestanden. Da musste der ganze Listenpunkt weg, sonst bleibt ein leerer Aufzählungspunkt stehen.
• 15 Links wurden zu normalem Text, der Satz drumherum blieb erhalten.
• 1 war ein Button in einer alten Theme-Vorlage.

Zusammen mit den 3 Links auf Produkte, die nicht mehr angeboten werden, sind so 58 Links rausgeflogen, statt umgeleitet zu werden.

Nach jedem Lauf dieselbe Kontrolle

Nach jedem Lauf gab es einen festen Ablauf, den ich vorgegeben hatte: alle internen Links neu aus der Datenbank holen, daraus die Liste der eindeutigen Adressen bauen, jede live prüfen und die Statistik mit dem Vorlauf vergleichen. Immer gleich und immer komplett. Das klingt nach Fleißarbeit, ist aber die halbe Miete. Nur so sieht man, ob ein Lauf wirklich das bewirkt hat, was er sollte, und ob er nebenbei etwas kaputt gemacht hat.

So sah der Verlauf über das ganze Projekt aus, inkl. WPML-Fall:

Stand	Fehlerhafte interne Links
Ausgangslage am 8. Oktober	9.449
nach dem WPML-Lauf	2.291
nach den finalen Ersetzungen	986
nach dem letzten Lauf, erster Abschlusstest (strenger gezählt)	94
zweiter Abschlusstest	1
nach der Korrektur von Hand	0

Ab dem ersten Abschlusstest gilt eine strengere Messung: jede Einbindung einzeln, jede Schreibweise für sich und zusätzlich die Sprache des Ziels. Die 94 Fälle dort sind nicht direkt mit den 986 davor vergleichbar. Was dieser Test noch gefunden hat und wie das Sicherheitsnetz um die Massenänderungen aufgebaut war, steht ausführlich im WPML-Beitrag.

Kurz gesagt: Kein Werkzeug lief ohne Simulation gegen einen Datenbank-Export, ohne Trockenlauf im Live-System und ohne frisches Backup. Jeder Beitrag wurde vor der Änderung einzeln gesichert. Und nach jedem Echtlauf musste ein neuer Export Byte für Byte dem geplanten Ergebnis entsprechen.

Welche Rolle hat die KI bei der Bereinigung gespielt?

Inventur, Prüfläufe, Statistiken und die Werkzeuge für die Datenbank habe ich mit Claude Code gebaut, und das hat das Projekt deutlich schneller gemacht. Die 453 Einzelempfehlungen lagen z.B. nach rund einer halben Stunde vor, jede mit Beispielseite, Ziel je Sprache und Begründung. Von Hand wäre das eine Fleißarbeit für sich gewesen.

Die Entscheidungen lagen aber bei mir, und die Arbeitsteilung sah so aus:

• Die KI hat meinen ersten Plan verbessert: Statt eines Browsers reichte ein Abruf ohne Weiterleitungsfolge. Auch die Hinweise auf Links außerhalb der Inhalte und auf die Bestelldaten im Export kamen von ihr.
• Die Frage, ob man die 301 hinter einer 200 überhaupt sieht, kam von mir. Davon hing ab, ob die ganze Prüfung etwas taugt.
• Die gründliche Analyse jedes Weiterleitungsziels habe ich abgebrochen und durch die einfache Regel ersetzt. Die war schneller und hat für alle 781 finalen Adressen gestimmt.
• Dass die 453 Problemfälle einzeln entschieden werden und nicht per Algorithmus, war meine Vorgabe. Genauso die Entscheidung, Links in einen auslaufenden Bereich zu löschen, statt sie umzubiegen.
• Auch die KI hat Fehler gemacht. Beim ersten Einlesen des Datenbank-Exports kamen statt 23 Spalten nur 8 an, weil das Einlese-Skript an der Formatierung des Exports hängen blieb. Schnell behoben, aber ein gutes Argument dafür, jede Zahl am Anfang einmal gegen die Quelle zu prüfen.

Genau an der Stelle ist ein KI-Assistent ein zweischneidiges Schwert. Er liefert in einer halben Stunde 453 plausible Empfehlungen. Ob sie stimmen, muss trotzdem jemand prüfen, der weiß, wie der Shop gedacht ist. Was als final gilt, welcher Link gelöscht wird und welche Seite ein Linktext eigentlich meint, sind Entscheidungen, die man nur mit Kenntnis des Geschäfts treffen kann.

Was hat die Bereinigung gebracht?

Das direkte Ergebnis ist eindeutig: Im zweiten Abschlusstest lief keiner der 37.792 geprüften internen Links mehr über eine veraltete Adresse oder ins Leere. Der eine verbliebene Fehler war ein WPML-Rückfall, den ich danach von Hand korrigiert habe.

Kennzahl	8. Oktober	Nach dem Projekt
Veraltete interne Links (ohne WPML-Fall)	2.232	0
davon alte Stadtseiten-URLs	811	0
davon Weiterleitungen auf Bilder und Theme-Bausteine	460	0
Interne Links auf ein 404 (inkl. WPML-Fall)	118	0

Für die Rankings ist es noch zu früh. Die Baseline aus der Search Console steht aber schon, und der Vergleich folgt nach 4-6 Wochen.

Meine Erwartung ist dabei bewusst nüchtern. Die entfernten 301 allein bringen wenig, weil Google über eine Weiterleitung den Großteil der Signale weitergibt. Wer sich von so einer Bereinigung einen Rankingsprung verspricht, wird vermutlich enttäuscht. Spürbarer sind 3 andere Dinge:

• Die Links, die vorher wirklich kaputt waren, funktionieren wieder. Bei 404-Zielen und Weiterleitungen auf Bilddateien kam beim Klick kein Inhalt an, weder für Besucher noch für Suchmaschinen.
• Jeder interne Link kommt jetzt mit dem ersten Abruf an. Das spart Umwege beim Crawling, gerade bei einem Shop mit tausenden Inhalten.
• Es gibt einen sauberen Ausgangspunkt. Die nächste URL-Umstellung lässt sich gegen einen Stand prüfen, in dem nichts mehr über Umwege läuft. Jeder neue Umweg fällt dann sofort auf.

Warum die 301-Weiterleitungen auf dem Server bleiben

Eine naheliegende Frage: Wenn kein interner Link mehr auf die alten Adressen zeigt, kann man die Weiterleitungen dann nicht löschen? Nein.

Die internen Links sind nur ein Weg, auf dem Besucher bei einer alten Adresse landen. Externe Links von anderen Websites, Lesezeichen und alte Einträge in den Suchergebnissen zeigen weiterhin dorthin. Ohne Weiterleitung würden all diese Aufrufe in einem 404 enden. Die interne Verlinkung wird also umgestellt, die Weiterleitungen auf dem Server bleiben, wie sie sind.

Welche Nebenbefunde die Inventur noch geliefert hat

Wer ohnehin jeden internen Link einmal anfasst, sieht nebenbei einiges, wonach er gar nicht gesucht hat. Ohne die Punkte zur Mehrsprachigkeit (die stehen im WPML-Beitrag) waren das vor allem diese:

• 23 verlinkte Seiten hatten ein Canonical auf eine andere URL, zusammen 317 Links. Das Canonical sagt Suchmaschinen, welche Adresse die maßgebende ist. Ein Teil davon ist gewollt, z.B. wenn eine Unterseite bewusst auf die übergeordnete Kategorie verweist. 2 davon waren falsch gesetzt.
• 112-114 Links (je nach Messung) zeigten auf Seiten mit noindex, also auf Seiten, die gar nicht in den Suchindex sollen. Vor allem die Anfrageliste des Shops, eine Zusatzleistung und Filter-URLs. Bei der Anfrageliste ist das völlig in Ordnung. Bei Filter-URLs ist die Frage, ob sie wirklich aus dem Inhalt verlinkt sein müssen.
• Einige Links zeigten auf 4 Produkte im Entwurfsstatus, die Besucher gar nicht sehen können.
• 2 Produkte gab es doppelt.

Keiner dieser Punkte war Teil des Auftrags. Auf der Liste stehen sie trotzdem, als Empfehlung für die nächsten Schritte.

Wo diese Prüfung aufhört

Damit keine falschen Schlüsse entstehen: Geprüft wurden alle internen Links in veröffentlichten Inhalten, also in Seiten, Beiträgen, Produkten, Varianten, Theme-Bausteinen, Vorlagen und Sidebars. Nicht dazu gehörten Menüs (431 Menüeinträge), Widgets, Theme-Einstellungen und eigene Felder. Ebenso wenig Links, die erst per JavaScript entstehen, oder Links, die ein Plugin automatisch setzt. Menüs und Widgets laufen separat, darum kümmert sich jemand anders. Wer eine ähnliche Bereinigung plant, sollte deswegen vorher klären, an welchen Stellen der eigenen Seite überhaupt Links entstehen.

Lohnt sich das Aufräumen interner 301-Links?

Ja, aber nicht wegen der 301 selbst. Die kosten einzeln wenig. Den eigentlichen Wert hatten die Fälle, die eine oberflächliche Prüfung nie gefunden hätte: 460 Links, deren Weiterleitung auf einem Bild bzw. Theme-Baustein endete, und Links, die ins Leere liefen. Eine blinde Ersetzung durch das Ende jeder Kette hätte genau diese Fälle nicht gelöst, sondern unsichtbar gemacht. Die Statistik hätte danach sauber ausgesehen, die Links wären trotzdem falsch gewesen.

Die Frage vom Anfang, ob man die 301 hinter einer 200 überhaupt sieht, war deswegen die wichtigste des ganzen Projekts. Die Antwort ist ganz einfach: nur, wenn die Prüfung Weiterleitungen bewusst nicht folgt. Alles andere misst das Falsche.

Eine Sache würde ich beim nächsten Mal anders machen: gleich mit der einfachen Regel für finale Ziele anfangen, statt erst eine gründliche Analyse jedes Ziels zu starten. Die Regel hat am Ende für alle 781 finalen Adressen gestimmt, die Analyse hätte nur Zeit gekostet.

Und für jede künftige URL-Umstellung ist meine Empfehlung klar: die internen Links im selben Schritt mitziehen wie die Weiterleitungen. Ein bisschen mehr Aufwand bei der Umstellung, dafür kein Aufräumprojekt hinterher. Ob sich die Bereinigung in den Rankings zeigt, ergänze ich hier, sobald der Vergleich mit der Baseline steht.

Häufige Fragen zu internen 301-Weiterleitungen und 404-Links

Wie findet man interne Links, die über eine 301-Weiterleitung laufen?

Nur mit einer Prüfung, die Weiterleitungen nicht automatisch folgt. Browser und normale Crawler zeigen am Ende eine 200 und verstecken damit den Umweg. In diesem Projekt kamen die Links direkt aus der WordPress-Datenbank, und jede der 2.932 verschiedenen Adressen wurde einmal ohne Weiterleitungsfolge abgerufen.

Wie viel bringt es für SEO, interne 301-Weiterleitungen zu entfernen?

Einzeln wenig, weil Google über eine 301 den Großteil der Signale weitergibt. Mehr bringen die Fälle, die dabei auffallen: interne Links auf 404-Seiten, Weiterleitungen auf Bilddateien und Umwege beim Crawling. Die Wirkung auf die Rankings ist in diesem Projekt noch nicht gemessen.

Kann man einen alten Link einfach durch das Ziel der Weiterleitung ersetzen?

Nur, wenn das Ziel final ist, also eine echte Seite. Hier endeten 453 von 1.234 Weiterleitungen auf einer Bilddatei, einem Theme-Baustein, einer Parameter-URL oder einem 404. Diese Fälle brauchten jeweils eine eigene Entscheidung.

Sollte man 301-Weiterleitungen löschen, wenn die internen Links umgestellt sind?

Nein. Externe Links, Lesezeichen und Suchmaschinen kennen die alten Adressen weiterhin. Umgestellt werden nur die internen Links, die Weiterleitungen auf dem Server bleiben bestehen.

Was macht man mit internen Links auf Seiten, die es nicht mehr gibt?

Das hängt vom Fall ab. Gibt es einen passenden Ersatz, z.B. die Kategorie eines Produkts, das nicht mehr öffentlich ist, bekommt der Link dieses Ziel. Gibt es keinen sinnvollen Ersatz oder läuft ein Bereich ohnehin aus, ist Entfernen die sauberere Variante. In diesem Projekt waren das 55 Links in einem auslaufenden Bereich und 3 Links auf Produkte, die nicht mehr im Sortiment sind.

Warum laufen nach einer neuen Permalink-Struktur oder Kategorie-Basis so viele interne Links über 301?

Weil eine Weiterleitung nur den Aufruf umleitet. Die Links in Beiträgen, Seiten und Produkten stehen weiter mit der alten Adresse in der Datenbank. In diesem Shop kamen so über mehrere Umstellungen 2.232 veraltete Links zusammen, von alten Stadtseiten-URLs (811) bis zu Blogartikeln ohne /blog/ (4).

Kann man tausende interne Links in WordPress per Bulk-Fix ersetzen, ohne etwas kaputt zu machen?

Ja, wenn das Risiko vorher abgesichert ist. Hier lief jede Massenänderung erst als Simulation gegen einen Export, dann als Trockenlauf im Live-System, mit Backup, Sicherung jedes Beitrags und einem Vergleich Byte für Byte danach. Beim größten Schritt waren das 1.305 Ersetzungen in 309 Beiträgen ohne einen einzigen Fehler.

Was bedeuten interne Links mit ?attachment_id= oder ?post_type=product&p=?

Das sind interne Adressformen von WordPress. Die erste zeigt auf die Anhangseite eines Bildes bzw. einer Datei, die zweite auf ein Produkt über seine ID. Beide liefen hier über eine Weiterleitung, und keiner verrät im Link selbst, wohin er führt. In diesem Shop waren es 157 Einbindungen mit solchen Parametern.