Ihre Drupal-Website läuft auf einer aktuellen Version. Sie erhält Sicherheitsupdates. Technisch funktioniert sie. Und trotzdem ist die Content-Bearbeitung mühsam, das Admin wirkt veraltet, und jede kleine Änderung wartet in der Developer-Warteschlange. Irgendwann sagt jemand: „Drupal ist das Problem. Wir wechseln.“
Wenn sich eine Drupal-Website kaputt anfühlt, ist die Plattform selten der eigentliche Übeltäter. Drupal ist ein modernes, leistungsfähiges CMS - aber „das Modul ist installiert“ und „das Modul ist gut konfiguriert“ sind zwei völlig verschiedene Dinge. Die meisten Websites, die kaputt wirken, sind gar nicht kaputt. Sie sind schlecht konfiguriert - und die Lücke zwischen „technisch funktioniert“ und „das Team arbeitet gern damit“ ist genau dort, wo die Frustration entsteht.
Dieser Artikel ist ein Diagnose-Leitfaden zu den 14 häufigsten Implementierungsfehlern, die eine Drupal-Website kaputt wirken lassen - über Redakteur-Erfahrung, Performance und technische Schuld - mit Symptomen, wahrscheinlicher Ursache und Fix für jeden. Fast alle lassen sich für einen Bruchteil der Kosten eines Neuaufbaus beheben.
In diesem Artikel:
- Fehler #1: Paragraphs installiert, aber nie konfiguriert
- Fehler #2: Fehlende oder falsche Berechtigungen
- Fehler #3: Inhaltstypen mit zu vielen (oder zu wenigen) Feldern
- Fehler #4: Ein veraltetes Admin-Theme
- Fehler #5: Keine Content-Vorschau oder kein Feedback
- Fehler #6: Medienverwaltung ignoriert
- Fehler #7: Langsame Performance durch falsch konfiguriertes Caching
- Fehler #8: Zu viele oder ungepflegte Module
- Fehler #9: Eine veraltete Drupal-Version
- Fehler #10: Ein schlecht konfigurierter WYSIWYG-Editor
- Fehler #11: Kein redaktioneller Workflow oder Content Moderation
- Fehler #12: Verwirrende Navigation und Informationsarchitektur
- Fehler #13: Defekte oder fehlende Sitesuche
- Fehler #14: Vernachlässigte SEO- und URL-Hygiene
- Ist Ihre Drupal-Website wirklich kaputt - oder nur schlecht konfiguriert?
Fehler #1: Paragraphs installiert, aber nie konfiguriert
Das ist der häufigste Fehler überhaupt - und der, der diesen Leitfaden inspiriert hat. Das Drupal-Paragraphs-Modul liegt im Code, vielleicht existieren ein paar Paragraph-Typen, aber Redakteure können trotzdem keine Seiteninhalte aufbauen oder ändern. Auf dem Papier hat die Website ein komponentenbasiertes CMS; in der Praxis sind die Bausteine unerreichbar.
Die Symptome sind eindeutig: Redakteure meiden das CMS, stellen Tickets für winzige Textänderungen oder laden Bilder mit Text hoch, weil das schneller ist als der Kampf mit dem Admin. Zur Diagnose prüfen Sie, ob Paragraph-Typen tatsächlich über ein Paragraphs-Referenzfeld einem Inhaltstyp zugewiesen sind und ob diese Felder im Bearbeitungsformular sichtbar sind.
Der Fix ist saubere Konfiguration, keine neue Software: Paragraph-Typen Inhaltstypen zuweisen, Felder mappen und das Formular-Display so einrichten, dass Redakteure ein klares Menü wiederverwendbarer Komponenten sehen. Die Wirkung ist dramatisch - dieselbe Website geht von „nicht bearbeitbar“ zu „voll flexibel“, ohne Plattformwechsel. Diese Transformation beschreiben wir in unserem Leitfaden von unbrauchbaren Paragraphs zu einem CMS, das Redakteure stärkt - einem Produktions-Rebuild, bei dem die erste Landingpage ~24 % höhere Conversion verzeichnete.
Fehler #2: Fehlende oder falsche Berechtigungen
Redakteure können sich einloggen, stoßen aber ständig an Grenzen - „Zugriff verweigert“ auf Inhalte, fehlende Buttons, Features, von denen man ihnen erzählt hat, die sie aber nicht sehen. Die Website fühlt sich kaputt an, weil für sie die Hälfte fehlt.
Die Ursache sind fast immer Rollenberechtigungen. Redakteuren fehlen häufig Rechte für Paragraph-Typen, die Medienbibliothek oder Taxonomie-Verwaltung, weil Berechtigungen für Entwickler eingerichtet wurden und nie für Content-Rollen angepasst wurden. Drupals Berechtigungsraster ist granular - mächtig, aber leicht falsch gesetzt.
Der Fix ist ein systematisches Berechtigungs-Audit. Legen Sie eine dedizierte Rolle „Content editor“ an und geben Sie ihr genau die Rechte, die sie braucht - relevante Inhalts- und Paragraph-Typen erstellen und bearbeiten, Medienbibliothek nutzen, abhängige Taxonomie verwalten - und nicht mehr. Ergebnis: Redakteure erledigen ihren Job, ohne an unsichtbaren Wänden abzuprallen.
Fehler #3: Inhaltstypen mit zu vielen (oder zu wenigen) Feldern
Ein Content-Formular kann in zwei entgegengesetzte Richtungen scheitern - beide lassen die Website kaputt wirken. Zu viele Felder - 30-plus in einem Formular - und Redakteure wissen nicht, was sie ausfüllen sollen; sie machen Fehler oder geben auf. Zu wenige - alles in ein Body-Feld gepresst - und es gibt keine Struktur, keine Wiederverwendung, keine Flexibilität.
Zur Diagnose öffnen Sie Ihre Inhaltstyp-Formulare und zählen: wie viele Felder gibt es, wie viele werden wirklich genutzt? Überladene Formulare und einsame Mega-Body-Felder sind beides rote Flaggen.
Der Fix liegt in der Mitte. Selten genutzte Felder konsolidieren oder entfernen, überladene Body-Felder in strukturierte Paragraphs für das Seitenlayout aufteilen. Ein guter Sweet Spot sind 5-8 sinnvolle Top-Level-Felder pro Inhaltstyp, Paragraphs übernehmen den Body. Das Formular wird offensichtlich, der Content strukturiert und wiederverwendbar.
Fehler #4: Ein veraltetes Admin-Theme
Redakteure sagen, das CMS „fühle sich alt an“, und vergleichen es ungünstig mit modernen Tools, die sie sonst nutzen. Das ist ein Wahrnehmungsproblem - aber Wahrnehmung steuert Adoption, und eine Oberfläche wie Legacy-Software überzeugt Menschen, die ganze Plattform sei Legacy.
Die Diagnose dauert Sekunden: prüfen Sie, welches Admin-Theme aktiv ist. Das alte Seven oder Standard-Claro wirkt neben einem modernen Admin-Theme veraltet.
Der Fix ist eine der ROI-stärksten Änderungen an jeder Drupal-Website: Gin installieren. Das dauert Minuten und transformiert die Bearbeitungserfahrung - der Wow-Effekt ist real. Kunden und Redakteure nehmen das CMS sofort als modern und leistungsfähig wahr, oft bevor sich sonst etwas geändert hat. Unterschätzen Sie nicht die psychologische Wirkung von visueller Modernisierung; ein müdes Admin-Theme vergiftet leise, wie Menschen über das gesamte System denken.
Fehler #5: Keine Content-Vorschau oder kein Feedback
Redakteure speichern, sehen die Seite, gehen zurück, tweaken, speichern, sehen wieder - eine Endlosschleife, nur um einen Abschnitt hinzubekommen. Das CMS fühlt sich kaputt an, weil man nicht sieht, was man tut, während man es tut.
Die Ursache ist fehlende Vorschau und Feedback: keine Inline- oder Layout-Vorschau, ein WYSIWYG, der nicht zum Frontend passt. Redakteure arbeiten blind und korrigieren per Trial-and-Error.
Der Fix reicht von schnell bis substanziell. WYSIWYG so konfigurieren, dass er das Frontend spiegelt, Paragraph-Vorschau hinzufügen, Layout Builder in Betracht ziehen, wo es passt. Selbst ohne volle Vorschau reduzieren bessere Feld-Hilfetexte und eine befüllte Beispielseite das Raten stark - und Module wie Geysir bringen schnellere, visuellere Paragraph-Bearbeitung. Ziel: Redakteure sollen das Ergebnis ihrer Aktionen vorhersehen können. Die vollständigen Muster für ein Admin, das am ersten Tag nutzbar ist, finden Sie in unserem Leitfaden zum CMS ohne Schulung in Drupal.
Fehler #6: Medienverwaltung ignoriert
Bilder liegen verstreut, dieselbe Datei wird fünfmal unter fünf Namen hochgeladen, es gibt keine zentrale Bibliothek. Medien finden und wiederverwenden ist mühsam - die Website wirkt im Hintergrund chaotisch und kaputt.
Diagnose: prüfen Sie, ob Media-Modul und Medienbibliothek richtig aktiviert und konfiguriert sind. Viele Websites haben Medienhandling nie über den Minimal-Default hinaus eingerichtet.
Der Fix: Medienbibliothek aktivieren und für zentrale Verwaltung konfigurieren. Die Vorteile summieren sich schnell - Bilder sind contentübergreifend wiederverwendbar, Image Styles halten Größen passend, die Performance verbessert sich, weil Sie nicht mehr überall riesige unoptimierte Originale ausliefern.
Fehler #7: Langsame Performance durch falsch konfiguriertes Caching
Seiten laden langsam - oder, genauso frustrierend, veröffentlichte Änderungen erscheinen nicht, und Redakteure schwören, die Website sei kaputt („Ich habe den Text geändert, aber es steht noch die alte Version da“). Geschwindigkeit und Aktualität sind zwei der häufigsten „es ist kaputt“-Beschwerden - und beide sind fast immer Konfiguration, nicht Drupal selbst.
Typische Ursachen: Caching auf dem Default-Datenbank-Backend, interner Page Cache deaktiviert, falsches Cache-Max-Age, fehlende oder zu breite Cache-Tags und -Contexts, keine CSS/JS-Aggregation, unoptimierte Bilder.
Der Fix ist eine geschichtete Caching-Strategie. Page- und Render-Cache aktivieren, Cache-Backend auf Redis oder Memcached umstellen, sinnvolles Cache-Max-Age setzen, Cache-Tags fixen, damit Content bei Änderungen korrekt invalidiert wird. CSS/JS-Aggregation einschalten, Image Styles hinzufügen, bei stark frequentierten Sites CDN oder Reverse Proxy davor. Eine Website, die wegen Trägheit oder veralteter Inhalte kaputt wirkte, wird schnell und zuverlässig - ohne Plattformwechsel.
Fehler #8: Zu viele oder ungepflegte Module
Eine lange Liste aktivierter Module - mehrere ungepflegt, aufgegeben oder überlappend - zieht die ganze Website runter. Symptome: langsames Admin und Frontend, intermittierende Fehler, halb funktionierende Features, Sicherheitswarnungen.
Zur Diagnose die Modulliste durchgehen. Wie viele Module sind aktiv? Wie viele hatten seit Jahren kein Release? Machen zwei Module dasselbe? Performance-lastige Module wie komplexe Views, Token und Search API können bei unsachgemäßer Nutzung ebenfalls schaden.
Der Fix ist diszipliniertes Ausmisten. Aktive Module auditieren, Ungenutztes deinstallieren, aufgegebene durch gepflegte Alternativen ersetzen, den Satz schlank halten. Weniger Konflikte, schnellere Website, kleinere Angriffsfläche - und Sicherheit zählt hier; folgen Sie beim Aufräumen proaktiven Maßnahmen zur Vermeidung von Drupal-Sicherheitsproblemen.
Fehler #9: Eine veraltete Drupal-Version
Die Website fehlen moderne Fähigkeiten, wirkt fragil und kann aktuelle Module nicht betreiben - weil Core auf einer nicht unterstützten Major-Version läuft, Contributed-Module Jahre alt sind oder Custom Code auf deprecated APIs basiert. Auf einer End-of-Life-Version zu laufen fühlt sich nicht nur kaputt an; es ist ein Sicherheits- und Kompatibilitätsrisiko.
Diagnose: Core-Version und Support-Status prüfen, Aktualität der Module checken.
Der Fix ist ein geplanter Upgrade oder Migration, statt zu warten, bis etwas bricht. Redakteur-Erfahrung ins Projekt einbinden, Rankings schützen durch Erhalt von URLs, Redirects und Metadaten - der Unterschied zwischen glattem Upgrade und schmerzhaftem ist meist Planung, wie unser Leitfaden zu Drupal-Versions-Upgrade vs. Migration erklärt. Richtig gemacht liefert ein Upgrade Sicherheit, Performance und moderne Bearbeitung - und rahmt Drupal als aktuell statt legacy.
Fehler #10: Ein schlecht konfigurierter WYSIWYG-Editor
Redakteure kämpfen mit dem Editor selbst. Formatierung hält nicht, eingefügter Content schleppt Müll-Markup mit, der Toolbar fehlen Buttons, das Veröffentlichte passt nicht zu dem, was beim Bearbeiten sichtbar war. Eine Kleinigkeit, die ständige Reibung erzeugt.
Die Ursache ist meist die Standard-CKEditor-5-Toolbar unangetastet gelassen, Textformate und erlaubte HTML-Tags falsch konfiguriert, kein Editor-Stylesheet passend zum Theme.
Der Fix: Editor um echte Redakteur-Bedürfnisse herum konfigurieren - Toolbar mit genutzten Buttons, erlaubtes HTML am Design System ausrichten, Editor-CSS, damit die Bearbeitungsansicht zur veröffentlichten Seite passt. Ergebnis: vorhersehbare Formatierung, deutlich weniger Alltagsfrust.
Fehler #11: Kein redaktioneller Workflow oder Content Moderation
Jeder kann direkt live veröffentlichen, es gibt keine Entwürfe oder Review-Schritte, niemand sieht, wer was geändert hat. Die Website wirkt chaotisch und fragil, weil ein einziger Fehler sofort öffentlich wird.
Die Ursache: Content Moderation und Workflows nicht aktiviert - nur published und unpublished, einziger Schutz ist Hoffnung, dass niemand den falschen Button klickt.
Der Fix: Content Moderation mit einfachem Entwurf → Review → Veröffentlicht - nur so viel Prozess, wie das Team wirklich braucht - und Revisionen für Historie nutzen. Sichereres Publishing, klarere Verantwortlichkeit, deutlich weniger „Wer hat die Startseite kaputt gemacht?“-Momente.
Fehler #12: Verwirrende Navigation und Informationsarchitektur
Besucher finden nicht, was sie suchen; Redakteure wissen nicht, wo neuer Content hingehört. Die Website wirkt kaputt, weil sie inkohärent ist, obwohl jede Einzelseite funktioniert.
Die Ursache ist meist organisches Wachstum: Menüs, die über Jahre gewachsen sind, keine bewusste Informationsarchitektur, tiefe Verschachtelung, inkonsistente Labels.
Der Fix: Navigation und IA an echten Nutzeraufgaben ausrichten - Struktur flacher machen, wo möglich, Content logisch gruppieren, Labels standardisieren, damit dasselbe überall gleich heißt. Ergebnis: eine Website, die für Besucher und Betreuer wieder kohärent wirkt.
Fehler #13: Defekte oder fehlende Sitesuche
Ein Besucher sucht, bekommt irrelevante Ergebnisse oder nichts - und schließt, die Website sei kaputt. Für seinen Zweck ist sie es auch. Auf content-lastigen Websites ist eine brauchbare Suche ein großer Teil davon, wie Nutzer das Gesamterlebnis beurteilen.
Typische Ursache: Core-Search ohne Konfiguration, oder Search API und Solr installiert, aber nie richtig indexiert oder getuned.
Der Fix: Search API konfigurieren (mit Solr jenseits kleiner Kataloge), richtigen Content indexieren, Relevanz und Facetten tunen. Eine Suche, die wirklich funktioniert, ist oft die größte wahrgenommene Verbesserung auf großen Websites.
Fehler #14: Vernachlässigte SEO- und URL-Hygiene
Hässliche oder kaputte URLs, 404 nach Content-Änderungen, verlorene Rankings, doppelte oder fehlende Metadaten - alles lässt eine Website kaputt wirken, für Nutzer mit Sackgassen und für Unternehmen, die organischen Traffic beobachten.
Die Ursache fehlende SEO-Hygiene: kein Pathauto für saubere automatische URLs, kein Metatag-Modul, kein Redirect-Modul, kaputte interne Links unbehoben.
Der Fix ist ein kleines Toolkit und etwas Disziplin. Pathauto, Metatag und Redirect installieren; 301-Redirects bei Content-Umzügen; kaputte Links fixen; XML-Sitemap einreichen. Ergebnis: stabile URLs, geschützte Rankings, weniger Sackgassen für Nutzer und Crawler. Eine verwandte SEO-Falle für sich: Text in Bildern eingebacken - unsichtbar für Suchmaschinen und KI-Antwort-Engines. Mehr dazu in unserem Artikel zu Text in Bildern und SEO.
Ist Ihre Drupal-Website wirklich kaputt - oder nur schlecht konfiguriert?
Wenn Ihr Team frustriert ist - Tickets für winzige Änderungen, Bilder statt Text, leise Vorschläge zum Plattformwechsel - beginnen Sie nicht mit der Evaluierung neuer CMS. Beginnen Sie mit der Diagnose Ihrer aktuellen Implementierung. In der großen Mehrheit ist die Plattform in Ordnung und die Konfiguration das Problem; Konfiguration zu fixen kostet einen Bruchteil eines Neuaufbaus. Steht ein Rebuild wirklich zur Debatte, lassen Sie die Entscheidung zuerst durch unseren Rahmen laufen: Nicht neu aufbauen, sondern entwickeln.
Möchten Sie ein Experten-Audit, warum sich Ihre Drupal-Website kaputt anfühlt?
Dieser Leitfaden basiert auf Jahren Produktionsarbeit bei der Modernisierung bestehender Drupal-Plattformen - einschließlich Projekten, in denen eine schlecht konfigurierte Paragraphs-Installation das CMS unbenutzbar wirken ließ, bis saubere Konfiguration daraus ein flexibles, redakteursfreundliches System machte. Das Muster wiederholt sich: Die Plattform war nie das Problem.
Interesse an einem konkreten Plan, das Kaputt-Wirken Ihrer Website zu beheben? Unser Team diagnostiziert und modernisiert Drupal-Implementierungen täglich - von Berechtigungen und Paragraphs über Caching, Suche und redaktionelle Workflows. Besuchen Sie unsere Drupal-Entwicklungsdienstleistungen, um zu sehen, wie wir helfen können.
