In deinem Crawl erscheint eine Seite, die fast nur ein Bild zeigt. Der zugehörige Ratgeber enthält dasselbe Bild, und in der Mediathek gibt es auch noch eine Datei-URL. Bevor du etwas entfernst, kläre, welche dieser Adressen du gerade prüfst. Eine unerwünschte Anhangsseite lässt sich behandeln, während das benötigte Bild erhalten bleibt.
Dieser Unterschied ist gerade bei älteren WordPress-Websites wichtig. Ein Core-Update bedeutet nicht automatisch, dass sämtliche Anhangsseiten weiterleiten. Auch ein eingeschalteter Redirect im SEO-Plugin beweist zunächst nur eine Einstellung. Entscheidend ist die Antwort, die ein Besucher ohne Anmeldung tatsächlich bekommt.
Der Prüfablauf ergänzt die allgemeinen Grundlagen zu WordPress SEO. Er konzentriert sich auf Medien und ihre Seiten, nicht auf eine pauschale Bereinigung der gesamten Mediathek.
Drei Adressen, die du auseinanderhalten musst
Eine Mediendatei kann in WordPress als Attachment-Datensatz verwaltet werden. Dazu können eine öffentliche Anhangsseite und mehrere Bildgrößen gehören. Der Beitrag, in den du das Bild einfügst, hat wiederum seine eigene URL.
Das folgende Beispiel ist vollständig fiktiv. Die Namen, ID und Pfade stammen von keiner untersuchten Website:
| Adresse | Aufgabe im Beispiel | Was du prüfen willst |
|---|---|---|
https://example.com/ratgeber/wandregal/ | Ratgeber mit eingebettetem Bild | Beitrag bleibt erreichbar und zeigt das richtige Bild |
https://example.com/ratgeber/wandregal/montageschritt/ | Möglicher Anhangs-Permalink | Bewusst behalten oder auf ein passendes Ziel weiterleiten |
https://example.com/?attachment_id=417 | ID-basierter Zugang zum Attachment | Antwort mit dem bekannten Permalink vergleichen |
https://example.com/wp-content/uploads/2025/03/montageschritt.jpg | Eigentliche Mediendatei | Datei bleibt abrufbar und hat einen passenden Inhaltstyp |
Die Form eines Permalinks ist kein verlässlicher Typnachweis. WordPress dokumentiert bei get_attachment_link() sowohl lesbare Pfade als auch die Form mit attachment_id. Filter können das Ergebnis verändern.
Die Funktion wp_get_attachment_url() liefert dagegen die Datei-Adresse. Bei einer CDN- oder Medienauslagerung kann diese auf einem anderen Host liegen. Ermittle beide Werte am konkreten Datensatz, statt aus einem Pfadnamen die Gegenadresse zu erraten.
Eine kleinere Datei aus srcset ist außerdem nicht automatisch die ursprüngliche Upload-Datei. Notiere für die Bildoptimierung, ob du Original, ausgelieferte Bildvariante oder HTML-Seite prüfst. Ein einzelner erfolgreicher Download deckt diese anderen Zugänge nicht mit ab.
Was WordPress seit 6.4 tatsächlich geändert hat
Laut Core-Entwicklungsnotiz sind Anhangsseiten bei neuen Installationen seit WordPress 6.4 standardmäßig deaktiviert. Dafür gibt es die Option wp_attachment_pages_enabled. Bei neuen Sites ist der Standard 0; bei bestehenden Sites wurde beim Upgrade 1 gesetzt, damit das bisherige Verhalten erhalten bleibt. Administratoren können die Option ändern.
Die Grenze verläuft damit zwischen Installationen und ihrer Konfiguration. Sie lautet weder „ab Version 6.4 sind alle Anhangsseiten weg“ noch „nur Bilder, die nach dem Update hochgeladen wurden, leiten weiter“.
Eine Website, die seit Jahren besteht und heute eine neuere Version verwendet, kann weiterhin Anhangsseiten ausgeben. Eine aus einer bestehenden Installation geklonte Website solltest du ebenfalls nach ihrem tatsächlichen Zustand beurteilen. Das Datum des Relaunchs sagt dir nicht, welche Option übernommen wurde.
Bei deaktivierten Anhangsseiten ist das vorgesehene Core-Ziel die Mediendatei. Eine Weiterleitung zum Elternbeitrag kann aus einer anderen Konfiguration stammen. Verwechsle diese beiden Ergebnisse nicht, wenn du Weiterleitungen dokumentierst. Ein Link zum Bild und ein Link zum erklärenden Ratgeber bedienen unterschiedliche Erwartungen.
Erst lesen: Version, Site und Datensatz feststellen
Mit Zugang zu WP-CLI kannst du die Core-Version und die Option abfragen. Führe die Befehle im richtigen WordPress-Verzeichnis aus. Im Beispiel bezeichnet --url die fiktive Ziel-Site; in einem Multisite-Netzwerk ist diese Zuordnung besonders wichtig.
bashwp core version
wp --url=https://example.com option get wp_attachment_pages_enabled
Diese Befehle lesen Werte. Die WP-CLI-Dokumentation zu option get erklärt auch die Auswahl der Ziel-Site über --url. Wird die Option nicht gefunden oder meldet der Befehl einen Fehler, notiere das Ergebnis. Mache aus einem fehlgeschlagenen Read keinen sicher ermittelten Wert 0.
Lass dir anschließend für eine bekannte Attachment-ID die beiden Adressen ausgeben. Bei ID 417 wäre die lesende Abfrage:
bashwp --url=https://example.com eval 'echo get_attachment_link(417), PHP_EOL; echo wp_get_attachment_url(417), PHP_EOL;'
Ohne Shell-Zugang kannst du die Dateiadresse aus der Mediathek und einen vorhandenen Anhangslink aus dem Frontend erfassen. Bezeichnungen und angebotene Schaltflächen hängen von Installation und Oberfläche ab. Der sichtbare Name einer Schaltfläche ersetzt die HTTP-Prüfung nicht.
Notiere außerdem Theme, relevante Medien- und SEO-Plugins sowie vorgeschaltete Cache- oder Redirect-Regeln. Die Option ist ein Hinweis auf die Core-Konfiguration. Die öffentliche Antwort entsteht aus dem gesamten System. Ein Plugin kann Links filtern, der Server bereits vor WordPress weiterleiten oder ein Cache eine ältere Antwort ausliefern.
Bei einem Bildtausch die Zuordnung erhalten
Wenn eine Redaktion ein Bild ersetzt, halte vorab fest, was sich ändern soll: nur der Bildinhalt, zusätzlich der Dateiname oder auch der Attachment-Datensatz. Diese Fälle brauchen unterschiedliche Kontrollen. Ein unveränderter sichtbarer Titel beweist keine unveränderte Dateiadresse. Eine neue Datei unter einem anderen Namen aktualisiert auch nicht zwangsläufig jeden alten Link.
Vergleiche deshalb die gespeicherten Adressen vor und nach dem Tausch. Öffne den betroffenen Beitrag, die gewünschte Bildvariante und den bisherigen Anhangslink erneut. Zeigt ein Cache noch das alte Motiv, trenne diesen Befund von einer falschen Weiterleitung. Notiere, auf welchem Host und mit welcher Bildgröße du die Abweichung siehst.
Bei einem größeren Umbau gehört diese Zuordnung in die SEO-Relaunch-Checkliste. Eine Anhangsseite auf die Datei weiterzuleiten erledigt nicht automatisch eine zusätzliche Migration alter Bilddatei-URLs. Dafür braucht ihr eine eigene Entscheidung, falls sich diese Adressen ebenfalls ändern.
Die Antwort ohne Anmeldung testen
Prüfe mindestens ein älteres und ein neueres Medium. Ergänze ein Bild mit Elternbeitrag und ein nicht zugeordnetes Medium, sofern diese Fälle existieren. Es geht um unterschiedliche Wege durch eure Installation, nicht um eine statistisch repräsentative Stichprobe.
Im Site Audit kannst du die anschließende technische Kontrolle der Website bündeln. Ergänze sie um die gezielt erfassten Anhangs-URLs. Ein gewöhnlicher Link-Crawl findet eine nicht verlinkte Alt-URL unter Umständen nicht, obwohl sie aus einem historischen Export bekannt ist.
Nutze für den ersten Abruf einen GET ohne automatische Weiterleitung. Die folgenden Befehle zeigen Header und verwerfen den Body. Unter Windows verwendest du bei Bedarf curl.exe, damit wirklich curl ausgeführt wird.
bashcurl -sS -D - -o /dev/null 'https://example.com/?attachment_id=417'
curl -sS -D - -o /dev/null 'https://example.com/ratgeber/wandregal/montageschritt/'
Unter Windows ersetzt du /dev/null durch NUL. Setze für diese Prüfung keine Anmeldung oder Browser-Cookies voraus. Ein Test im eingeloggten Admin-Browser kann einen anderen Zustand zeigen als der öffentliche Aufruf.
Erst danach verfolgst du die Kette mit -L. Lies jede Location, den abschließenden Status und den Inhaltstyp. Eine Zeile 200 am Ende verrät ohne diese Zwischenstationen nicht, ob du die Anhangsseite, einen Login oder das Bild erreicht hast.
| Prüffall | Erwartung, wenn die Anhangsseite entfallen soll | Zusätzlicher Nachweis |
|---|---|---|
| Bekannter Anhangs-Permalink | Geplante dauerhafte Weiterleitung | Ziel stimmt mit der dokumentierten Entscheidung überein |
| ID-URL desselben Attachments | Kein unbeabsichtigter zweiter HTML-Einstieg | Abweichungen zur lesbaren URL untersucht |
| Endgültige Datei-Adresse | Erfolgreicher Abruf der Mediendatei | Bild lässt sich öffnen, Inhaltstyp ist plausibel |
| Beitrag und Bildvarianten | Inhalt und Einbettung funktionieren weiter | Desktop, Mobilansicht und relevante Bildgrößen geprüft |
Eine unterschiedliche Antwort der ID- und Pfad-URL ist ein Untersuchungsbefund. Sie beweist für sich allein weder einen bestimmten Core-Bug noch ein fehlerhaftes Plugin. Die aktuelle Core-Referenz für redirect_canonical() hilft Entwicklern bei der Zuordnung. Ob genau dieser Code im konkreten Hosting unverändert läuft, muss separat feststehen.
Behalten, weiterleiten oder aus der Suche nehmen
Eine Anhangsseite kann eine sinnvolle Aufgabe haben. Denk an eine kuratierte Fotoseite mit Bildbeschreibung, Urheberangabe und einer nachvollziehbaren Download-Möglichkeit. Prüfe ihren eigenen Nutzen, eingehende Links und beobachtete Suchzugriffe, bevor du sie wie einen leeren Bildrahmen behandelst. Eine bloße Attachment-ID ist kein Qualitätsurteil.
Wenn die Seite entfallen soll, wähle das Ziel passend zur bisherigen Aufgabe. Erwartet der Klick das einzelne Bild, kann die Datei passen. Erwartet er eine Anleitung zu genau diesem Motiv, kann ein inhaltlich passender Beitrag sinnvoll sein. Ein technisch vorhandener Elternbeitrag ist nicht automatisch ein guter Ersatz. Das Bild kann mehrfach verwendet werden oder eine historische Zuordnung besitzen.
Für dauerhafte Redirects beschreibt Google in seiner Dokumentation serverseitige Weiterleitungen als geeigneten Weg. Daraus folgt keine Garantie für erhaltene Rankings. Halte die Kette kurz und prüfe das Ziel, statt alle Anhangsseiten unabhängig vom Inhalt auf die Startseite zu schicken.
Soll die HTML-Seite erreichbar bleiben, aber nicht in Google erscheinen, ist noindex eine andere Entscheidung. Google muss die Seite dafür abrufen können, wie die Dokumentation zur Indexierungssperre erklärt. Eine gleichzeitige robots.txt-Sperre kann diesen Nachweis verhindern. Prüfe die HTML-Anweisung und eventuelle HTTP-Header an genau dieser URL.
Auch ein Canonical Tag ersetzt keinen Redirect für Besucher. Im Befund gehören deshalb Antwortstatus, Weiterleitungsziel und Indexierungsanweisung in getrennte Felder. So sieht das Team, welche Wirkung tatsächlich eingerichtet wurde.
Das Bild bleibt eine eigene Prüfaufgabe
Deaktiviere Anhangsseiten nicht durch das Löschen der Medien. Die offizielle Referenz zu wp_delete_attachment() beschreibt ausdrücklich, dass beim endgültigen Löschen auch die Datei entfernt wird. Ein Bild, das ein Beitrag noch benötigt, kann dadurch fehlen.
Kontrolliere außerdem die tatsächlich eingebetteten Adressen: src und srcset, relevante Bildvarianten und gegebenenfalls den CDN-Host. Eine Redirect-Regel für HTML darf nicht versehentlich das gesamte Upload-Verzeichnis erfassen.
Googles Bild-SEO-Dokumentation nennt normale HTML-Bildelemente als wichtigen Weg zur Entdeckung. Kontrolliere daher die Seite, auf der das Bild künftig im erklärenden Zusammenhang stehen soll. Ein funktionierender Datei-Endpunkt allein beweist weder die korrekte Einbettung noch Bildsichtbarkeit in Google.
Auch Robots-Anweisungen der Datei und der HTML-Seite sind separat zu lesen. Ein pauschaler X-Robots-Tag: noindex auf allen Uploads wäre eine zusätzliche Entscheidung über die Medien selbst. Leite sie nicht stillschweigend aus der Absicht ab, nur dünne Anhangsseiten aus der Websuche zu entfernen.
Eine Änderung mit klarer Abnahme übergeben
Lege vor der Umsetzung eine kleine Zuordnungsliste an: Attachment-ID, bisheriger Permalink, Dateiadresse, gewünschtes Verhalten und Begründung. Speichere die öffentlichen Antworten mit Datum. Nach der Änderung wiederholst du dieselben Abrufe und den Besuch der einbettenden Beiträge.
Bewahre die vorherige Option und die betroffenen Regeln auf, damit sich eine unbeabsichtigte Änderung gezielt zurücknehmen lässt. Auf Produktivsystemen sollte klar sein, wer die Weiterleitung verwaltet und welche Cache-Ebene nach einer Korrektur überprüft wird.
Die Indexierung beurteilst du danach mit aktuellem Abruf und den verfügbaren Search-Console-Befunden. Alte Berichtszeilen verschwinden nicht zwingend gleichzeitig mit einer technischen Änderung. Unterscheide einen historischen Status von der heutigen Antwort.
Falls eine weiterhin gewünschte Anhangsseite erreichbar ist, aber nicht in Google erscheint, hilft die Diagnose für „Gecrawlt, zurzeit nicht indexiert“. Mehr URLs im Index sind kein sinnvolles Abnahmekriterium. Die Änderung ist technisch gelungen, wenn die beschlossenen Zugänge korrekt antworten, benötigte Bilddateien erreichbar bleiben und die Beiträge weiterhin funktionieren. Die spätere Suchentwicklung beobachtest du gesondert.