WordPress-Google-Indexierung: Der komplette Guide, damit jede Seite gefunden wird
WordPress treibt über 40 % des Webs an, doch bei Tausenden WordPress-Sites entdeckt Google bestimmte Seiten nie. Dieser Guide führt dich durch jede Einstellung, Plugin-Konfiguration und Server-Anpassung, die du brauchst, um eine vollständige, schnelle Indexierung deiner WordPress-Inhalte sicherzustellen.
In dieser Anleitung
WordPress treibt über 40 % des Webs an, aber seine Flexibilität schafft Dutzende Stellen, an denen die Indexierung kaputtgehen kann. Eine falsch gesetzte Checkbox unter Einstellungen > Lesen kann deine gesamte Site verstecken. Eine fehlkonfigurierte SEO-Plugin-Einstellung kann still und leise noindex-Direktiven hinzufügen. Ein schlecht programmiertes Theme kann doppelte Canonical-Tags einschleusen, die Googlebot verwirren.
Dieser Guide ist eine WordPress-spezifische Tour durch jeden Konfigurationspunkt, der die Indexierung beeinflusst — Core-Einstellungen, Yoast-/RankMath-Sitemaps, Permalink-Strukturen, .htaccess-Regeln und REST-API-Endpoints. Egal ob du einen Blog oder einen WooCommerce-Shop betreibst, die Schritte hier gelten.
Wie Google WordPress-Sites crawlt
Google entdeckt WordPress-Seiten über drei Hauptkanäle:
- Deine XML-Sitemap — der primäre Entdeckungsmechanismus
- Interne Links in deiner Site, denen Googlebot folgt
- Externe Backlinks, die von anderen Websites auf deine Seiten zeigen
WordPress generiert seit Version 5.5 eine eingebaute Sitemap unter /wp-sitemap.xml, aber die meisten Site-Betreiber nutzen stattdessen eine Plugin-Sitemap, weil sie mehr Kontrolle darüber bietet, welche Post-Typen, Taxonomien und Archive enthalten sind.
Wenn Googlebot deine WordPress-Site besucht, prüft er zuerst die robots.txt im Domain-Root. WordPress erzeugt eine virtuelle robots.txt über eine PHP-Funktion, statt eine statische Datei auszuliefern — Plugins und Theme-Funktionen können sie also programmatisch verändern. Die Standard-robots.txt von WordPress erlaubt alle Crawler und verweist auf die Sitemap, aber Security-Plugins fügen häufig restriktive Regeln hinzu, die den Zugriff auf /wp-admin/, /wp-includes/ und manchmal sogar /wp-content/uploads/ blockieren — das Verzeichnis, in dem all deine Medien liegen.
Nach dem Lesen der robots.txt beginnt Googlebot mit dem Crawl. WordPress liefert in der Regel gut strukturiertes HTML, aber die Rendering-Pipeline zählt. Wenn dein Theme stark auf JavaScript für das Layout setzt (üblich bei Page-Buildern wie Elementor, Divi oder WPBakery), muss Google einen zweiten Rendering-Durchgang machen. Diese zweistufige Indexierung — zuerst rohes HTML, dann die JavaScript-gerenderte Version — kann die vollständige Indexierung um Tage oder sogar Wochen verzögern. Seiten, die mit dem nativen Gutenberg-Block-Editor gebaut sind, werden serverseitig gerendert und vermeiden diese Verzögerung komplett.
WordPress stellt Inhalte auch über seine REST API unter /wp-json/wp/v2/ bereit. Googlebot crawlt REST-API-Endpoints normalerweise nicht für die Indexierung, aber bei schlecht konfigurierten Sites tauchen REST-API-URLs manchmal in Sitemaps oder internen Links auf, was die Crawl-Queue von Google durcheinanderbringt.
WordPress-Core-Einstellungen, die die Indexierung beeinflussen
Die wichtigste Indexierungs-Einstellung in WordPress liegt unter Einstellungen > Lesen. Die Checkbox mit der Beschriftung „Suchmaschinen davon abhalten, diese Website zu indexieren“ fügt jeder Seite einen <meta name="robots" content="noindex, nofollow">-Tag hinzu und ergänzt robots.txt um Disallow: /. Diese Einstellung ist für Entwicklungs- und Staging-Umgebungen gedacht, bleibt aber öfter in der Produktion aktiv, als du denkst. Jedes WordPress-Indexierungs-Audit sollte hier starten.
Die Permalink-Struktur, konfiguriert unter Einstellungen > Permalinks, bestimmt das URL-Format für jeden Beitrag und jede Seite. Die Standardstruktur nutzt schlichte Query-Strings wie /?p=123, die zwar crawlbar sind, aber null Keyword-Signale an Google liefern. Die empfohlene Struktur für die meisten Sites ist „Beitragsname“ (/%postname%/), die saubere, lesbare URLs erzeugt. Wenn du die Permalink-Struktur auf einer bestehenden Site änderst, erstellt WordPress keine automatischen Weiterleitungen für die alten URLs. Jede zuvor indexierte URL liefert eine 404, sofern du nicht Redirect-Regeln in .htaccess ergänzt oder ein Plugin wie Redirection nutzt.
Auch die Site-Adressen-Einstellungen unter Einstellungen > Allgemein sind relevant. Wenn deine WordPress-Adresse und die Site-Adresse nicht übereinstimmen oder eine www nutzt und die andere nicht, sieht Google zwei verschiedene Versionen jeder URL. WordPress regelt die www-zu-non-www-Weiterleitung über .htaccess-RewriteRules, aber Fehlkonfigurationen hier führen zu Redirect-Loops, die das Crawling komplett verhindern.
WordPress versendet außerdem XML-RPC-Pingbacks, wenn du neue Inhalte veröffentlichst. Das XML-RPC-System unter /xmlrpc.php ist zwar weitgehend zugunsten der REST API veraltet, aber unter Einstellungen > Schreiben gibt es eine Liste von „Update-Diensten“, die steuert, welche Dienste benachrichtigt werden. Den Sitemap-Ping-Endpoint von Google hier einzutragen, ist nicht mehr wirksam, da Google den Sitemap-Ping 2023 abgeschafft hat — viele veraltete Anleitungen empfehlen es trotzdem noch.
SEO-Plugin-Konfiguration: Yoast SEO und RankMath
Yoast SEO und RankMath sind die beiden beliebtesten WordPress-SEO-Plugins, und beide haben weitreichende Kontrolle über deine Indexierung. Sie erzeugen XML-Sitemaps, verwalten Meta-Robots-Direktiven, setzen Canonical-URLs und steuern, wie deine Inhalte in Suchergebnissen erscheinen.
Yoast SEO legt seine Sitemap unter /sitemap_index.xml ab. Das ist ein Sitemap-Index, der auf einzelne Sitemaps für Beiträge, Seiten, Kategorien, Tags, Autorenarchive und Custom Post Types verweist. Du steuerst, welche Inhaltstypen erscheinen, über Yoast > Einstellungen > Inhaltstypen und Yoast > Einstellungen > Kategorien & Tags. Jeder Inhaltstyp hat einen Schalter „In Suchergebnissen anzeigen“ — diesen auszuschalten fügt dem gesamten Inhaltstyp eine noindex-Direktive hinzu und entfernt ihn aus der Sitemap. Das ist die Nummer-eins-Ursache für versehentliches Noindexing in WordPress.
RankMath verfolgt einen ähnlichen Ansatz, hat aber eine granularere Oberfläche. Die Sitemap-Einstellungen liegen unter RankMath > Sitemap Settings, wo jeder Post-Typ und jede Taxonomie einen eigenen Tab hat. RankMath bietet außerdem im Beitragseditor einen „Erweitert“-Tab pro Seite, in dem du einzelne Seiten auf noindex, nofollow oder noarchive setzen kannst. Ein häufiger Fehler ist, eine Seite während der Entwicklung auf noindex zu setzen und vor der Veröffentlichung zu vergessen, das zurückzudrehen.
Beide Plugins setzen automatisch Canonical-URLs. Canonical-URL-Konflikte entstehen, wenn:
- Beide Plugins gleichzeitig aktiv sind — lass niemals zwei SEO-Plugins gleichzeitig laufen
- Ein Caching-Plugin eine veraltete Version der Seite mit einem überholten Canonical-Tag ausliefert
Die Sitemap dieser Plugins ersetzt die Core-Sitemap von WordPress. Sind sowohl die Core-Sitemap (/wp-sitemap.xml) als auch die Plugin-Sitemap (/sitemap_index.xml) aktiv, entdeckt Google möglicherweise beide und verschwendet Crawl-Budget mit doppelten Einträgen. Yoast und RankMath deaktivieren die Core-Sitemap automatisch, aber das SEO-Plugin zu deaktivieren, ohne seine Konfiguration zu entfernen, kann die Core-Sitemap reaktivieren und gleichzeitig verwaiste Sitemap-URLs in der Google Search Console hinterlassen.
Die .htaccess-Datei und Indexierungs-Kontrollen auf Serverebene
Die .htaccess-Datei im Root-Verzeichnis deiner WordPress-Installation ist eine der mächtigsten und gleichzeitig am häufigsten missverstandenen Dateien rund um die Indexierung. WordPress schreibt für die Permalink-Behandlung eigene Rewrite-Regeln in diese Datei, aber Plugins, Hoster und manuelle Edits können Regeln hinzufügen, die Crawler blockieren oder Redirect-Ketten erzeugen.
Der Standard-WordPress-.htaccess-Block prüft, ob die angeforderte Datei oder das Verzeichnis existiert, und routet die Anfrage andernfalls an index.php, damit WordPress sie verarbeitet. Security-Plugins wie Wordfence, Sucuri und iThemes Security ergänzen eigene Regeln oberhalb des WordPress-Blocks. Diese Regeln umfassen mitunter IP-basiertes Blocking, Rate-Limiting oder User-Agent-Filter, die Googlebot versehentlich aussperren können. Hat dein Security-Plugin ein Feature wie „verdächtige User Agents blockieren“, stell sicher, dass der User-Agent-String von Googlebot explizit auf der Whitelist steht.
Auch Hoster verändern .htaccess. Managed-WordPress-Hoster wie WP Engine, Kinsta und Flywheel fügen Cache-Header, GZIP-Kompressionsregeln und manchmal Redirect-Regeln für ihr CDN hinzu. Das ist normalerweise unproblematisch — aber wenn dein Hoster HTTPS via .htaccess erzwingt und deine WordPress-Einstellungen noch HTTP-URLs referenzieren, bekommst du eine Redirect-Kette:
- 1HTTP zu HTTPS (über
.htaccess) - 2www-/non-www-Normalisierung (über WordPress)
Jede Weiterleitung in der Kette kostet Crawl-Budget und erhöht die Latenz.
Um deine .htaccess zu prüfen, lad sie via SFTP oder den Datei-Manager deines Hosters herunter und geh jeden Regelblock durch. Achte auf:
Deny from all-Regeln, die ganze Verzeichnisse blockieren könntenRewriteRule-Muster, die Crawler-User-Agents umleitenHeader set X-Robots-Tag-Direktiven, die noindex auf Server-Ebene setzen
Der X-Robots-Tag-HTTP-Header ist besonders heimtückisch, weil er nicht im Seitenquelltext erscheint — du siehst ihn nur in den HTTP-Response-Headern via curl oder den Browser-Devtools.
Plugin-Konflikte und Theme-Probleme, die die Indexierung blockieren
Die Plugin-Architektur von WordPress bedeutet, dass jedes installierte Plugin HTTP-Header verändern, Meta-Tags einschleusen, die robots.txt modifizieren oder deine Sitemap ändern kann. Die häufigsten Indexierungs-Killer sind:
Caching-Plugins (WP Rocket, W3 Total Cache, LiteSpeed Cache), die veraltetes HTML mit überholten Meta-Robots-Tags oder Canonical-URLs ausliefern. Wenn du eine Seite von noindex auf index umstellst, kann die Cache-Version weiterhin den noindex-Tag servieren, bis der Cache geleert wird. Leer nach jeder SEO-relevanten Änderung immer den kompletten Page-Cache.
Mitglieder- und Paywall-Plugins (MemberPress, Restrict Content Pro, WooCommerce Memberships), die Inhalte in Auth-Checks einpacken. Versteckt das Plugin Inhalte hinter einem Login ohne Fallback für anonyme Nutzer, sieht Googlebot entweder ein Login-Formular oder leeren Content. Manche Mitglieder-Plugins bieten eine Option „Excerpt für Suchmaschinen anzeigen“ — aktivier sie, damit Google einen sinnvollen Snippet indexieren kann.
Page-Builder-Plugins speichern Inhalte in eigenen Datenbankformaten, die WordPress' Standard-the_content()-Funktion nicht ausgibt. Elementor speichert seine Layout-Daten als Post-Meta und rendert sie per JavaScript. Werden Elementors CSS- und JS-Dateien in robots.txt blockiert, kann Google die Seite nicht rendern und indexiert ein leeres Layout. Das gilt genauso für Divi, Beaver Builder und WPBakery. Prüf das URL-Prüftool in der Google Search Console und klick „Gecrawlte Seite ansehen“, um genau zu sehen, was Googlebot rendert.
Auch Themes können stören. Manche Themes bringen eigene SEO-Funktionen mit — Meta-Description-Felder, Open-Graph-Tags oder sogar Sitemap-Generatoren — die mit deinem SEO-Plugin in Konflikt geraten. Theme-generierte Meta-Tags können doppelte Title-Tags und Description-Tags in deinem HTML-Head erzeugen. Schau in den Seitenquelltext und such nach doppelten <meta name="description">- oder <meta name="robots">-Tags. Ergänzt dein Theme eigene, deaktivier das Feature in den Theme-Einstellungen oder wechsel das Theme.
WordPress REST API und Crawl-Budget-Optimierung
Die WordPress REST API stellt deine Inhalte unter /wp-json/wp/v2/posts, /wp-json/wp/v2/pages und ähnlichen Endpoints bereit. Sie ist nicht für Suchmaschinen gedacht, aber mitunter landen diese URLs im Google-Index, wenn sie aus deiner Sitemap, dem JavaScript deines Themes oder externen Quellen verlinkt werden. REST-API-Responses liefern JSON, kein HTML — indexierte API-URLs erscheinen also als rohe Daten in den Suchergebnissen.
Um zu verhindern, dass REST-API-URLs indexiert werden, ergänze einen X-Robots-Tag: noindex-Header bei den REST-API-Responses. Das geht mit einem kleinen Code-Snippet in der functions.php deines Themes oder einem eigenen Plugin. Manche SEO-Plugins erledigen das automatisch — verifizier es, indem du eine REST-API-URL aufrufst und die Response-Header prüfst.
Crawl-Budget ist bei großen WordPress-Sites ein reales Thema. Hast du Tausende Beiträge plus Tag-Archive, Kategorie-Archive, Datums-Archive, Autoren-Archive und paginierte Versionen all dieser, muss Google Zehntausende URLs crawlen. Viele dieser Archivseiten haben dünnen Content. Stell in deinen SEO-Plugin-Einstellungen folgende auf noindex:
- Tag-Archive — enthalten oft nur 1-2 Beiträge
- Datums-Archive — Monate, in denen du nur einmal veröffentlicht hast
- Autoren-Archive — auf Single-Author-Blogs überflüssig
So bündelst du dein Crawl-Budget auf deine echten Inhalte.
WordPress generiert Feed-URLs unter /feed/, /comments/feed/ und pro Kategorie und Tag. Das sind valide Entdeckungsmechanismen und sollten crawlbar bleiben, aber sie sollten nicht indexiert werden. Die meisten SEO-Plugins ergänzen Feed-Responses standardmäßig um noindex. Verifizier es, indem du /feed/ aufrufst und im XML-Header nach einer noindex-Direktive suchst.
Zuletzt: Denk an die Antwortzeit deiner Site. WordPress auf Shared Hosting mit vielen aktiven Plugins hat oft eine Time to First Byte (TTFB) von 2-4 Sekunden. Googlebot interpretiert langsame Antworten als Signal, dass der Server überlastet ist, und reduziert seine Crawl-Rate. Setz auf Server-seitiges Caching (Redis oder Memcached Object Cache, Page Cache über deinen Hoster), um die TTFB unter 500 ms zu drücken. Allein damit kannst du dramatisch mehr Seiten pro Tag bei Google crawlen lassen.
Schritt-für-Schritt-Anleitung
Prüf, dass die Checkbox „Suchmaschinen davon abhalten“ nicht aktiviert ist
Logg dich in dein WordPress-Admin-Dashboard ein und navigier zu Einstellungen > Lesen. Scroll runter zum Abschnitt „Sichtbarkeit für Suchmaschinen“.
Die Checkbox „Suchmaschinen davon abhalten, diese Website zu indexieren“ muss bei Produktivsites deaktiviert sein. Ist sie gesetzt, häkel sie ab und klick Änderungen speichern.
Diese eine Checkbox steuert eine seitenweite noindex-Direktive, die Google komplett daran hindert, irgendeine Seite deiner Site zu indexieren. Nach dem Abhaken: Schau in den Quelltext und bestätige, dass <meta name="robots" content="noindex, nofollow"> nicht mehr im <head> auftaucht.
Konfigurier Sitemap und Indexierungs-Settings deines SEO-Plugins
Yoast SEO: Geh zu Einstellungen > Inhaltstypen und aktivier „In Suchergebnissen anzeigen“ für Beiträge und Seiten. Unter Kategorien & Tags indexier Kategorien, aber überleg, Tags auf noindex zu setzen.
RankMath: Geh zu Sitemap Settings und schalt jeden Post-Typ an. Unter Titles & Meta prüf, dass kein Inhaltstyp den Robots Meta auf noindex stehen hat.
Ruf /sitemap_index.xml im Browser auf und bestätige, dass valides XML mit Links zu deinen Inhalten geladen wird.
Wähl die optimale Permalink-Struktur und richte Weiterleitungen ein
Navigier zu Einstellungen > Permalinks und wähl „Beitragsname“ als Permalink-Struktur. So entstehen URLs wie deinedomain.de/dein-beitragstitel/ — sauber, keyword-reich und für Google leicht zu parsen.
Wenn du auf einer bestehenden Site von einer anderen Struktur wechselst:
- 1Installier das Redirection-Plugin bevor du die Änderung machst
- 2Wechsel die Permalink-Struktur und speicher
- 3Das Redirection-Plugin loggt automatisch 404-Fehler von alten URLs
- 4Richte Redirect-Regeln von den alten Mustern zu den neuen ein
War deine alte Struktur z. B. /%year%/%monthnum%/%postname%/, leg eine Regex-Weiterleitung von ^/\d{4}/\d{2}/(.+)$ auf /$1 an, um Link-Equity zu erhalten.
Audit von robots.txt und .htaccess auf Crawler-Sperren
Ruf deinedomain.de/robots.txt auf und prüf, dass keine Disallow: /-Regel existiert und deine Sitemap-URL mit einer Sitemap:-Direktive gelistet ist.
Lad .htaccess via SFTP runter und such nach User-Agent-Sperren, IP-Restriktionen, die Googles 66.249.x.x-Range betreffen, und X-Robots-Tag-Headern von Security-Plugins. Findest du verdächtige Regeln, deaktivier Security-Plugins eines nach dem anderen, um die Quelle zu identifizieren.
Reich deine Sitemap bei der Google Search Console ein
Logg dich in die Google Search Console ein und wähl dein WordPress-Property. Navigier zu Sitemaps in der linken Seitenleiste und trag deine Sitemap-URL ein:
/sitemap_index.xmlbei Yoast oder RankMath/wp-sitemap.xmlbei der WordPress-Core-Sitemap
Klick Senden. Google beginnt mit der Verarbeitung der Sitemap, was üblicherweise 24-48 Stunden für den ersten Read dauert.
Nach dem Einreichen beobachte den Sitemap-Bericht auf typische Fehler:
- URLs mit 404 (gelöschte Beiträge noch in der Sitemap)
- URLs durch robots.txt blockiert
- URLs mit Redirect-Ketten
Der Seiten-Bericht zeigt dir, wie viele eingereichte URLs indexiert, ausgeschlossen oder fehlerhaft waren.
Test das Seiten-Rendering mit dem URL-Prüftool
Nutz in der Google Search Console die URL-Prüfung für deine wichtigsten Seiten. Klick „Live-URL testen“ und verifizier: Der HTTP-Status ist 200, der Indexierungs-Status zeigt, dass die URL indexierbar ist, und das gerenderte Screenshot unter „Gecrawlte Seite ansehen“ passt zu dem, was dein Browser zeigt.
Zeigt die gerenderte Seite fehlenden Content oder leere Bereiche, hast du ein JavaScript-Rendering-Problem durch blockierte Ressourcen oder Page-Builder-Konflikte.
Nutz IndexBolt, um die Indexierung verbleibender Seiten zu beschleunigen
Nachdem du alle technischen Fixes oben erledigt hast, können manche Seiten über Googles natürlichen Crawl-Zyklus immer noch Wochen brauchen, um indexiert zu werden — besonders auf neueren oder authority-schwächeren WordPress-Sites.
Nutz IndexBolt, um diese URLs direkt zur Indexierung einzureichen:
- 1Exportier deine Sitemap-URLs (find sie in deiner
sitemap_index.xmldurch Klick auf jede Sub-Sitemap) - 2Füg sie ins Einreichungsformular von IndexBolt ein
- 3Lass unsere API sie durch die Google-Indexierungs-Pipeline schieben
Für zeitkritische Inhalte wie neue Produktseiten, Event-Ankündigungen oder eilige News nutz IndexBolts Instant-Indexierung, um die Warteschlange zu überspringen und Seiten in Stunden statt Tagen indexieren zu lassen.
Häufige Probleme und wie du sie behebst
Die Checkbox „Suchmaschinen davon abhalten“ ist immer noch aktiviert
Ursache: Diese Checkbox unter Einstellungen > Lesen wurde während der Site-Entwicklung oder Migration aktiviert und nie wieder ausgeschaltet. Manche Hoster aktivieren sie standardmäßig auf Staging-Umgebungen, und sie überlebt das Pushen von Staging in die Produktion. Automatische WordPress-Installer aus Hosting-Control-Panels lassen sie manchmal ebenfalls aktiviert.
Lösung: 1. Geh zu **Einstellungen > Lesen**, häkel **„Suchmaschinen davon abhalten, diese Website zu indexieren“** ab und klick **Änderungen speichern** 2. Schau in den Quelltext deiner Startseite und bestätige, dass der **noindex**-Meta-Tag weg ist 3. Prüf die `robots.txt` (`deinedomain.de/robots.txt`), dass sie nicht mehr `Disallow: /` enthält 4. **Leer den Cache jedes Caching-Plugins**, damit das aktualisierte HTML sofort ausgeliefert wird
SEO-Plugin setzt einen ganzen Post-Typ oder eine Taxonomie auf noindex
Ursache: In Yoast SEO wurde der Schalter „In Suchergebnissen anzeigen“ unter Einstellungen > Inhaltstypen für einen Post-Typ ausgeschaltet. In RankMath wurde der Robots Meta für einen Inhaltstyp unter Titles & Meta auf noindex gesetzt. Das fügt jeder Seite dieses Typs eine noindex-Direktive hinzu und entfernt sie aus der Sitemap, selbst wenn einzelne Beiträge wertvollen Content haben.
Lösung: Öffne die Einstellungen deines SEO-Plugins und geh jeden Post-Typ und jede Taxonomie durch. - **Yoast:** Geh zu **Einstellungen > Inhaltstypen** und aktivier **„In Suchergebnissen anzeigen“** für jeden Typ, der indexiert werden soll - **RankMath:** Geh zu **Titles & Meta > Post Types** und setz den Robots Meta auf **„index“** Nach der Änderung regenerier deine Sitemap, indem du sie im Browser aufrufst und bestätigst, dass die betroffenen URLs jetzt auftauchen. **Reich die Sitemap in der Google Search Console erneut ein.**
Permalink-Struktur-Wechsel verursacht Massen-404
Ursache: Eine Änderung der Permalink-Struktur unter Einstellungen > Permalinks aktualisiert alle internen Links, erstellt aber keine Weiterleitungen für die alten URL-Muster. Alle externen Links, Bookmarks oder zuvor indexierten URLs, die auf die alte Struktur zeigen, liefern jetzt 404-Fehler. Google deindexiert diese Seiten irgendwann.
Lösung: 1. Installier das **Redirection**-Plugin (oder nutz deine `.htaccess` direkt), um musterbasierte **301-Weiterleitungen** von der alten URL-Struktur zur neuen anzulegen 2. War deine alte Struktur `/%category%/%postname%/`, leg ein Redirect-Mapping von alten URLs zur neuen `/%postname%/`-Struktur an 3. Beobachte **404-Fehler** im Seiten-Bericht der Google Search Console 4. Ergänze individuelle Redirects für alle URLs, die die musterbasierte Regel verfehlt hat Mit der Zeit aktualisiert Google seinen Index entsprechend der neuen URL-Struktur.
Mehrere Plugins erzeugen widersprüchliche Sitemaps
Ursache: Zwei gleichzeitig laufende SEO-Plugins (z. B. Yoast und RankMath) oder ein SEO-Plugin neben einem dedizierten Sitemap-Plugin wie Google XML Sitemaps erzeugen mehrere Sitemap-Dateien. Wenn robots.txt oder die Google Search Console beide referenzieren, verarbeitet Google doppelte URL-Einträge und kann sie als verdächtig einstufen. Manche All-in-One-Security-Plugins wie All In One WP Security erzeugen ebenfalls eigene Sitemaps.
Lösung: **Nutz nur ein Plugin für die Sitemap-Generierung.** Wenn du Yoast oder RankMath einsetzt, deaktivier oder entfern alle Stand-alone-Sitemap-Plugins. 1. Prüf die `robots.txt` auf mehrere `Sitemap:`-Zeilen und entfern Duplikate 2. In der Google Search Console: Geh zu **Sitemaps** und entfern veraltete oder doppelte Einreichungen 3. Verifizier, dass die WordPress-Core-Sitemap unter `/wp-sitemap.xml` durch dein SEO-Plugin deaktiviert ist (Yoast und RankMath erledigen das automatisch, wenn aktiv)
Caching-Plugin liefert veraltete noindex-Seiten aus
Ursache: Du hast eine Seite von noindex auf index umgestellt (oder ein anderes Meta-Tag-Problem behoben), aber dein Caching-Plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache usw.) liefert immer noch das alte gecachte HTML mit der noindex-Direktive aus. Page-Caches können je nach Konfiguration Stunden oder Tage persistieren.
Lösung: **Leer nach jeder SEO-relevanten Änderung deinen kompletten Page-Cache:** - **WP Rocket:** Einstellungen > WP Rocket > **„Cache leeren“** - **W3 Total Cache:** Performance > Dashboard > **„Empty All Caches“** - **LiteSpeed Cache:** LiteSpeed Cache > Toolbox > **„Purge All“** Wenn du ein CDN wie **Cloudflare** nutzt, leer auch den CDN-Cache im Cloudflare-Dashboard. Verifizier nach dem Leeren, indem du die Seite in einem **Inkognito-Fenster** aufrufst und im Quelltext bestätigst, dass die richtigen Meta-Tags da sind.
Schweres Theme und Page Builder bremsen die Crawl-Rate
Ursache: Komplexe WordPress-Themes mit großen CSS-/JS-Bundles und Page Builder wie Elementor oder Divi erhöhen die Ladezeit deutlich. Wenn die Time to First Byte 2 Sekunden überschreitet, reduziert Googlebot seine Crawl-Rate, um den Server nicht zu überlasten. Auf Shared Hosting kann das dein tägliches Crawl-Volumen von Hunderten Seiten auf nur ein paar Dutzend drücken.
Lösung: Aktivier **Server-seitiges Caching**, um Antwortzeiten zu verbessern: 1. Installier ein Caching-Plugin und konfigurier es für **Full-Page-Caching** 2. Nutz einen **Object-Cache** (**Redis** oder **Memcached**), wenn dein Hoster das unterstützt 3. **Minifizier und kombinier** CSS-/JS-Dateien über dein Caching-Plugin 4. Erwäg den Wechsel zu einem Managed-WordPress-Hoster (**WP Engine**, **Kinsta**, **Cloudways**), der Server-Caching und CDN inkludiert Verifizier deine Crawl-Rate in der Google Search Console unter **Einstellungen > Crawl-Statistiken**, wo tägliche Crawl-Requests, Download-Größe und Antwortzeiten angezeigt werden.
Profi-Tipps
WordPress-Sites können Hunderte oder Tausende Seiten haben, die darauf warten, dass Google sie entdeckt. Mit IndexBolt kannst du deine WordPress-URLs direkt zur Indexierung einreichen und musst nicht auf den nächsten Googlebot-Crawl warten. Egal ob du gerade ein noindex-Problem behoben oder einen Schwung neuer Beiträge veröffentlicht hast — bring sie in Stunden statt Wochen in Googles Index.
100 Gratis-Credits. Keine Kreditkarte nötig. Ergebnisse in unter 24 Stunden.
Häufig gestellte Fragen
Wie lange braucht Google, um eine neue WordPress-Seite zu indexieren?+
Bei **etablierten WordPress-Sites** mit guten Crawl-Raten erscheinen neue Seiten typischerweise innerhalb von **2-7 Tagen** nach Veröffentlichung bei Google. Bei **neueren Sites** oder Sites mit niedriger Domain-Autorität kann es **2-6 Wochen** dauern. Wenn deine Seite nach 4 Wochen nicht indexiert ist, blockiert wahrscheinlich ein technisches Problem das Crawling oder Indexieren. Mit **IndexBolt** kannst du diesen Zeitrahmen für dringende Seiten auf **Stunden** verkürzen.
Soll ich die WordPress-Core-Sitemap oder die meines SEO-Plugins nutzen?+
Nutz die **Sitemap deines SEO-Plugins**, wenn du Yoast SEO oder RankMath installiert hast. Diese Plugins erzeugen umfassendere Sitemaps mit besserer Kontrolle darüber, welche Inhaltstypen enthalten sind, und sie **deaktivieren die Core-Sitemap automatisch**, um Duplikate zu verhindern. Die WordPress-Core-Sitemap unter `/wp-sitemap.xml` reicht für einfache Sites ohne SEO-Plugin, hat aber nicht die granularen Steuerungen, die Yoast und RankMath bieten.
Kann ich zu viele Seiten in meiner WordPress-Sitemap haben?+
Eine einzelne Sitemap-Datei darf laut Sitemap-Protokoll bis zu **50.000 URLs** enthalten. Yoast und RankMath splitten große Sitemaps in Sub-Sitemaps von je **1.000 URLs** (konfigurierbar). Die eigentliche Sorge ist nicht die Sitemap-Größe, sondern die **Qualität der URLs**. Enthält deine Sitemap Tausende dünner Archivseiten, Tag-Seiten mit einem einzigen Beitrag oder paginierte URLs, wird Googles **Crawl-Budget** für Seiten mit geringem Wert verschwendet. Halt deine Sitemap schlank, indem du **dünne Inhaltstypen auf noindex setzt**.
Beeinflusst ein WordPress-Theme-Wechsel meine Google-Rankings?+
Theme-Wechsel können **definitiv Indexierung und Rankings beeinflussen**. Ein neues Theme kann: - Deine **Seitenstruktur** und **Heading-Hierarchie** verändern - **Interne Linkmuster** modifizieren - **Strukturierte Daten** ergänzen oder entfernen - Anderes **JavaScript-Rendering**-Verhalten einführen Ist das neue Theme langsamer oder nutzt viel JavaScript, crawlt und indexiert Google deine Seiten möglicherweise weniger effektiv. **Test einen Theme-Wechsel immer zuerst auf einer Staging-Site** und überwache den Seiten-Bericht der Google Search Console danach eng.
Warum erscheinen meine WordPress-Tag-Seiten als „Gefunden – zurzeit nicht indexiert“?+
Google stuft Tag-Archivseiten häufig als **wenig wertvoll** ein, weil sie dieselben Beitrags-Excerpts enthalten, die auf anderen Archivseiten auftauchen (Kategorieseiten, Autorenseiten, Blog-Homepage). Wenn Google feststellt, dass eine Seite keinen einzigartigen Mehrwert bietet, entdeckt es die URL, **entscheidet sich aber gegen die Indexierung**. Best Practice ist, **Tag-Archive in den SEO-Plugin-Einstellungen auf noindex zu setzen**, es sei denn, deine Tags haben substanziellen, einzigartigen Content. Das hilft sogar, deine wichtigen Seiten schneller indexieren zu lassen, weil sich das **Crawl-Budget bündelt**.
Meine WordPress-Site nutzt einen Page Builder. Beeinflusst das die Indexierung?+
Page Builder wie **Elementor**, **Divi** und **WPBakery** speichern Inhalte in eigenen Formaten und rendern sie im Frontend per JavaScript. Google kann JavaScript rendern, tut das aber in einer **verzögerten zweiten Passe**, was bedeutet, dass mit Page Buildern gebaute Seiten länger brauchen können, um vollständig indexiert zu werden. Noch wichtiger: Wenn deine `robots.txt` die CSS- oder JS-Dateien des Page Builders blockiert (was manche Security-Plugins tun), kann Google **die Seite gar nicht rendern** und indexiert ein leeres Layout. Test es mit dem **URL-Prüftool** der Google Search Console, um sicherzugehen, dass Google die voll gerenderte Seite sieht.