Viele WordPress-Seiten bei Raidboxes laufen blitzschnell – bis ein SEO-Tool wie Semrush plötzlich Dutzende „langsame Seiten“ meldet. Meist sind es ausgerechnet die selten besuchten Unterseiten: Ratgeber-Artikel, Glossar-Einträge, alte Blogposts. In diesem Beitrag zeigen wir, warum das passiert, wie du es sauber diagnostizierst und mit welcher einzigen Stellschraube du es behebst – ganz ohne riskantes CSS/JS-Minify.
Das Symptom: Nur die Long-Tail-Seiten sind langsam
Die Startseite und die wichtigsten Leistungsseiten laden in unter zwei Sekunden. Aber genau die Seiten mit wenig Traffic – Wissensartikel, Glossar, Detailseiten – tauchen im Site-Audit mit Ladezeiten von 3 bis 6 Sekunden auf, einzelne Ausreißer sogar mit 20+ Sekunden. Typisch ist auch, dass die Zahl der „langsamen“ Seiten mit der Zeit steigt, je mehr Inhalte hinzukommen.
Die Ursache: Varnish und ein zu kurzes s-maxage
Raidboxes setzt vor den eigentlichen Webserver einen Varnish-Cache. Der speichert fertig gerenderte HTML-Seiten und liefert sie extrem schnell aus. Wie lange Varnish eine Seite vorhält, steuert der Cache-Control-Header – konkret der Wert s-maxage (die TTL für „shared caches“ wie Varnish und CDNs). Ein typischer Header sieht so aus:
Cache-Control: public, max-age=300, s-maxage=3600, stale-while-revalidate=86400Das Entscheidende: s-maxage=3600 bedeutet, dass Varnish die Seite nur eine Stunde vorhält. Häufig besuchte Seiten werden innerhalb dieser Stunde immer wieder neu angefragt und bleiben dadurch dauerhaft „warm“. Eine Glossar- oder Ratgeberseite, die seltener als einmal pro Stunde aufgerufen wird, fällt dagegen aus dem Cache. Kommt dann der Suchmaschinen- oder SEO-Crawler vorbei, trifft er die Seite kalt – Varnish muss sie erst von PHP komplett neu rendern lassen. Bei einem schweren Page-Builder wie Divi dauert dieser Kaltstart schnell mehrere Sekunden.
Je mehr Long-Tail-Inhalte eine Seite bekommt, desto mehr solcher selten besuchten Seiten gibt es – und desto mehr „langsame Seiten“ meldet das Audit. Der Trend ist also kein Zufall, sondern die direkte Folge des kurzen TTL.
Wichtig bei der Diagnose: nicht als eingeloggter Admin messen
Eine klassische Falle: Wer die Header im eigenen Browser prüft, während er im WordPress-Backend eingeloggt ist, sieht etwas völlig anderes – nämlich Cache-Control: no-store, no-cache, private. Das ist kein Fehler, sondern Absicht: Für eingeloggte Nutzer wird bewusst nichts gecacht. Die Realität für Besucher und Crawler siehst du nur in einer anonymen Anfrage (Inkognito-Fenster oder ohne Cookies).
So prüfst du die echten Header
Im Terminal genügt ein Aufruf gegen eine selten besuchte Unterseite:
curl -sI https://deine-domain.de/glossar/beispiel/ | grep -i -E 'cache-control|age|server'Achte auf zwei Werte: Der Age-Header zeigt, wie lange die ausgelieferte Kopie schon im Cache liegt. Age: 0 bei einer Unterseite heißt: Sie war nicht im Cache und wurde gerade frisch gerendert – ein Cache-Miss. Bei der Startseite siehst du dagegen meist ein hohes Age (warm). Genau dieser Unterschied bestätigt das Problem.
Die Lösung: s-maxage erhöhen statt am Theme schrauben
Der wirksamste Hebel ist denkbar einfach – die Cache-TTL für HTML-Seiten verlängern, damit eine einmal gecachte Seite deutlich länger warm bleibt:
// vorher
Cache-Control: public, max-age=300, s-maxage=3600, stale-while-revalidate=86400
// nachher – Varnish hält die Seite einen ganzen Tag
Cache-Control: public, max-age=300, s-maxage=86400, stale-while-revalidate=86400Bei vielen Raidboxes-WordPress-Installationen wird dieser Header von einem kleinen MU-Plugin oder Code-Snippet gesetzt – dort wird der Wert angepasst. max-age (Browser-Cache) kann ruhig kurz bleiben, damit eingeloggte Redakteure schnell aktuelle Stände sehen; entscheidend ist s-maxage für Varnish.
Zusätzlich: den Cache aktiv warmhalten
Damit auch nach einem Cache-Leeren (etwa nach dem Veröffentlichen neuer Inhalte) niemand auf eine kalte Seite trifft, lohnt sich ein Cache-Warmup: Ein Job ruft regelmäßig alle URLs aus der Sitemap auf und füllt damit den Varnish-Cache vor. In Kombination mit einem höheren s-maxage bleiben dann praktisch alle Seiten dauerhaft warm.
Was du nicht tun musst
Aggressives Zusammenfassen und Minifizieren von CSS/JS wird oft als erste Lösung vorgeschlagen, bricht bei Divi und anderen Page-Buildern aber häufig das Layout – und löst das eigentliche Problem (kalte Seiten) gar nicht. Bei einem Cache-Miss ist die Render-Zeit das Thema, nicht die Asset-Größe. Erst die Caching-Ebene sauber einstellen, optimieren später und mit Sorgfalt.
Fazit
„Langsame Unterseiten“ bei Raidboxes sind selten ein echter Defekt – meist ist es einfach ein zu kurzes s-maxage, das selten besuchte Seiten zu früh aus dem Varnish-Cache wirft. Wer anonym misst, den Age-Header liest und die Cache-TTL passend erhöht, bringt die gesamte Long-Tail-Performance mit einer einzigen Zeile in Ordnung. Das Prinzip gilt für nahezu jede Raidboxes-WordPress-Seite.
Du betreibst deine Seite bei Raidboxes und bist unsicher, wo dieser Header gesetzt wird oder wie du ihn sicher änderst? Wir von der OIT GmbH aus Osnabrück richten Caching, Warmup und Performance-Monitoring sauber für dich ein – sprich uns einfach an.
Hast du eine Frage zu diesem Artikel?
Schreib uns – wir antworten in der Regel innerhalb eines Werktages.
