In Briefings hören wir den Satz in Varianten: „Unsere WordPress-Seite ist furchtbar langsam, aber wir können nichts ändern, weil das Marketing Elementor braucht.“ Oder: „Wir haben schon drei Caching-Plugins, und trotzdem dauert der erste Aufbau ewig.“ Beides beschreibt denselben Zustand. WordPress ist ein CMS. Es ist kein Schicksal. Langsamkeit entsteht, wenn die Site mehr Code, mehr Bilder und mehr Drittanbieter ausliefert, als der Inhalt rechtfertigt — oft auf einem Tarif, der für Broschüren gedacht war und nun einen Baukasen-Stack trägt.
Wir bauen und sanieren WordPress für Unternehmen im deutschen Markt: eigenes Theme, wenige Plugins, Hosting-Empfehlung in der EU, Schriften lokal, Bilder in den Griff. Das Leistungsbild steht unter WordPress. Dieser Text erklärt, warum so viele DACH-Sites trotzdem träge wirken, was wir zuerst messen und wann ein Custom Theme ehrlicher ist als der nächste Slider.
Das Standardbild: Elementor plus vierzig Plugins
Eine typische Ist-Aufnahme sieht so aus: Theme von einem Marktplatz, Child Theme mit drei überschriebenen Dateien, Elementor oder ein verwandter Builder, ein Add-on-Pack „weil die Sektion sonst nicht geht“, ein Slider-Plugin obwohl der Builder Slider kann, zwei SEO-Plugins, zwei Caching-Plugins, ein Bildkompressor, ein Security-Plugin, ein Popup, ein Chat, ein Forms-Plugin, ein Translations-Plugin „für später“, ein Backup-Plugin, das nachts die CPU frisst, und ein verwaistes „Coming Soon“, das niemand deaktiviert hat. Im Netzwerk-Tab: Google Fonts, YouTube-Preview, Maps, Tag-Manager, Hotjar „nur testweise“, ein CDN für das Theme, das selbst schon ein CDN für Icons lädt.
Jedes Teil hatte einen Grund. Zusammen sind sie ein Produkt, das auf Mobilfunknetzen in Deutschland sekundenlang nichts zeigt. Core Web Vitals kippen. Die Search Console meckert. Das Marketing kauft ein weiteres Optimierungsplugin. Die Last steigt. In technischer SEO ist das der Punkt, an dem wir nicht „SEO-Texte“ vorschlagen, sondern den Stack kürzen.
Ein Caching-Plugin macht aus einem überladenen Builder keine schnelle Site. Es macht aus einer langsamen Site eine manchmal schnellere Kopie derselben Last — bis jemand einloggt oder ein Cookie-Banner den Cache umgeht.
Was wir zuerst messen — bevor jemand „mal cache leeren“ sagt
Wir messen den ersten HTML-Byte, den Largest Contentful Paint, die Hauptthread-Blockade, die Transfergröße, die Anzahl der Requests, Drittanbieter, Schriftnachlade, Bildgewichte, Time to First Byte vom konkreten Host. Labor (Lighthouse) und Feld (Search Console, echte Geräte), nicht nur ein Screenshot aus einem US-Rechenzentrum. Eine Site, die in einem Leer-Cache-Test auf Glasfaser „geht“, kann auf einem Mittelklasse-Handy im ICE immer noch unbenutzbar sein. Genau dort entscheiden Einkäufer, ob sie das Formular noch ausfüllen.
Wir schauen ins Backend: Autoload der Optionen, transiente Daten, Revisions, ungenutzte Builder-CSS, die Größe der wp_postmeta, Cron-Jobs, Object-Cache ja/nein. Eine aufgeblähte Datenbank macht Admin und Frontend langsam, auch wenn das Theme „leicht“ wirkt. In Briefings hören wir: „Im Editor ist alles ruckelig, aber die Startseite ist doch gecacht.“ Dann ist das Problem doppelt: Redaktion leidet, und der Cache kaschiert, was Besucher ohne Cache (erster Hit, personalisierte Banner, Warenkorb) trotzdem spüren.
Hosting: der Untergrund, nicht die Ausrede
Shared Hosting für 3 € im Monat kann eine hart codierte HTML-Seite tragen. Es trägt selten PHP, MySQL, ein Page Builder, ein Antivirus-Scan und tägliche Backups gleichzeitig, ohne in die Knie zu gehen. PHP-Version veraltet, kein OPcache, langsames NFS, überbuchte CPU, Mail und Web auf derselben Mini-Instanz: das sind Alltagsbefunde. Wir empfehlen EU-Standorte, aktuelle PHP-Versionen, HTTP/2 oder HTTP/3, vernünftige PHP-Memory-Limits, tägliche Backups unabhängig vomselben Plattenplatz, und Staging. Das steht in keinem Theme-Verkaufstext und entscheidet über TTFB.
Ein CDN kann statische Dateien näher an Besuchende in Deutschland bringen. Es heilt kein 800-ms-PHP. Es ersetzt keinen Auftragsverarbeitungsvertrag. Es darf nicht nebenbei US-Logs vollschreiben, ohne dass die Datenschutzerklärung das sagt. Hosting und Datenschutz gehören zusammen; „schnell“ ohne Standort-Klarheit ist für DACH-Auftraggeber unvollständig.
Was „Managed WordPress“ oft bedeutet
Manche Hoster werben mit Managed WordPress: Updates, Caching auf Server-Ebene, Malware-Scan. Das kann helfen. Es kann auch mit einem Caching-Plugin kollidieren, das dieselben Header überschreibt. Wir klären, wer den Object-Cache legt, wer Full-Page-Cache legt, und ob eingeloggte Redakteure den Cache umgehen. Zwei Caches, die sich nicht kennen, erzeugen die berühmten „manchmal alte Seite, manchmal neue“-Tickets.
Bilder: der häufigste, billigste Gewinn
Hero-JPEGs mit 4000 Pixeln Breite, direkt aus der Kamera, als Hintergrund einer Startsektion: das ist kein Designanspruch, das ist Nachlässigkeit. Wir setzen maximale Darstellungsgrößen, Kompression, moderne Formate wo sinnvoll, width/height gegen Layoutsprung, lazy-load unterhalb der Falte, das LCP-Bild bewusst ohne Lazy, damit der Browser es priorisiert. Medienbibliotheken voller ungenutzter Originaldateien räumen wir, weil Backups und Migrationen sonst Stunden brauchen.
Slider mit sechs Vollbildern sind Conversion-Theater aus 2014. Ein ruhiges Bild, ein klarer Satz, ein Button: das lädt schneller und erklärt mehr. In Briefings hören wir, der Slider sei „Markenstandard“. Dann komprimieren wir die Marke, oder wir ersetzen Bewegung durch ein Standmotiv, das die Marke tatsächlich zeigt.
Schriften, Icons, Drittanbieter
Google Fonts vom CDN: langsam durch Extra-DNS und datenschutzrechtlich in Deutschland ein Dauerbrenner. Lösung: lokal hosten, wenige Schnitte, font-display. Icon-Fonts, die 4000 Glyphen laden, obwohl zwölf Icons gebraucht werden: SVG-Sprites oder ein knappes Subset. YouTube-iFrames, die vor dem Klick Cookies und Player-JS ziehen: Preview und Zwei-Klick. Chat-Widgets, die den Hauptthread blockieren: weglassen oder nach Interaktion laden. Jeder Drittanbieter ist eine Wette gegen INP.
Page Builder gegen Custom Theme
Builder versprechen, dass „die Marketing-Abteilung alles selbst bauen kann“. In der Praxis bauen drei Personen drei unvereinbare Sektionen, jede mit eigenem Abstandssystem, jede mit eigenem CSS-Container. Das DOM wird tief, das CSS global, der Editor langsam. Ein Custom Theme mit festen Blöcken (Gutenberg oder ein knappes Set eigener Blöcke) begrenzt Freiheit und gewinnt Konsistenz, Tempo und Wartbarkeit. Redakteure ändern Texte, Bilder, Listen — nicht die Physik der Seite.
Wir sind nicht religiös gegen Builder. Ein begrenzter Einsatz auf einer Landingpage, die in sechs Wochen stirbt, kann sinnvoll sein. Ein Builder als Betriebssystem der ganzen Corporate Site, fünf Jahre lang, mit Add-ons, ist die häufigste Ursache für Relaunch-Not. Wenn Sie uns fragen, „Custom oder Elementor?“, antworten wir mit der Frage: Wer pflegt in zwei Jahren, und wie oft ändert sich das Layout wirklich? Wenn die Antwort „Texte und News“ ist, braucht niemand einen vollen Builder.
Gutenberg, FSE, klassische Themes
Der Block-Editor reicht für viele Unternehmenssites, wenn das Theme die Blöcke gestaltet statt sie zu bekämpfen. Full Site Editing kann schlank sein — oder ein neues Baukastenproblem, wenn jedes Template im Editor zusammengeschoben wird. Klassische Themes mit wenigen Templates sind für uns oft die ruhigste Lösung: PHP-Templates, klare Hierarchie, kein Visual-Canvas, der bei jedem Speichern 200 KB CSS nachlegt. Die Entscheidung steht im Angebot, nicht als Dogma auf der Website.
Plugins: jedes braucht eine Begründung
Wir führen eine Liste: Name, Zweck, Alternative, Risiko, letzte Aktualisierung, ob es PHP 8 verträgt, ob es eigene Skripte im Frontend lädt. Was keinen Zweck hat, fliegt. Zwei Plugins für dasselbe (SEO, Cache, Formulare) fliegen bis auf eines. Security-Plugins, die jedes Request durch PHP jagen und dabei selbst angreifbar sind, ersetzen wir durch Server-Regeln, restriktive Rechte und Updates. Backup muss laufen — aber nicht, indem es mittags die Production-CPU frisst.
Eigene, kleine Plugins für ein spezielles Formular oder eine Schnittstelle sind oft leichter als ein Marktplatz-Universalschiff. Wie wir das anlegen, beschreiben wir unter WordPress: eigene Plugins. Der Punkt ist nicht, alles selbst zu schreiben. Der Punkt ist, Abhängigkeit und Frontend-Gewicht zu kennen.
- SEO: ein Plugin oder — auf einfachen Sites — hartes Markup im Theme.
- Formulare: eines, ohne Marketing-Automation-Zwang in die USA.
- Cache: eines, oder server-seitig, nicht drei.
- Bilder: Theme plus Build-Schritt, nicht fünf Kompressoren.
- Übersetzungen: nur wenn Sie wirklich übersetzen, nicht „falls irgendwann EN“.
- Slider, Popup, Counter, „Before/After“: oft CSS und ein Bild, nicht ein Plugin.
WooCommerce und der Shop-Sonderfall
Ein Shop ist langsamer als eine Broschüre, das ist ehrlich. Produktvarianten, Warenkorb, Sessions, Zahlungs-Skripte. Trotzdem muss nicht jedes Produkt 15 verwandte-Plugin-Sektionen laden. Transients, Slow Queries, fehlende Indizes, ungebremste Widgets auf jeder Archivseite: das sind Werkstatt-Themen. Wir schalten Skripte auf Seiten ab, die sie nicht brauchen. Wir laden Zahlungs-JS nicht auf der Startseite. Wir raten von „alles in einem Builder-Produkt-Template“ ab, wenn der Katalog wächst.
Wie wir aufräumen — die Reihenfolge
- Inventar: Theme, Builder, Plugins, Drittanbieter, Host, PHP, DB-Größe.
- Messung vor dem Eingriff, damit hinterher nicht nur das Gefühl spricht.
- Hosting und PHP auf einen tragfähigen Stand, EU, Backups.
- Drittanbieter und Schriften: lokal, Zwei-Klick, Streichen.
- Bilder und Medienbibliothek.
- Plugin-Reduktion, doppelte Caches entflechten.
- Builder-CSS und ungenutzte Widgets; wo nötig: Templates in ein Custom Theme überführen.
- Datenbank: Revisionen, Autoload, Spam-Kommentare, transiente Leichen.
- Cache sinnvoll, nicht als erstes und nicht als einziges.
- Messung danach, Search Console, Redaktions-Schulung: was man nicht mehr tun sollte.
Schritt 7 ist der teure. Manchmal reicht Aufräumen. Manchmal ist das Theme so verwachsen, dass ein neues Custom Theme mit Inhaltsübernahme günstiger ist als weitere sechs Monate Plugin-Archäologie. Das sagen wir, bevor jemand „nur mal schnell optimieren“ beauftragt und dann wundert, warum Sektionen zerfallen, wenn Elementor fliegt.
Was der Umstieg auf ein Custom Theme konkret bedeutet
Wir zeichnen Templates (Start, Leistung, Beitrag, Archiv, Kontakt, rechtliche Seiten), bauen Blöcke oder Felder für die Inhalte, die wirklich wechseln, migrieren Texte, setzen Weiterleitungen, prüfen Formulare, bauen Cache und Backup neu auf. Redakteure bekommen eine kurze deutsche Anleitung, keine Entwickler-Schulung. Was im Builder „eine neue Sektion in fünf Minuten“ war, ist danach oft „eine Inhaltsänderung in einem vorgesehenen Block“. Das ist der Deal: weniger Freiheit im Layout, mehr Tempo und weniger Bruch bei Updates.
Updates sind der unterschätzte Teil. Ein Multipurpose-Theme plus Builder plus Add-ons ist eine Matrix aus Kompatibilität. Ein schlankes Theme mit zwei Plugins aktualisiert man, ohne drei Layouts zu reparieren. Sicherheit hängt daran. Langsamkeit auch: veraltetes PHP, weil ein Plugin 7.4 erzwingt, ist keine Petitesse.
Tabelle: Symptom und häufige Ursache
| Symptom | Häufige Ursache | Was wir tun |
|---|---|---|
| TTFB über 800 ms | Schwaches Hosting, PHP, DB, kein OPcache | Host/PHP, Queries, Object-Cache |
| LCP schlecht | Hero-Bild, späte Schrift, Builder-CSS | Bild priorisieren, Schriften lokal, CSS kappen |
| INP / Ruckeln | Chat, Tag-Manager, Builder-JS | Skripte streichen oder verzögern |
| CLS | Bilder ohne Maße, späte Banner, Fonts | Dimensionen, Banner-Platz, font-display |
| Nur eingeloggt langsam | Admin-Assets, Heartbeat, Autoload | Backend aufräumen, nicht nur Frontend-Cache |
| Nach Plugin-Update tot | Builder-Abhängigkeit, PHP-Konflikt | Staging, dann Theme-Pfad ohne den Konflikt |
| Mobil unbrauchbar | Slider, Mega-Menü, zu große Bilder | Mobil first, weniger Bewegung |
| „Manchmal alt“ | Zwei Caches, HTML-Purge unklar | Eine Cache-Schicht, klare TTL |
Was wir in Briefings immer wieder hören
„Wir dürfen Elementor nicht anfassen, die Geschäftsführung hat selbst die Startseite gebaut.“ Dann bauen wir ein Theme, das die Inhalte übernimmt, und erklären den Preis des Weiterbauens im Builder. Entscheidung bleibt bei Ihnen. Wir schönen sie nicht.
„Ein Freelancer hat gesagt, WP Rocket reicht.“ Ein gutes Cache-Setup hilft. Es ersetzt kein 3-MB-Hero und kein Font-CDN. Wir setzen Cache am Ende, nicht als Religion am Anfang.
„Könnt ihr alles lassen und nur beschleunigen?“ Manchmal ja. Oft nein. Wer 40 Plugins braucht, weil das Geschäftsmodell 40 Plugins braucht, hat ein anderes Produkt als eine Firmenwebsite. Dann reden wir über Architektur, nicht über Minify.
„Ist WordPress dann die falsche Wahl?“ Für redaktionelle Sites mit klaren Templates ist es eine vernünftige Wahl. Für eine Broschüre, die sich zweimal im Jahr ändert, ist hartes HTML/PHP oft schneller und ruhiger. Die Abwägung gehört ins Erstgespräch, nicht in ein Dogma. Preise und Pakete: Preise.
Redaktion, Schulung, Rückfallvermeidung
Nach der Sanierung installiert jemand wieder ein Popup-Plugin, weil eine Kampagne „das immer so macht“. Deshalb dokumentieren wir: was darf ins Backend, was nicht, wie Bilder hochgeladen werden (Größe, Zuschnitt), wie man nicht fünf H1 in eine Seite stapelt. Eine Stunde Schulung spart Monate Regression. Wir schreiben das in die Übergabe, auf Deutsch, im Sie-Ton, ohne Video-Kurse aus einem anderen Markt.
Wartungsverträge, die nur „Updates klicken“ heißen, ohne Staging und ohne Blick auf neue Skripte, sind Kosmetik. Wenn Sie uns für Pflege buchen, gehört der Netzwerk-Tab in den Turnus. Wenn Sie intern weiterbauen, brauchen Sie jemanden, der „neues Plugin“ als Performance-Frage erkennt.
Sicherheit und Tempo hängen zusammen
Ungepatchte Plugins sind Einfallstore. Gehackte Sites laden Spam-Redirects und Crypto-Miner — beides macht langsam und zerstört SEO. Brute-Force auf wp-login, XML-RPC-Pingbacks, offene User-Enumeration: das sind Last und Risiko. Wir härten Login, begrenzen Versuche, schalten ab, was niemand braucht. Das ist kein Security-Theater mit zehn Ampeln im Dashboard. Es ist weniger Angriffsfläche, und weniger Angriffsfläche ist oft auch weniger PHP pro Request.
CSS, JavaScript und der Mythos vom „Minify-Plugin“
Page Builder schreiben oft für jede Sektion eigenes CSS in die Datenbank und laden zusätzlich ein globales Bundle, das alle Widgets kennt, auch die ungenutzten. Concatenation und Minify kleben das danach zu einer noch schwerer cachebaren Datei, die bei jeder Mini-Änderung invalidiert. Wir gehen den anderen Weg: ungenutztes CSS nicht erzeugen, Skripte nur auf Templates enqueuen, die sie brauchen, jQuery nicht aus Gewohnheit. Ein Slider-Skript auf der Datenschutzseite ist kein Versehen, das ist der Default vieler Themes.
Drittanbieter-Fonts, Icon-Kits und Formular-Builder, die ihr eigenes jQuery mitbringen, verdoppeln Last. Wir prüfen die Enqueue-Liste, nicht nur die Plugin-Liste. In Briefings hören wir: „Wir haben doch Autoptimize.“ Autoptimize kann helfen, wenn die Quelle schlank ist. Es kann auch kaputtes CSS und doppeltes jQuery liefern. Messung vor und nach, Staging, sonst bleibt es Magie.
Datenbank: Autoload, Transients, Revisionen
WordPress lädt Optionen mit autoload=yes auf jedem Request. Page Builder und abgebrochene Plugins hinterlassen dort oft hundert Kilobyte und mehr. Transients, die nie sterben, wachsen. Revisionen jeder Builder-Speicherung blähen wp_posts. Wir messen die Autoload-Größe, kippen Leichen, begrenzen Revisionen, setzen Transients auf TTL. Das beschleunigt Admin und TTFB, ohne dass jemand ein neues Cache-Plugin kauft. Einmal im Quartal reicht auf vielen Firmen-Sites — wenn niemand wöchentlich fünf Plugins testet.
Objekt-Cache (Redis, Memcached) lohnt, wenn Hosting ihn sauber anbietet und Plugins kompatibel sind. Auf billigem Share ohne Isolation kann er schaden. Wir setzen ihn nicht „weil Best Practice auf Twitter“, sondern wenn die Messung es trägt.
Staging, Deploy, keine Live-Experimente
Plugin-Updates zuerst auf Staging, dann Production. Builder-Major-Updates sind Layout-Risiken, keine Klick-Routine. Wir halten eine kurze Rollback-Notiz: PHP-Version, Theme-Stand, Plugin-Stand. Wer live „mal Elementor Pro updaten“ klickt, weil das Dashboard rot blinkt, erklärt hinterher den blanken Screen. Das ist kein Argument gegen Updates. Es ist ein Argument gegen Updates ohne Kopie.
Was nach zwölf Monaten wieder langsam macht
Die Sanierung hält nicht, wenn Kampagnen unkontrolliert Skripte nachlegen. Ein Tag-Manager, der „nur die Herbstaktion“ trägt und im Januar noch drei Pixel ausführt. Ein neues Testimonial-Slider-Plugin, weil die Geschäftsführung ein Karussell gesehen hat. Ein Formular-Tool aus den USA, weil Vertrieb es vom Messe-Stand mitgebracht hat. Wir empfehlen eine Änderungsliste: wer darf Plugins installieren, wer darf den Header anfassen, welche Bildgröße ist Pflicht. Ohne das ist Performance ein Projekt, das jährlich neu bezahlt wird.
WordPress-Core, PHP und das Theme müssen zusammenbleiben. Ein eingefrorenes PHP 7.4, weil ein totes Plugin schreit, ist langsam und unsicher. Der Weg ist: Plugin ersetzen, PHP heben, messen. Nicht: PHP halten und ein weiteres Cache-Layer drüberlegen. In Briefings hören wir stolz „wir updaten nie, dann geht nichts kaputt“. Dann geht irgendwann alles kaputt, nur an einem Wochenende. Ein Child-Theme auf einem toten Multipurpose-Elternteil ist dasselbe Muster: Die Basis rostet, das Kind erbt den Rost. Dann ist Custom Theme nicht Geschmack, sondern Ausstieg.
Medien wachsen still. Redaktion lädt jedes Mal das Kamerarohfile. Die Bibliothek hat 8 GB, Backups dauern, der Host drosselt. Eine Upload-Regel (maximale Kantenlänge, erlaubte Formate) ist unspektakulär und spart mehr als ein neues CDN. Wir setzen sie in der Schulung, nicht als Fußnote. Dasselbe gilt für PDF-Kataloge, die niemand HTML-fähig macht, und für Screenrecordings als Hero: schwer, ohne Untertitel, schlecht fürs LCP. Wer Medienpolitik hat, braucht weniger Notfall-Optimierung.
Wann wir von einem Relaunch abraten
Wenn die Site technisch tragfähig ist, die Inhalte stimmen und nur zwei schwere Bilder und ein Chat das LCP ruinieren, brauchen Sie kein neues Design. Wenn das Theme totgepflegt, der Builder die Daten in Shortcodes begräbt und PHP 8 am Horizont scheitert, ist Festhalten teurer. Wir sagen beides. Ein Relaunch, nur weil jemand „frisch“ will, während 40 Plugins bleiben, wiederholt das Problem in neuer Optik.
Was „schnell genug“ für eine Unternehmenssite heißt
Wir jagen keine Trophäen-100-Punkte, wenn dafür Inhalte leiden. Wir wollen, dass der erste sichtbare Inhalt auf einem gängigen Mobilgerät in Deutschland in einem Rahmen kommt, den Menschen nicht als Hänger empfinden, dass Interaktionen nicht kleben, dass Layout nicht springt. Feldwerte in der Search Console über Wochen, nicht ein Lab-Peak nach dem Leeren des Caches. Anfragen über das Formular sind die Geschäftskennzahl. Millisekunden sind Mittel, nicht Zweck.
Die schnellste WordPress-Site ist die mit dem wenigsten unnötigen Code. Alles andere ist Verwaltung dieses Rests.
Cron, Heartbeat, Admin: warum intern alles klebt
Besucher sehen den Cache. Redakteure sehen PHP. Heartbeat pollt im Editor, Cron arbeitet abgelegte Jobs, ein Backup-Plugin läuft „wenn CPU frei ist“ und ist es nie. Wir drosseln Heartbeat, legen Cron auf echte Systemjobs wo der Host das kann, verschieben Backups in die Nacht. Das beschleunigt nicht den LCP der Startseite. Es beschleunigt die Leute, die die Startseite ändern sollen. Wenn die Assistenz den Editor hasst, entstehen wieder Builder-Sünden — aus Not, nicht aus Geschmack.
In Gampaha sehen wir das in Staging-Sessions am deutschen Vormittag: dieselbe URL, eingeloggt langsam, ausgeloggt „geht“. Dann ist Frontend-Cache die Maske. Masken entfernen wir messend, nicht mit einem weiteren Optimierungsplugin. Pflege unter WordPress meint auch den Admin, nicht nur den First Paint.
Was wir Redaktionen verbieten — freundlich und schriftlich
Keine GIFs als Hero. Keine unkomprimierten Kameradateien. Kein zweites Slider-Plugin, weil die Startseite „lebendiger“ soll. Kein Chat-Widget ohne Absprache, wenn ein Wartungsvertrag läuft. Das steht in der Übergabe. Es ist unhöflich klar. Unhöflich klar hält Tempo. In Gampaha schreiben wir das auf Deutsch, im Sie-Ton, ohne Video-Kurs aus einem anderen Markt.
Wer Kampagnen braucht, bekommt eine Landing-Vorlage im Theme, nicht die Freiheit, Elementor wieder einzuschalten. Freiheit ohne Raster ist, wie die Site in acht Monaten zurückfällt. Wir haben das oft genug zurückgebaut, um es vorher aufzuschreiben. Spannen dafür stehen unter Preise, nicht als „ein Cache-Plugin, dann sind Sie durch“. Die Vorlage hat ein Hero, einen Text, einen Button. Mehr braucht eine Kampagne selten. Mehr ist, wie der Stapel wieder wächst.
Wenn Sie eine träge Installation erben oder seit Jahren am Builder weiterstricken, schicken Sie uns über Kontakt die URL und — wenn möglich — eine Plugin-Liste. Wir sagen nach Sichtung, ob Aufräumen reicht oder ein Custom Theme der kürzere Weg ist. Ohne Ranking-Versprechen, ohne „beste WordPress-Agentur“, mit einer messbaren Vorher-Nachher-Liste. Das ist unbequemer als ein weiteres Optimierungsplugin. Es ist der Weg, der in zwölf Monaten noch trägt. Wer nur einen Cache-Schalter will, braucht uns nicht. Wer den Stapel aus Elementor, Add-ons und Hosting ehrlich kürzen will, schon. Eine Messung vor dem Vertrag schützt beide Seiten: Sie sehen, ob der Aufwand zum Angebot passt, wir sehen, ob 40 Plugins wirklich 40 Gründe haben. Manche haben keinen. Die fliegen zuerst.
Weiter: WordPress-Leistung, technische SEO, eigene Plugins, Preise. Wenn die Liste der Plugins länger ist als die Liste der Seiten, ist das meist schon die Diagnose — und der Grund, warum Caching allein nichts ändert. Wir schreiben das so deutlich, weil genau dieses Muster in deutschen Firmen-Backends der Normalfall ist, nicht die Ausnahme.
