Drupal-Google-Indexierung: Der komplette Guide, damit dein Drupal-Content in der Suche landet
Drupal ist eine der mächtigsten CMS-Plattformen, im Einsatz bei Regierungen, Universitäten und großen Enterprises. Diese Flexibilität bedeutet aber, dass Indexierung nicht automatisch passiert — du musst die richtigen Module installieren und konfigurieren, damit Google deinen Content entdecken und indexieren kann.
In dieser Anleitung
Drupal ist ein Content-Management-Framework, bekannt für Flexibilität, Sicherheit und Skalierbarkeit. Es treibt einige der komplexesten Sites des Webs an: Regierungsportale mit Tausenden Seiten, Universitätswebsites mit mehreren Departments und Inhaltstypen, Enterprise-Intranets und große Medienpublikationen. Drupals Stärke ist, dass es praktisch jede Content-Architektur abbilden kann — vom einfachen Blog bis zur mehrsprachigen, mehrsiteigen Plattform mit Hunderten Inhaltstypen und komplexen Zugriffsrechten.
Diese Flexibilität hat einen Preis: Drupal liefert out of the box keine SEO-Features. Anders als WordPress (mit eingebauter Sitemap und Basis-SEO), Shopify (auto-generierte Sitemaps und Canonical-Tags) oder Ghost (umfassende SEO standardmäßig) verlangt Drupal die Installation und Konfiguration von Contributed Modules für jede SEO-Funktion. XML-Sitemap-Generierung, URL-Aliase, Meta-Tag-Verwaltung, Redirect-Handling und robots.txt-Anpassung — alles braucht eigene Module.
Der Kern der Drupal-SEO-Module — oft „Drupal-SEO-Stack“ genannt — umfasst XML Sitemap (oder Simple XML Sitemap) für die Sitemap-Generierung, Pathauto für automatische URL-Aliase, Metatag für Meta-Tag-Verwaltung, Redirect für 301-Redirect-Handling und das robots.txt-Modul, um Crawler-Zugriff zu steuern. Ohne diese Module generiert Drupal URLs wie /node/123 (opake numerische Pfade), hat keine XML-Sitemap, erzeugt keine Meta-Descriptions und liefert nur eine Basis-robots.txt, die du nur auf Dateisystem-Ebene bearbeiten kannst.
Dieser Guide geht jedes Modul und jede Konfiguration durch, die nötig sind, um eine Drupal-Site voll indexierbar zu machen. Egal ob du Drupal 10, 11 oder noch eine Drupal-9-Site pflegst — die Module und Konzepte sind weitgehend dieselben. Wir behandeln Installation, Konfiguration, typische Stolpersteine spezifisch für Drupals Architektur und fortgeschrittene Techniken für große Drupal-Installationen.
Der Drupal-SEO-Modul-Stack
Eine ordentlich konfigurierte Drupal-Site für Suchmaschinen-Indexierung verlangt einen bestimmten Satz Contributed Modules. Jedes Modul kümmert sich um einen anderen SEO-Aspekt, und zusammen liefern sie umfassenden Indexierungs-Support.
Simple XML Sitemap (oder das ältere XML Sitemap-Modul) erzeugt deine /sitemap.xml-Datei. Du kannst festlegen, welche Inhaltstypen, Taxonomie-Vokabulare, Menüs und Custom-Entity-Types in die Sitemap aufgenommen werden. Pro Typ lassen sich Priorities und Change-Frequencies setzen. Simple XML Sitemap ist die moderne Wahl und unterstützt Drupal 10 und 11 nativ, während das ältere XML-Sitemap-Modul Kompatibilitätsprobleme mit neueren Drupal-Versionen haben kann.
Pathauto erzeugt automatisch lesbare URL-Aliase basierend auf konfigurierbaren Mustern. Statt /node/123 entstehen URLs wie /blog/my-article-title basierend auf Token-Patterns, die du definierst. Pathauto hängt vom Token-Modul für dynamische URL-Generierung ab. Ohne Pathauto ist jede Drupal-Seite nur unter ihrem internen Node-Pfad erreichbar — schrecklich für Nutzer und SEO.
Das Metatag-Modul liefert eine UI zur Meta-Tag-Konfiguration (Title, Description, Canonical, Robots, Open Graph, Twitter Cards und mehr) auf globaler, Inhaltstyp- und Einzelknoten-Ebene. Es unterstützt Token-Replacements, sodass du Muster wie „[node:title] | [site:name]“ für Title-Tags anlegen kannst. Ohne Metatag-Modul erzeugt Drupal nur einen Basis-<title>-Tag — ohne Meta-Description, ohne Canonical-URL, ohne Social-Meta-Tags.
Das Redirect-Modul verwaltet 301-Weiterleitungen. Änderst du einen URL-Alias (manuell oder via Pathauto), kann das Redirect-Modul automatisch einen Redirect von der alten zur neuen URL anlegen. Es bietet außerdem eine UI für manuelle Redirects und kann typische Redirect-Probleme wie Trailing-Slash-Inkonsistenzen und Mixed-Case-URLs beheben.
Das robots.txt-Modul (oder RobotsTxt-Modul) erlaubt, deine robots.txt-Datei über die Drupal-Admin-Oberfläche zu verwalten, statt die Datei direkt auf dem Server zu bearbeiten. Wichtig, weil Drupals robots.txt eine statische Datei im docroot ist und Änderungen bei Core-Updates überschrieben werden können.
URL-Aliase mit Pathauto konfigurieren
URL-Aliase sind fundamental für Drupal-SEO. Drupals interne Pfade (/node/123, /taxonomy/term/45) sind zwar crawlbar und indexierbar, liefern aber keine Keyword-Informationen und schaffen eine opake Site-Struktur. Pathauto löst das, indem es URL-Aliase automatisch nach von dir definierten Mustern generiert.
Um Pathauto zu konfigurieren, installier es per Composer (composer require drupal/pathauto), aktivier es unter /admin/modules und konfigurier dann die Muster unter /admin/config/search/path/patterns. Erstell für jeden Inhaltstyp ein Muster mit Tokens. Typische Muster: /blog/[node:title] für Blog-Artikel, /[node:content-type]/[node:title] für mehrere Inhaltstypen, /products/[node:field_product_category:entity:name]/[node:title] für hierarchische Produkt-URLs und /[node:menu-link:parents:join-path]/[node:title] für menü-hierarchiebasierte URLs.
Pathauto nutzt das Token-Modul, um diese Muster aufzulösen. Es schreibt Titel automatisch klein, ersetzt Leerzeichen durch Bindestriche, entfernt Sonderzeichen und kürzt lange URLs. Du kannst die Transliterations-Einstellungen unter /admin/config/search/path/settings anpassen, um zu steuern, wie Sonderzeichen, Akzente und nicht-lateinische Schriften behandelt werden.
Eine kritische Pathauto-Einstellung ist die „Update action“ für bestehende Aliase. Wenn du den Titel eines Nodes änderst, soll Pathauto den URL-Alias aktualisieren? Wenn ja, bricht die alte URL, sofern nicht das Redirect-Modul installiert ist. Empfohlene Konfiguration: „Create a new alias. Leave the existing alias functioning“ — erzeugt einen neuen Alias und behält den alten aktiv. Zusammen mit dem Redirect-Modul leitet die alte URL automatisch zur neuen weiter.
Für bestehende Sites mit Tausenden bereits in Google indexierter /node/123-URLs kann Pathauto Aliase für allen vorhandenen Content im Bulk generieren. Geh zu /admin/config/search/path/update_bulk und wähl die zu verarbeitenden Inhaltstypen. Nach der Bulk-Generierung installier das Redirect-Modul, um automatische Redirects von /node/123-Pfaden zu den neuen Aliasen zu schaffen. So folgt Google den Redirects und aktualisiert seinen Index zu den sauberen URLs.
Metatag-Modul-Konfiguration für die Indexierung
Das Metatag-Modul ist essenziell, um zu steuern, wie Google deine Seiten sieht. Installier es per Composer (composer require drupal/metatag) und aktivier das Metatag-Modul samt Submodulen: Metatag: Open Graph, Metatag: Twitter Cards und Metatag: Verification (für Search-Console-Verifizierungstags).
Konfigurier globale Defaults unter /admin/config/search/metatag. Die globale Konfiguration setzt Fallback-Meta-Tags für jede Seite ohne spezifischere Konfiguration. Setz den globalen Titel auf „[current-page:title] | [site:name]“, die Description auf „[node:summary]“ (oder leer lassen, um generische Descriptions zu vermeiden) und die Canonical-URL auf „[current-page:url]“.
Leg dann Inhaltstyp-spezifische Overrides an. Für Blog-Artikel könntest du den Titel auf „[node:title] - Blog | [site:name]“ und die Description auf „[node:field_meta_description]“ setzen (mit einem dedizierten Meta-Description-Feld, das du dem Inhaltstyp hinzufügst). Für Produktseiten nutz produkt-spezifische Tokens. Für Taxonomy-Term-Seiten nutz „[term:name] - [vocabulary:name] | [site:name]“ als Titel-Muster.
Das Metatag-Modul steuert außerdem die Robots-Meta-Direktive pro Inhaltstyp und pro Node. Für Inhaltstypen, die nicht indexiert werden sollen (admin-only-Inhaltstypen, Webform-Bestätigungsseiten, User-Profile), setz Robots-Meta auf „noindex, follow“ auf Inhaltstyp-Ebene. Das verhindert die Indexierung, lässt Google aber den Links folgen.
Für einzelne Nodes können Content-Editoren die Meta-Tags im „Meta tags“-Fieldset des Node-Edit-Formulars überschreiben. Trainier deine Editoren, Custom-Meta-Descriptions für wichtigen Content zu schreiben — die auto-generierte Summary ist oft nicht suchoptimiert. Wenn du Meta-Description-Schreiben erzwingen willst, mach das Feld via Form-Display-Konfiguration zur Pflicht oder nutz einen Custom-Validation-Handler.
Das Metatag-Modul unterstützt zudem hreflang-Tags für mehrsprachige Sites via Metatag: hreflang-Submodul. Ist deine Drupal-Site mehrsprachig (mit dem Core-Translation-Modul), aktivier hreflang und konfigurier es, um automatisch hreflang-Tags zu generieren, die alle Sprachversionen jeder Seite verlinken.
XML-Sitemap-Generierung und -Konfiguration
Installier Simple XML Sitemap per Composer (composer require drupal/simple_sitemap) und aktivier es. Konfigurier es unter /admin/config/search/simplesitemap. Das Modul erlaubt mehrere Sitemaps (nützlich bei großen Sites mit verschiedenen Content-Sektionen) und das Auswählen von Entity-Types, Bundles und konkreten Entities.
Für die meisten Drupal-Sites nimm veröffentlichte Nodes von Inhaltstypen auf, die indexiert werden sollen (Articles, Pages, Produkte), veröffentlichte Taxonomy-Term-Pages mit substanziellem Inhalt und Custom-Entity-Types, die öffentliche Seiten erzeugen. Schließ administrative oder zugriffsbeschränkte Inhaltstypen aus und solche, die von Natur aus dünn sind (Webform-Submissions, User-Profile).
Simple XML Sitemap unterstützt Priority- und Changefreq-Settings pro Inhaltstyp. Google hat erklärt, diese Hints weitgehend zu ignorieren, aber sie helfen, deine Sitemap zu organisieren und die relative Wichtigkeit deines Contents zu signalisieren. Setz Homepage-Priority auf 1.0, Hauptinhaltstypen auf 0.8 und Sekundärinhalte wie Taxonomy-Terms auf 0.5.
Das Modul erzeugt die Sitemap standardmäßig unter /sitemap.xml und splittet sie in mehrere Dateien, wenn die URL-Anzahl das konfigurierte Limit überschreitet (Default 2000, Max 50.000 laut Sitemap-Spec). Bei großen Drupal-Sites mit Zehntausenden Seiten kann die Sitemap-Generierung ressourcenintensiv sein. Konfigurier Cron, die Sitemap außerhalb der Stoßzeiten zu regenerieren, und setz das Regenerations-Intervall sinnvoll (alle 6-24 Stunden für die meisten Sites).
Ein häufiges Problem bei Drupal-Sitemaps ist Entity-Access. Drupals Permission-System kann den Sitemap-Generator daran hindern, Nodes zu erreichen, die für anonyme Nutzer sichtbar sind, aber nicht für den Cron-User. Das Simple-XML-Sitemap-Modul erzeugt die Sitemap während der Cron-Ausführung mit den Berechtigungen des anonymen Users by default. Wenn deine Nodes spezielle Permissions zum Anzeigen brauchen, verifizier, dass anonyme Nutzer Zugriff haben, oder konfigurier das Modul so, dass es die Sitemap mit den Permissions eines anderen Users erzeugt.
Nach der Sitemap-Konfiguration reich sie in der Google Search Console unter Sitemaps > Add a new sitemap > deinedomain.de/sitemap.xml ein. Überwache den Sitemap-Status auf Fehler wie 404-URLs (gelöschte Nodes noch in der Sitemap), blockierte URLs (robots.txt-Konflikte) und Redirect-URLs (Nodes mit geänderten Aliasen).
Drupals Node-Pfade, Aliase und Duplicate Content
Drupal hat ein einzigartiges Duplicate-Content-Problem, das andere CMS nicht teilen: Content ist sowohl unter dem internen Node-Pfad (/node/123) als auch unter dem URL-Alias (/blog/my-article) erreichbar. Ohne richtige Konfiguration kann Google beide URLs indexieren — Duplicate-Content, der Ranking-Signale auf zwei URLs für dieselbe Seite splittet.
Die erste Verteidigung ist die Redirect-Modul-Einstellung „Enforce clean and canonical URLs“. Wenn aktiviert, führt der Aufruf von /node/123 für einen Node mit Alias /blog/my-article zu einer 301-Weiterleitung auf den Alias. Das sagt Google, dass der Alias die kanonische URL ist und der Node-Pfad ignoriert werden soll. Aktivier die Einstellung unter /admin/config/search/redirect/settings.
Die zweite Verteidigung ist der Canonical-URL-Meta-Tag aus dem Metatag-Modul. Selbst wenn ein Node irgendwie unter seinem internen Pfad erreicht wird, verweist der Canonical-Tag im HTML-<head> auf den Alias. Google respektiert Canonical-Tags und konsolidiert Ranking-Signale auf die kanonische URL.
Die dritte Verteidigung ist die robots.txt. Füg Disallow: /node/ in deine robots.txt ein, um Google das Crawlen interner Node-Pfade komplett zu untersagen. Das ist ein „Gürtel und Hosenträger“-Ansatz, der zusammen mit Redirects und Canonical-Tags sicherstellt, dass Node-Pfade nie indexiert werden.
Drupal erzeugt auch potenzielle Duplikate durch Taxonomy-Term-Pages. Hast du ein Vokabular „Kategorien“ mit einem Term „Technologie“, erzeugt Drupal eine Seite unter /taxonomy/term/5 (und, mit Pathauto, einen Alias wie /categories/technology), die alle mit dem Term getaggten Nodes listet. Hat die Taxonomy-Term-Page keinen einzigartigen Intro-Content — nur eine Liste von Node-Teasern, die anderswo erscheinen — kann Google sie als dünn oder doppelt einstufen.
Views-generierte Seiten bringen eine weitere Komplexitätsschicht. Drupals Views-Modul kann Seiten erzeugen, die Content nach verschiedenen Kriterien listen — mit Pagination. Ein View, der alle Blogposts mit 10 pro Seite listet, erzeugt URLs wie /blog?page=1, /blog?page=2 usw. Jede paginierte Seite hat ähnlichen Content (nur andere Posts). Ohne rel="next"- und rel="prev"-Pagination-Tags (von Google deprecated, manche SEO-Praktiker nutzen sie weiter) oder eine noindex-Direktive auf paginierten Seiten kann Google Crawl-Budget auf tiefen Pagination-Seiten mit abnehmendem Content-Wert verschwenden.
Drupal-Caching und sein Einfluss auf Meta-Tags
Drupal hat eines der ausgefeiltesten Caching-Systeme aller CMS, und während das generell ein Performance-Plus ist, kann es bei falschem Verständnis SEO-Probleme verursachen.
Drupals Page-Cache (Internal Page Cache-Modul für anonyme User, Dynamic Page Cache für authentifizierte User) speichert voll gerenderte HTML-Seiten. Wenn du Meta-Tags eines Nodes via Metatag-Modul aktualisierst, kann das gecachte HTML weiter die alten Meta-Tags ausliefern, bis der Cache geleert wird. Bei Sites mit aggressivem Caching (TTL von Stunden oder Tagen) bedeutet das, dass SEO-Änderungen für Google länger unsichtbar bleiben.
Die Lösung ist, Drupals Cache-Tag-System zu verstehen. Wenn du einen Node bearbeitest, sollte Drupals Cache-Tag-System automatisch jede gecachte Seite invalidieren, die den Content dieses Nodes enthält. Das funktioniert korrekt, wenn Meta-Tag-Änderungen Teil des Node-Edits sind (mit Metatag-Modul-Per-Node-Override). Änderungen an globalen oder Inhaltstyp-Level-Meta-Tag-Defaults triggern aber ggf. keine Cache-Invalidierung für alle betroffenen Seiten. Nach Änderungen an globalen Metatag-Einstellungen leer den Page-Cache der Site manuell unter /admin/config/development/performance > Clear all caches.
Externe Caching-Layer fügen eine weitere Dimension hinzu. Wenn deine Drupal-Site hinter Varnish, einem Reverse-Proxy-Cache oder einem CDN wie Cloudflare läuft, gibt es einen zusätzlichen Cache, der Drupals Cache-Tags nicht kennt. Nach dem Leeren von Drupals internem Cache musst du auch den externen Cache leeren. Für Varnish nutz das Varnish-Purge-Modul, um Drupals Cache-Tag-System mit Varnishs Purge-Mechanismus zu integrieren. Für Cloudflare nutz das Cloudflare-Modul, um den CDN-Cache automatisch bei Drupal-Content-Änderungen zu purgen.
Das Purge-Modul und seine zugehörigen Module (Purge Queuer, Purge Processor und plattformspezifische Plugins) bieten eine einheitliche Schnittstelle zur Cache-Invalidierung über alle Layer hinweg. Für SEO ist die Kernanforderung: Wenn sich ein Meta-Tag auf einer Seite ändert, muss jede gecachte Version (Drupal-internal, Varnish, CDN) invalidiert werden, damit Googles nächster Crawl die aktualisierten Tags sieht.
Besondere Vorsicht bei authentifiziertem vs. anonymem Caching. Drupal kann authentifizierten Usern (Editoren, Admins) anderen Content als anonymen Usern (inklusive Googlebot) ausliefern. Wenn deine Metatag-Konfiguration Bedingungen basierend auf User-Rollen enthält, stell sicher, dass die anonyme Version die korrekten Meta-Tags hat. Test, indem du dich ausloggst (oder ein Inkognito-Fenster nutzt) und den Quelltext anschaust, um zu verifizieren, welche Meta-Tags Google sehen wird.
Schritt-für-Schritt-Anleitung
Den Kern-SEO-Modul-Stack installieren
Nutz Composer, um die essenziellen SEO-Module zu installieren: composer require drupal/simple_sitemap drupal/pathauto drupal/metatag drupal/redirect drupal/token. Aktivier sie dann im Drupal-Admin unter /admin/modules oder via Drush: drush en simple_sitemap pathauto metatag metatag_open_graph redirect. Diese Module bilden die Grundlage für Sitemap-Generierung, URL-Aliase, Meta-Tag-Verwaltung und Redirect-Handling. Verifizier, dass jedes Modul aktiviert ist und keine Dependency-Fehler hat unter /admin/reports/status.
Pathauto-URL-Alias-Muster konfigurieren
Geh zu /admin/config/search/path/patterns und erstell ein URL-Muster für jeden Inhaltstyp. Für Articles nutz ein Muster wie /blog/[node:title]. Für Pages nutz /[node:title]. Für Produkte (falls relevant) nutz /products/[node:title] oder /products/[node:field_category:entity:name]/[node:title] für kategoriebasierte Hierarchie. Nach dem Erstellen der Muster geh zu /admin/config/search/path/update_bulk und bulk-generier Aliase für allen vorhandenen Content. Installier und aktivier dann das Redirect-Modul, um automatische 301-Weiterleitungen von internen Node-Pfaden (/node/123) zu den neuen Aliasen anzulegen.
Metatag-Modul für alle Inhaltstypen konfigurieren
Navigier zu /admin/config/search/metatag und konfigurier Meta-Tag-Defaults. Setz das globale Titel-Muster auf [current-page:title] | [site:name] und die Canonical-URL auf [current-page:url]. Leg dann Inhaltstyp-spezifische Overrides an: Für jeden Inhaltstyp klick „Add“ und konfigurier Titel, Description, Canonical-URL und Robots-Direktiven. Setz die Description auf [node:field_meta_description], wenn du ein dediziertes Feld hast, oder [node:summary] als Fallback. Für Inhaltstypen, die nicht indexiert werden sollen (Webforms, interne Seiten), setz Robots-Meta auf noindex, follow.
XML-Sitemap konfigurieren und generieren
Geh zu /admin/config/search/simplesitemap und konfigurier, welche Entity-Types aufgenommen werden. Aktivier veröffentlichte Nodes für alle öffentlichen Inhaltstypen, aktivier Taxonomy-Terms für Vokabulare mit substanziellem Content und schließ User-Profile, Webform-Submissions und andere nicht-öffentliche Entities aus. Setz Sitemap-Prioritäten (Homepage 1.0, Hauptcontent 0.8, Sekundärcontent 0.5). Klick „Generate“, um die Sitemap sofort zu erzeugen, und ruf dann /sitemap.xml auf, um zu verifizieren, dass die erwarteten URLs enthalten sind. Konfigurier das Cron-Intervall für die automatische Regeneration.
robots.txt konfigurieren, um interne Pfade zu blockieren
Bearbeite die robots.txt-Datei deiner Drupal-Site (im docroot) und ergänze Regeln, um interne Pfade zu blockieren, die nicht gecrawlt werden sollen. Füg Disallow: /node/ (blockiert interne Node-Pfade), Disallow: /admin/ (blockiert Admin-Seiten), Disallow: /user/ (blockiert User-Profile und Login-Seiten) und Disallow: /search/ (blockiert Drupals interne Suchergebnisse) hinzu. Ergänze Sitemap: https://deinedomain.de/sitemap.xml am Ende. Nutzt du das RobotsTxt-Modul, verwalte diese Regeln unter /admin/config/search/robotstxt statt die Datei direkt zu bearbeiten.
Sitemap einreichen und in der Google Search Console verifizieren
Füg deine Drupal-Site zur Google Search Console hinzu. Für die Verifizierung nutz das Metatag: Verification-Submodul, um den Google-Verifizierungs-Meta-Tag unter /admin/config/search/metatag > Global > Verification zu ergänzen. Nach der Verifizierung geh zu Sitemaps in der Google Search Console und reich deine Sitemap-URL ein. Überwache den Sitemap-Bericht auf Fehler. Typische Fehler: URLs mit 403 (Permission-Probleme), URLs mit 301 (Aliase, die von Node-Pfaden umleiten), URLs mit Soft-404 (Nodes mit leerem Content). Behebe jede Fehlerkategorie, bevor du erneut einreichst.
Prioritäts-Seiten via IndexBolt für schnellere Indexierung einreichen
Nach der Modul-Installation und -Konfiguration haben Drupal-Sites oft einen Rückstau an Seiten, die indexiert werden müssen — besonders nach einer Migration oder größeren Restrukturierung. Exportier deine Sitemap-URLs und identifizier noch nicht indexierte Seiten via Google-Search-Console-Seiten-Bericht. Reich die wichtigsten Seiten über IndexBolt ein — fokussier auf Haupt-Landingpages, wertvolle Content-Nodes und Seiten mit eingehenden Backlinks, deren Suchsichtbarkeit erhalten bleiben muss. Drupals sauberes, serverseitig gerendertes HTML macht es zu einem hervorragenden Kandidaten für IndexBolts Indexierungs-Pipeline.
Häufige Probleme und wie du sie behebst
Node-Pfade (/node/123) und URL-Aliase erzeugen Duplicate Content
Ursache: Drupal-Content ist sowohl unter dem internen Node-Pfad (/node/123) als auch unter dem URL-Alias (/blog/my-article) erreichbar. Ohne die Canonical-URL-Erzwingung des Redirect-Moduls kann Google beide URLs entdecken und indexieren — Duplicate-Content, der Ranking-Signale auf zwei URLs für dieselbe Seite splittet.
Lösung: Installier und aktivier das Redirect-Modul, geh zu /admin/config/search/redirect/settings und aktivier „Enforce clean and canonical URLs“. Das erzeugt automatische 301-Weiterleitungen von /node/123 zum URL-Alias. Konfigurier außerdem das Metatag-Modul so, dass Canonical-URLs auf den Alias zeigen. Als Gürtel-und-Hosenträger-Schutz füg Disallow: /node/ in deine robots.txt ein, um Google das Crawlen interner Pfade komplett zu untersagen.
Views-Pagination erzeugt Hunderte dünner Seiten
Ursache: Drupals Views-Modul erzeugt paginierte Listen, die URLs wie /blog?page=1, /blog?page=2 bis /blog?page=50 erzeugen. Jede paginierte Seite enthält einen kleinen Content-Ausschnitt (typischerweise 10-25 Items pro Seite), und aus Googles Sicht sehen die Seiten ähnlich aus. Tiefe Pagination-Seiten (Seite 10 und tiefer) haben kaum Discovery-Wert und verschwenden Crawl-Budget.
Lösung: Für Views mit tiefer Pagination ergänze eine noindex-Direktive auf paginierten Seiten ab Seite 2. Das geht via Metatag-Modul-Tokensystem oder mit Custom-Code, der den Page-Parameter erkennt. Alternativ nutz das „Load more“-Pattern (Infinite-Scroll oder „Load more“-Button) statt traditioneller Pagination — dabei bleibt aller Content auf einer URL. Reduzier die Gesamtzahl paginierter Seiten durch Erhöhung der Items-per-Page in deinen View-Settings.
Taxonomy-Term-Pages mit dünnem Content werden indexiert
Ursache: Drupals Taxonomie-System erzeugt für jeden Term in jedem Vokabular eine Seite. Terms mit wenigen getaggten Nodes ergeben dünne Archivseiten — eine Seite mit einem oder zwei Content-Teasern ohne einzigartigen Text. Google kann diese dünnen Seiten zwar indexieren, sie aber schlecht ranken und damit die Quality-Signale deiner Site verwässern.
Lösung: Ergänze Description-Content zu Taxonomy-Terms, die als Kategorieseiten dienen. Schreib im Taxonomy-Term-Edit-Formular 100-300 Wörter einzigartigen Content zum Thema. Konfigurier dein Taxonomy-Term-Template so, dass diese Description prominent erscheint. Für Vokabulare, bei denen Term-Pages gar nicht indexiert werden sollen (z. B. interne Tagging-Vokabulare), setz die Metatag-Defaults für die Terms dieses Vokabulars auf noindex. Entferne dünne Taxonomy-Term-Pages aus deiner Sitemap, indem du das Vokabular in der Simple-XML-Sitemap-Konfiguration ausschließt.
Drupal-Permissions blockieren anonymen Zugriff auf veröffentlichten Content
Ursache: Drupals granulares Permission-System kann anonyme User (inklusive Googlebot) unbeabsichtigt am Zugriff auf veröffentlichten Content hindern. Das passiert, wenn die Permission „View published content“ für die anonyme Rolle entfernt wurde, Content-Access-Module (Content Access, Node Access) das Viewing nach Rolle einschränken oder Field-Level-Permissions Content für anonyme User verbergen.
Lösung: Geh zu /admin/people/permissions und verifizier, dass die anonyme User-Rolle die Permission „View published content“ für alle indexierbaren Inhaltstypen hat. Nutzt du Content-Access-Module, audit ihre Konfiguration, damit veröffentlichte Nodes für anonyme User zugänglich sind. Test, indem du dich komplett ausloggst und deine Content-Seiten besuchst — siehst du eine „Access denied“-Seite, sind die Permissions falsch. Verifizier auch, dass das Simple-XML-Sitemap-Modul während Cron auf den Content zugreifen kann (es läuft standardmäßig als anonymer User).
Caching liefert nach SEO-Änderungen veraltete Meta-Tags
Ursache: Drupals aggressives Page-Caching (Internal Page Cache, Dynamic Page Cache, externes Varnish oder CDN) speichert voll gerendertes HTML inklusive Meta-Tags. Aktualisierst du Meta-Tags via Metatag-Modul — besonders globale oder Inhaltstyp-Level-Defaults — kann das gecachte HTML je nach Cache-TTL stunden- oder tagelang die alten Meta-Tags ausliefern.
Lösung: Nach Meta-Tag-Änderungen auf globaler oder Inhaltstyp-Ebene leer alle Caches unter /admin/config/development/performance > Clear all caches. Nutzt du Varnish, purge den Varnish-Cache zusätzlich (ban req.http.host == "deinedomain.de" in Varnish CLI). Nutzt du Cloudflare oder ein anderes CDN, purge den CDN-Cache via Dashboard oder API. Verifizier die aktualisierten Meta-Tags durch Aufruf einer Seite im Inkognito-Fenster und Blick in den Quelltext. Für laufende Zuverlässigkeit installier das Purge-Modul, um Cache-Invalidierung über alle Layer hinweg zu automatisieren.
Modul-Konflikte erzeugen doppelte oder fehlende Meta-Tags
Ursache: Mehrere Drupal-Module können dieselben Meta-Tags erzeugen. Beispiel: Ein Theme gibt einen eigenen Title-Tag aus, das Metatag-Modul erzeugt einen weiteren, und ein Custom-Modul ergänzt einen dritten. Ähnlich können das SEO-Checklist-Modul, Google-Analytics-Modul oder andere Contrib-Module eigene Meta-Tags einschleusen, die mit dem Metatag-Modul-Output konfligieren.
Lösung: Schau in den Quelltext mehrerer Content-Seiten und such nach doppelten Meta-Tags — mehrere `<title>`-Tags, mehrere `<meta name="description">`-Tags oder mehrere `<link rel="canonical">`-Tags. Gibt es Duplikate, identifizier, welches Modul jedes erzeugt. Deaktivier die Duplikat-Quelle — typischerweise durch Entfernen des Meta-Tag-Outputs aus dem Theme-Template (prüf html.html.twig und page.html.twig) und ausschließliches Vertrauen auf das Metatag-Modul. Das Metatag-Modul sollte die einzige Source of Truth für alle SEO-relevanten Meta-Tags sein.
Profi-Tipps
Drupal-Sites sind oft groß, komplex und geschäftskritisch. Egal ob du Tausende Nodes hast, die darauf warten, von Google entdeckt zu werden, oder ob du gerade eine größere Migration mit neuen URL-Strukturen abgeschlossen hast — IndexBolt schiebt deine wichtigsten Seiten direkt in Googles Indexierungs-Pipeline. Hör auf, auf Cron-getriggerte Sitemaps und natürliche Crawl-Zyklen zu warten — reich deine Drupal-URLs über IndexBolt ein und lass sie in Stunden indexieren.
100 Gratis-Credits. Keine Kreditkarte nötig. Ergebnisse in unter 24 Stunden.
Häufig gestellte Fragen
Hat Drupal eingebaute SEO-Features?+
Drupal-Core liefert die Basis-Bausteine — sauberen HTML-Output, einen konfigurierbaren `<title>`-Tag, URL-Aliasing (seit Drupal 8 hat Core eine Basis-Alias-Verwaltung) und die Möglichkeit, statische Dateien wie robots.txt auszuliefern. Drupal enthält aber out of the box weder eine XML-Sitemap, Meta-Description-Verwaltung, automatische Canonical-URLs, strukturierte Daten noch Redirect-Verwaltung. Diese Features kommen aus Contributed Modules (Simple XML Sitemap, Metatag, Redirect, Pathauto), die separat installiert und konfiguriert werden müssen.
Welche Drupal-Module brauche ich für SEO?+
Der essenzielle Drupal-SEO-Modul-Stack: Simple XML Sitemap für die Sitemap-Generierung, Pathauto für automatische URL-Aliase, Token (von Pathauto benötigt), Metatag für Meta-Tag-Verwaltung, Redirect für 301-Redirect-Handling und optional das RobotsTxt-Modul, um robots.txt über den Admin zu verwalten. Für mehrsprachige Sites ergänze das Metatag: hreflang-Submodul. Installier alle Module via Composer und aktivier sie über /admin/modules oder Drush.
Wie verhindere ich, dass /node/123-Pfade indexiert werden?+
Nutz einen Drei-Schicht-Ansatz: (1) Installier das Redirect-Modul und aktivier „Enforce clean and canonical URLs“, um /node/123 automatisch per 301 auf den URL-Alias umzuleiten. (2) Konfigurier das Metatag-Modul, um Canonical-URLs auf den Alias-Pfad zu setzen. (3) Füg Disallow: /node/ in deine robots.txt ein, damit Google interne Node-Pfade nicht crawlt. Zusammen sorgen diese drei Maßnahmen dafür, dass Google nur deine sauberen URL-Aliase sieht und indexiert — niemals die internen Node-Pfade.
Wie handhabe ich URL-Änderungen während einer Drupal-Migration?+
Vor der Migration dokumentier alle URLs deiner aktuellen Site durch Sitemap-Export. Nach der Migration zu Drupal konfigurier Pathauto so, dass Aliase deiner alten URL-Struktur möglichst exakt entsprechen. Für URLs, die sich ändern müssen, erstell 301-Weiterleitungen via Redirect-Modul. Du kannst Redirects per CSV unter /admin/config/search/redirect/import bulk-importieren. Nach dem Einrichten der Redirects reich deine Sitemap in der Google Search Console erneut ein und überwache den Seiten-Bericht auf 404-Fehler, die auf fehlende Redirects hinweisen.
Warum werden meine Drupal-Views-Pages nicht indexiert?+
Views-Pages werden aus mehreren Gründen ggf. nicht indexiert: Die Views-Page-URL ist nicht in deiner Sitemap (ergänze sie manuell in Simple XML Sitemap's Custom Links), der Seiten-Content ist zu ähnlich zu anderen Seiten (paginierte Views mit überlappendem Content), die Seite hat einen falschen Meta-Robots-Tag (prüf die Metatag-Modul-Konfiguration für das Views-Display) oder die Seite verlangt Permissions, die anonyme User nicht haben. Test die Views-Page-URL im URL-Prüftool der Google Search Console, um das konkrete Problem zu diagnostizieren.
Kann ich IndexBolt mit einer Drupal-Site hinter Basic-Auth nutzen?+
IndexBolt braucht Zugriff auf deine öffentlichen URLs — jede Basic-HTTP-Authentication (üblich auf Drupal-Staging-Umgebungen) muss für Produktiv-Seiten, die indexiert werden sollen, entfernt sein. Hat deine Staging-Site Basic-Auth, ist das in Ordnung — Staging soll nicht indexiert werden. Deine Produktiv-Site sollte ohne Auth-Barriere öffentlich erreichbar sein. Drupals Content-Access-Permissions sind unabhängig von HTTP-Authentication — solange anonyme User veröffentlichte Nodes ansehen können, kann IndexBolt diese URLs zur Indexierung einreichen.