{"id":1932,"date":"2026-08-07T10:26:18","date_gmt":"2026-08-07T07:26:18","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=1932"},"modified":"2026-08-04T01:11:08","modified_gmt":"2026-08-04T01:11:08","slug":"cache-control-header-in-wordpress-erklaert","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/de\/cache-control-header-in-wordpress-erklaert\/","title":{"rendered":"Cache-Control-Header in WordPress verst\u00e4ndlich erkl\u00e4rt"},"content":{"rendered":"

Ein CDN speichert eine Kontoantwort wegen einer zu weit gefassten \u00f6ffentlichen Cache-Regel, w\u00e4hrend eine statische Schrift bei jedem Besuch neu validiert wird. Beide Probleme betreffen Cache-Control<\/code> \u2013 aber derselbe Header f\u00fcr alle URLs w\u00fcrde eines davon verschlimmern.<\/p>\n

Cache-Regeln m\u00fcssen zur Antwortklasse passen. Die bekannten Direktiven unterscheiden sich st\u00e4rker, als ihre Namen vermuten lassen.<\/p>\n

\nInhaltsverzeichnis<\/strong><\/p>\n
    \n
  1. Was darunter zu verstehen ist<\/a><\/li>\n
  2. Praxisbeispiel<\/a><\/li>\n
  3. Warum die Unterscheidung wichtig ist<\/a><\/li>\n
  4. Ein einfacher und sicherer Einstieg<\/a><\/li>\n
  5. Technische Pr\u00fcfung<\/a><\/li>\n
  6. Risiken, h\u00e4ufige Fehler, Backup und Rollback<\/a><\/li>\n
  7. So unterst\u00fctzt AIOWS: AIOWS Cache Manager<\/a><\/li>\n
  8. Passende AIOWS-Artikel<\/a><\/li>\n
  9. Fazit und Empfehlung<\/a><\/li>\n
  10. Offizielle Quellen<\/a><\/li>\n<\/ol>\n<\/div>\n

    Was darunter zu verstehen ist<\/h2>\n

    Cache-Control<\/code> legt fest, ob und wie Browser oder gemeinsame Caches eine Antwort speichern und wiederverwenden d\u00fcrfen. max-age<\/code> bestimmt die Frische, s-maxage<\/code> kann gemeinsame Caches ansprechen, und private<\/code> schlie\u00dft diese von der Wiederverwendung aus.<\/p>\n

    no-cache<\/code> erlaubt Speicherung, verlangt aber vor der Wiederverwendung eine Validierung. no-store<\/code> weist Caches an, die Antwort nicht zu speichern. Die Begriffe sind nicht austauschbar.<\/p>\n

    Praxisbeispiel<\/h2>\n

    Ein Download mit versionierter URL darf lange \u00f6ffentlich frisch bleiben. Die Kontoseite enth\u00e4lt dagegen pers\u00f6nliche Daten und ben\u00f6tigt eine private beziehungsweise nicht speicherbare Regel. Ein globales public, max-age=31536000<\/code> w\u00e4re f\u00fcr die Datei sinnvoll, f\u00fcr das Konto jedoch gef\u00e4hrlich.<\/p>\n

    Die Header werden daher pro Antwortklasse gesetzt und an der \u00f6ffentlichen URL kontrolliert.<\/p>\n

    Warum die Unterscheidung wichtig ist<\/h2>\n

    Falsche Header k\u00f6nnen private Inhalte teilen oder Besucher \u00fcber lange Zeit auf veralteten Dateien halten. Zu konservative Regeln verschenken wiederum Leistung bei wirklich unver\u00e4nderlichen Ressourcen.<\/p>\n

    Die richtige Balance entsteht nicht durch ein allgemeines Snippet, sondern durch klare Klassen f\u00fcr HTML, API-Daten, Downloads, versionierte Assets, Fehler und Weiterleitungen.<\/p>\n

    Ein einfacher und sicherer Einstieg<\/h2>\n
      \n
    1. Klassifizieren Sie \u00f6ffentliche und angemeldete Seiten, API-Antworten, Downloads und statische Dateien.<\/li>\n
    2. Erfassen Sie die endg\u00fcltigen Header einschlie\u00dflich Vary<\/code>, Cookies, Age<\/code> und CDN-Status.<\/li>\n
    3. Setzen Sie zun\u00e4chst vorsichtige Regeln f\u00fcr pers\u00f6nliche Inhalte.<\/li>\n
    4. Geben Sie versionierten Dateien l\u00e4ngere Laufzeiten.<\/li>\n
    5. Testen Sie Anmeldung, Abmeldung, Inhalts\u00e4nderung und bedingte Anfragen.<\/li>\n<\/ol>\n

      Technische Pr\u00fcfung<\/h2>\n

      Ermitteln Sie, welche Ebene den Header schreibt oder \u00fcberschreibt. Webserver, WordPress, Proxy und CDN k\u00f6nnen mehrere Felder zusammenf\u00fchren. Pr\u00fcfen Sie auch, ob Vary<\/code> und der Cache-Schl\u00fcssel Sprache, Kodierung, Cookies oder Autorisierung korrekt ber\u00fccksichtigen.<\/p>\n

      Bewahren Sie f\u00fcr jeden Test je eine Rohantwort vom Ursprung und vom \u00f6ffentlichen Edge-Endpunkt auf. Dieser Vergleich zeigt, ob WordPress die falsche Regel erzeugt oder ein Vermittler sie ver\u00e4ndert.<\/p>\n

      Risiken, h\u00e4ufige Fehler, Backup und Rollback<\/h2>\n

      public<\/code> macht pers\u00f6nliche Daten nicht sicher, und private<\/code> entfernt keine bereits falsch gespeicherten Kopien. Nach einer Sicherheitskorrektur m\u00fcssen betroffene gemeinsame Eintr\u00e4ge deshalb gezielt gel\u00f6scht werden.<\/p>\n