Which WordPress pages/URLs should never be cached?

I have a multisite blog that will soon have an Akamai caching service sitting in front of it, serving cached content to visitors (15 minute TTL).

I want to configure Akamai to exclude any important URLs that should never be cached (i.e., don’t want to serve cached login/admin pages). Is there a compilation, or general recommendation, of all important URLs that should never be cached? Here’s what I’ve got so far:

Read More
  • /wp-* (This would prevent wp-includes/admins/etc)
  • /xmlrpc.php
  • Any URL with with ?preview=true so that editors can preview

Edit: Additional info below

We are using Akamai edge cache, which is full site caching. Basically, Akamai acts as a reverse proxy server. Our DNS is pointing at Akamai, visitors hit Akamai directly. Akamai only hits us to update pages when TTL expires, or when a page is requested that isn’t already cached.

We have the ability to exclude parts of the site from being fully cached, for example URLs matching wp-*, or any urls with the query string preview=true. Exclusions do allow cookies to be passed through; POST requests are also allowed.

With this additional info, the original question still remains — what WP-specific URLs/paths/etc need to be excluded from the full-site caching to prevent things from breaking? E.g., previews obviously need to be dynamic by nature, so I’ve excluded that by allowing preview=true query string. What else do I need to exclude? Is anything matching wp-* good enough, or are other things missing, i.e. /xmlrpc.php?

I hope things brings some additional context to the original question.

Related posts

Leave a Reply

3 comments

  1. You should not cache anything in the admin so your examples are correct.

    A typical nginx reverse proxy cache is set to ignore wp-.*.php|wp-admin

    Another option is to not cache logged in users by checking the wp cookies, but you probably don’t have that level of control.

    ps. It is highly advisable you test this out before flipping the switch.

    tl;dr You should be fine with a vanilla install.

  2. I don’t believe Akamai actually caches the entire page. Any publicly available static resource is fine to cache and would have no bearing on the functionality of the site — even if it were on the login page or in the dashboard.

    So you don’t need to do any blocking.

    The same can’t be said for something like W3 Total Cache, but that’s solved by simply not serving cached files to logged in users or excluding specific theme or plugin files.

  3. You are using akamai as web caching server so maybe it will help if you look for tips on using squid, which is a popular web caching tool, with wordpress.

    The thing with caching is that you don’t want an HTML which was tailored for a specific user to be cached, and the proper way to do it when working with standard conforming web caches is to set the http “Cache-Control” header to something like “no-cache, must-revalidate, max-age=0”, which is exactly what wordpress is sending when a user is logged in, so you might actually be OK without doing any configuration.

    If you have the ability to exclude by cookie then maybe you should add protection and exclude when the log in cookie is set (don’t remember the exact name) and the same for the commenter cookie if you have comments enabled so commenters will be able to see their own comments after submitting them.

    If after that you still feel like excluding specific files then do it only for php files , as you want the js,css and images under /wp-inculde to be CDNed. Maybe just exclude all php files except for /index.php