Wenn du WordPress-Websites mit aktiviertem Caching betreust, kennst du das wahrscheinlich: Du aktualisierst einen Beitrag, ein Template, ein Produkt, ein Formular oder eine wiederverwendete Komponente \u2013 aber eine oder mehrere Frontend-Seiten zeigen weiterhin die alte gecachte Version.<\/p>\n\n
Zum Beispiel:<\/p>\n\n
Die \u00fcbliche Reaktion ist, den Cache manuell zu leeren \u2013 manchmal nur f\u00fcr eine bestimmte Seite, manchmal f\u00fcr die ganze Website, weil das sicherer erscheint, als zuerst alle betroffenen URLs herauszufinden.<\/p>\n\n
Damit ist das unmittelbare Problem zwar gel\u00f6st, aber das Cache-Leeren bleibt Teil deines Publishing-Workflows. Ein vollst\u00e4ndiger Purge verwirft zudem einwandfrei gecachte Seiten und verursacht unn\u00f6tigen Cold-Cache-Traffic sowie zus\u00e4tzliche Serverarbeit. <\/p>\n\n
Cache Autopilot<\/a> nimmt dir diesen manuellen Schritt ab. Es ermittelt, welche Frontend-Seiten von der \u00c4nderung betroffen sind, l\u00e4sst diese URLs \u00fcber dein unterst\u00fctztes Cache-Plugin<\/a> leeren und l\u00e4dt sie anschliessend im Hintergrund wieder vor. <\/p>\n\n Dein Cache-Plugin k\u00fcmmert sich um den Cache. Cache Autopilot erg\u00e4nzt den fehlenden Kontext: welche Seiten tats\u00e4chlich aktualisiert werden m\u00fcssen<\/em>. <\/p>\n\n F\u00fcr kleinere Websites schrieb ich immer wieder einmalige Snippets: Wenn sich Beitragstyp X \u00e4ndert, l\u00f6sche den Cache der Seiten X, Y, Z. Das funktionierte gut genug – bis es nicht mehr funktionierte.<\/p>\n\nDas Projekt, das eine richtige L\u00f6sung erzwang<\/h2>\n\n