Server and Browser Cache

Heavy caching is one of the best ways to speed up your browsing experience, which is why WP Engine provides heavy caching through default and upgraded services. The primary caching layers are server (Varnish) and network (CDN).

When updating content on your site, you might not see your updates and changes reflected immediately when viewing the site. The reason for this is most commonly caching, and caches simply need to be purged. Typically seeing your changes is as easy as purging the right cache.

Not seeing changes after a deployment? Website looks wrong after copying? Made a change to a post or page but not seeing it reflected on the frontend? Purge caches!

Our servers employ extensive caching by default. This is part of what makes WP Engine the fastest WordPress® website host.¹ When using page caching, the typical flow for the first page request looks something like this:

Many of these steps are saved when you introduce a cached version:

Each layer of caching has its own default expiration times as well.

Page Cache: Stores the dynamically generated version of a page.

• 10 minute cache expiration

Network Caches: DNS-level caching, including CDN, powered by Cloudflare. Requires a domain be added to the environment to activate.

Object Cache: Stores results of database queries.

• Object cache an optional feature
• No cache expiration
• 1MB buffer size, data is stored based on what was request most recently

NitroPack: A performance tool that automatically handles cloud-based optimization of the frontend of your website.

• NitroPack is an optional product extension

Browser Cache: Stores assets in a user’s local browser, such as Chrome or Firefox.

• All static assets on the WP Engine platform are cached 365 days by default
• Cache expiration can be adjusted through cache headers

Smarter Cache is a feature you can enable in your WordPress dashboard that will allow your posts and pages to be cached for longer if they haven’t been modified in a while.

If your posts and pages have gone more than 4 weeks without being updated, this option will allow you to cache them for up to 6 months by default. As posts pass 4 weeks without being updated, the cache header will be updated to 6 months.

To enable Smarter Cache:

1. Go to the WP Engine menu at the top of your WordPress sidebar.
2. Select the Caching tab.
3. Scroll down to the Smarter Cache section and check the box for Smarter Cache.
4. Click the Save all changes button at the bottom of the page.

How you manage your caching will vary by the type of site you have and how often you update your site’s content.

• Ensure your domain is on our Advanced Network (AN) or Global Edge Security (GES) network for DNS. If your domain is on our older Legacy DNS Network, we strongly recommend upgrading it to take advantage of edge caching.
• If your domain is on Advanced Network (AN), it’s safe to enable Edge Full Page Cache on the Cache page in the User Portal for an environment.

Tip

Advanced Network is included free of charge in all of our plans. GES can be purchased as an add-on and is included in some plans.

Cache Time-To-Live (TTL) strategy

There are multiple levels and types of caching. By default, WP Engine caches pages for 10 minutes and static assets for up to one year. In practice, CDN cache will refresh pages every 10 minutes and static assets will remain cached for up to 2-3 hours (depending on traffic to your site; since CDNs are regional, this will further vary by region). Page cache will typically keep static assets cached for much longer, up to weeks or even months before those items are refreshed in the cache. Browser caches will fully respect both the 10 minute page TTL and the 365 day static asset TTL so return visitors will see cached content if they return during the TTL.

Depending on how often your content is updated, you will likely want to change these default cache settings, depending on how often your content is likely to change:

• Content never changes: If content on your site is unlikely to change after it’s published, setting your cache TTL to an extended time period (ex. 4 weeks) and enabling Smarter Cache in WP Admin is a good strategy.
• Content changes often: If content on your site is likely to change one or more times per week, using a shorter TTL  (ex. 1 or 3 days) will help maximize caching while helping to avoid stale content.
• Content changes hourly: If content on your site changes daily or even more often, a shorter TTL is recommended.  For most sites, a TTL of 4 hours is probably ideal to maximize CDN caching while minimizing the risk of stale content from the browser cache. If your website has “breaking news” where content can change very often, a TTL of 10 minutes is probably ideal.
• Note: It’s possible to set different TTLs for different pages using Web Rules. For example, the home page could have a TTL of 2 hours while the rest of the site has a 4 week TTL. If you need this level of control, do not use Smarter Cache and set Cache Times in WP Admin to “default” (need link to updated section 3).

WP Engine has a number of eCommerce cache exclusions in place to ensure WooCommerce®  runs as expected, so no additional action is needed.¹ 

• If your site is on WP Engine’s eCommerce bundle, be sure to enable LiveCart and EverCache® for WooCommerce. These tools will help to ensure that your site is taking full advantage of edge caching by caching as many dynamic elements as possible without impacting your cart and purchase flows. Enabling both features is quick and easy–just a simple toggle on the Environment Overview page.
• Note: Cache hit rates for WooCommerce sites are on average 15% lower than typical WordPress websites due to the number of pages that need to be dynamic in order to function properly.

Because large amounts of content are password protected, this hampers caching and tends to result in much lower than average cache hit ratios.

Ensure that any additional cache exclusions you add are absolutely necessary to avoid further reducing the content that can be cached.

Edge Full Page Cache (EFPC) is an optional layer of caching at the network level which will improve your website’s performance. This feature caches the website’s HTML and stores it on Cloudflare’s CDN network, improving the Time to First Byte (TTFB) and latency of most websites.

EFPC can be enabled for any primary domain that is on GES or our Advanced Network for DNS.

If your domain is currently configured using Advanced Network or Global Edge Security (GES), the majority of your website’s static assets are already cached using Cloudflare’s CDN network. However, HTML files by default are served directly from WP Engine’s servers. With Edge Full Page Cache, HTML pages can now be served from Cloudflare’s CDN which places assets geographically closer to your visitors and will improve overall page performance.

For more information about WP Engine’s other types of server caching, see the WP Engine Cache section.

Edge Full Page Cache can be enabled from the Domains page of an environment.

1. From the Sites page, select the environment name
2. Select Domains in the secondary lefthand menu (You may have to expand the Manage dropdown section)
3. Click the three dot menu button to the far right of the domain
4. Select Enable Edge Full Page Cache
   

Edge Full Page Cache can also be enabled from the Cache page in the User Portal for your Primary domain. This can also be enabled for Primary domains from the Domains page menu shown in the example above.

1. From the Sites page, select the environment name
2. Select Cache in the secondary lefthand menu (You may have to expand the Manage dropdown section)
3. Locate the Network Caches section
4. Toggle Edge Full Page Cache
   

Edge Full Page Cache expiration times will use cache-control headers which you can change in the WP Engine mu-plugin and set in the Web Rules Engine. By default cache-control headers should be 10 minutes for posts and pages which you can see from the WP Engine menu in the WordPress dashboard.

To purge Edge Full Page Cache, use the Clear Network Caches option on the Cache page of the User Portal. Learn more here.

Alternatively, both Clear All Caches on the Cache page and in the website’s WordPress admin will purge Edge Full Page Cache.

WordPress has an incredibly large number of plugins and themes available.  While our team has tested Edge Full Page Cache with a variety of plugins and themes, we are unable to test every available WordPress tool for compatibility. Use this feature at your discretion, understanding that outcomes may vary.

Plugins with extensive personalization will generally benefit the least from Edge Full Page Cache since their key dynamic pages cannot have their HTML cached. These types of plugins include Membership/Community plugins and Learning/LMS plugins.

If you encounter a conflict with a plugin or other feature please disable Edge Full Page Cache and report the conflict using the popup shown below which should show immediately after disabling.

If you do not see the feedback form popup then you can also submit feedback through the  Product feedback link at the bottom of the WP Engine User Portal.

• Some pages excluded from WP Engine’s caching will not be excluded from Edge Full Page Cache.
  • WP Engine has default cache exclusions in place for the WordPress admin dashboard, eCommerce dynamic pages, and PHP test drive, which will be excluded from Edge Full Page Cache.
  • Edge Full Page Cache will not respect custom cache exclusions for cookies. Other cache exclusion types (page, query arg) should work as expected. Learn how to review custom cache exclusions here. 
  • Edge Full Page Cache will respect cache-control headers set in the WP Engine mu-plugin and the Web Rules Engine.
• Page URLs that have been personalized with query strings will be cached as separate pages by Edge Full Page Cache for each unique version of the query string.
• Pages that generate personalized content via PHP may not work correctly with Edge Full Page Cache. For example, a page that uses PHP to generate a personalized welcome message (ex. “Hello Jorge”) might cache on the first user and display this message incorrectly to the next user(s).  However, pages that display personalized content using JavaScript will generally not have this problem as long as the JavaScript itself is generating the content.
• Access rules added to Nginx or Web Rules to control access to the website might also not work as expected, as the requests would be cached in Cloudflare’s CDN and the rules from the server in WP Engine would not be processed.

• NitroPack – While technically compatible, having both Edge Full Page Caching and NitroPack enabled at the same time offers no additional benefit. We recommend prioritizing NitroPack, if both options are available.
• Device type variants – Serving different versions of HTML for the same page based on device type (e.g. Mobile devices, Desktop), is incompatible since only one HTML version can be cached for the page with Edge Full Page Cache. Responsive pages using CSS Media Queries will still be compatible since the same HTML is used for all device types.
• WPGraphQL Smart Cache Clear – This plugin only clears WP Engine’s Varnish page cache and does not clear Cloudflare’s Edge Full Page Cache.
• GeoTarget – GeoTarget uses server-side logic to deliver country-specific content, so it is incompatible with Edge Full Page Cache. Using the two together will deliver unexpected results since the cached content will be based on user requests.

Cache headers are rules that tell each visitor’s computer how long to save assets (like images) locally on a person’s computer. Because these assets are stored locally, purging server cache will not clear old assets off of a visitor’s machine. Assets can only be cleared when the cache header reaches its expiration or the user clears their browser cache.

“Headers” refers to information that your web browser sends or requests. Some headers are sent with a page or file request, while others are associated with the response you receive back.

When a page or file is requested, the server and your browser both listen to the “Cache-Control” headers for instructions on who can access the cached copy, and how long the copy can be accessed. Cache-Control headers are important to your site’s scalability, so WP Engine already manages these headers for you.

To effectively leverage browser cache, these cache-control headers are used to tell the browser how long to store saved content.

By default, page cache is set to 600 seconds, or 10 minutes. Static assets (such as images) are set to 365 days.

Information

Cache-control headers cannot be set lower than 600 seconds (10 minutes). Anything lower requires a full cache exclusion rule.

Cache-control headers can be set for static assets (e.g. images, js, css, etc) by way of the User Portal, on the Web Rules page.

Learn more about adding headers in the Web Rules guide here:

• Web Rules Engine

There are multiple ways to see the Cache-Control headers set by your website, but the easiest way is within your web browser.

1. Right+Click or CTRL+Click on your web page
2. Click Inspect
3. Select the Network tab
4. Refresh the page
5. You should see something like this:

6. Click your page URL in the list – usually the first item
7. This will bring up a list of Response headers sent
   • If you do not see the headers straight away, be sure the Headers tab is selected

8. You will see two important headers:
   • cache-control: Tells the cache system (browser or server-level page cache) how long to cache the page in seconds.
     • When max-age is set to 600, the page can be cached for 10 minutes.
     
   • x-cache: Tells you whether the page was served from cache or not.
     • A HIT indicates the request was served from the caching layer. The number tells you how many times this version of a page has been served from cache.A MISS indicates the page was not served from cache. The x-pass-why header will tell you the reason why the request did not hit cache. In the example below, the reason this page was not cached is because it’s a WordPress® Admin page, which cannot be cached as a WP Engine default.¹
     

Making cache-related changes will typically affect site performance. The more cacheable a site is, the more it will gracefully scale with higher traffic volumes. Caching can also negatively impact site performance as well, so it is advise to alter cache length on items you are sure can be served from cache without issue.

There may be times when you want to cache a page for longer than the standard 10 minutes. In these cases, you can use a configuration plugin to set Cache-Control headers to your liking. Cache headers can be increased, but not decreased below 600 seconds (10 minutes).

Increasing the amount of time pages are stored in cache will help with site speed and the overall user experience on your site. Increasing cache headers varies by the type of asset. While there are other plugins and methods available, those will likely require placing header changes in your .htaccess file. WP Engine has deprecated the .htaccess file, so this is not a sustainable method and will not ensure your success. The options we recommend are listed below.

If you would like to increase the cache expiration on a website to improve performance and scalability, it is advised to use a method of altering cache headers that does so directly in PHP code, such as in the WP Engine mu-plugin. Alternatively, cache headers can be set on the Web Rules page of the User Portal, or by having a rule placed directly on Nginx by Support.

Cache-control headers for pages set lower than 600 (10 minutes) will not be effective, as this is the length of time set on WP Engine’s caching server directly.

Anything lower than 600 requires a full page cache exclusion, which can be added by WP Engine Support. We advise using cache exclusions very sparingly, as uncached pages can negatively impact performance at scale. We will not honor requests to uncache an entire website, a site homepage or add cache exclusions that otherwise uncache a large portion of your website.

Cache expiry for WordPress post and pages can be increased by way of the WP Engine mu-plugin available in the WordPress admin dashboard of the website.

Tip

Use the post and page expiry settings shown below if you want global rules for each content type. If you need granular controls then we recommend using Web Rules. If using Web Rules, leave the global settings shown below set to “default” and ensure that Smarter Cache is disabled.

1. Log in to the wp-admin dashboard of the website.
2. Click on WP Engine in the main menu.
3. Select the Caching tab.
4. Alter the Post cache length and/or Page cache length.

5. (Optional) Enable Smarter Cache and Last-modified Headers to increase cache even more for post that are not edited often.
   
6. Click the Save all changes button at the bottom of the page.

Cache length for REST API end-points can be increased through the WP Engine mu-plugin in your WordPress admin dashboard. To take effect, a change must be made from the default setting and then saved.

1. Log in to the wp-admin dashboard of the website
2. Select WP Engine from the main menu
3. Click Caching
4. Alter the desired end-point(s)
5. Save all changes

There are situations when a page should never be served from cache and the interaction should always be treated as unique, such as during checkout or login. Our servers will respect cache exclusion rules for pages, cookies and arguments.

Certain pages are removed from server caching by default on all sites to help ensure functionality. Some of these default cache exclusions are:

• WP Admin area
• wp-login.php
• Pages named cart, checkout, store or check-out
• Pages where a cookie containing wordpress_ has a value set

If we see WooCommerce^® on the site we add some extra default exclusions, so you don’t have to worry.¹ We exclude the following pages from cache:

• /products-compare
• /coupon
• /my-account/lost-password
• /wp-json/wc
• /wc-api

As well as the arguments:

• add-to-cart=.+
• wp-api=.+

And finally, these cookies:

• woocommerce_items_in_cart=[1-9]+
• wp_woocommerce_session
• woocommerce_cart_hash
• woocommerce_recently_viewed
• store_notice[notice id]

While we’ve added some default exclusions there are still situations you may need custom cache exclusions put in place. You can use exact values or you can use regex to specify patterns.

Information

The option to add your own cache exclusions in the User Portal is not available for all accounts. If you do not see the + Add new exclusion button, then you can contact our Support team to have them add a cache exclusion for you.

The 3 types of cache exclusions you can add are:

• Page URL path
• Query string argument
• Cookie: If you need a cookie rule added, contact our Support team to have them add the cookie cache exclusion for you.

To view or add custom cache exclusions in the User Portal:

1. From the Sites page, click on the environment name in the list of sites and environments.
2. Select Cache in the secondary lefthand menu (You may have to expand the Manage dropdown section).
3. Scroll down to the Cache exclusions section.
   
4. To add a new rule, click the + Add new exclusion button.
5. Choose from the available exclusion types of URL path or Query arg.
6. Type the URL path or query string argument to be excluded, into the URL field.
   Review examples below:
   1. URL path examples
   2. Query arg examples
7. Click Add exclusion to save your cache exclusion rule. Rules can sometimes take 10-15 minutes before they begin to take affect.

Tip

When setting cache exclusions, you should be as specific as possible. Too many pages excluded from cache by a cache exclusion rule will impact performance. We reserve the right to remove cache exclusion that are negatively impacting server performance.

Paths correspond to pages on your website, and the path is the part of page URL that comes after the domain name. For example, the path for https://example.com/path-to-page/ would be: /path-to-page/.

When submitting path cache exclusions to our support team to exclude a web page from cache, remember that the path is in RegEx (regular expressions) format.

RegEx patterns for URLs will begin with the caret symbol: ^

RegEx patterns for URLs will end with the dollar symbol $, or they can be left open ended.

You also have to consider the optional forward slash at the end of URLs. WordPress supports both /path-to-page and /path-to-page/. To include the optional forward slash in your path you will add a / with a ? after it. This will allow both options. The below is an example of a path to a specific page with the optional trailing slash.

^/path-to-page/?$

If you mark the end of the path with a $ then you are specifying an exact path to a specific page. If you leave it open ended with no $ at the end, then our system will also apply the exclusion to URLs that match your specified path with any characters after it. There are use cases for both options outlined below.

An example of a case when you would not want to leave the path open ended:

1. You add an open ended path exclusion for your about page. ^/about.
2. You also have a web page of https://example.com/about-widgets which you don’t want to be excluded from cache.
3. Your open ended exclusion path would also exclude the /about-widgets page since beginning of the path still matches.
4. In this case you would want to include the $ in your path to make sure you are only excluding the /about page and not the /about-widgets page.
5. The correct path you would give to the support team in this case would be: ^/about/?$

An example of when you would want to leave the path open ended:

1. If you have many about pages that all start with the path prefix of about, and they all needed to be excluded from cache, then an open ended path would be useful for you. This would allow you to exclude all of the necessary pages with just one path.
2. The correct path in this case would be open ended: ^/about
3. Note: In this case you would also have to confirm that there are no other matching paths that start with “about” that you do not want to be excluded. For example, you want /about-product-1 and /about-product-2 to be excluded but not /about-our-leaders.
4. If not all URLs that start with /about can be excluded, then you may have to add individual exclusion paths for each URL that needs to be excluded like the below examples:
   • ^/about/?$
   • ^/about-product-1/?$
   • ^/about-product-2/?$
   • An alternative to excluding all of the /about-product URLs individually would be to use an open ended path for those: ^/about-product-

Arguments (sometimes referred to as “args”), are metadata that can be passed along with a page URL as a “query string” and read by server side code. Think of them as variables with a name and value. In the case of WordPress they can read by PHP code to help customize a page. Arguments can be appended to a web page URL by adding a ? at the end of the URL and then adding each argument name and value (name=value), separated with the & symbol.

The following is an example of 2 arguments (color and size) being added to a URL:
https://example.com?color=green&size=large

The “query string” in this example is: ?color=green&size=large

When you submit arguments to our support team as cache exclusions, then any page that is visited with that argument appended to the URL, will be excluded from cache.
Note: arguments are case sensitive.

You can submit just an argument name like color, or you can submit a specific argument name and value like color=green.

Submitting just the argument name of color would exclude page URLs that specify any color in the query string.

Submitting an argument name/value combo like color=green would exclude only page URLs that specify the color green.

Cookies are similar to arguments because they are also metadata for a web page with a name and value. The difference is that arguments are passed from the web browser in the page request, and cookies are passed from the server in the page response. Cookies can only be set by server side code and cannot be affected by the website visitor like arguments.

Cookies will either be set by your website developer, a plugin or theme developer, or by 3rd-parties like browser extensions. Cookies can be read by utilizing the developer tools panel in your web browser.

When you submit a cookie to our support team as a cache exclusion, then any page that has the cookie present, will be excluded from cache.
Note: cookies are case sensitive.

This works the same as argument exclusions because you can specify just the cookie name or a name with a specific value.

Submitting a cookie of color would exclude all pages that specify a cookie named color that has any value.

Submitting a cookie of color=green would only exclude pages with a cookie named color that has the exact value of green.

Cache exclusions can be tested by advanced users with knowledge of computer “terminals”. The terminal on your computer is where you can run shell scripts or commands.

The terminal command that you can use for testing is called the curl command. This command lets you input a URL and see the server response.

Note: When using the “curl” command some terminal programs will escape characters for you with a backslash as you type them, like the ? and = symbols. For example, if you type a query string of ?color=green at the end of a URL, it might get escaped automatically to look like the below command. This is normal behavior and the command should still work as expected.
curl -IL https://example.com.com/example-page/?color=green

Test a PATH Cache Exclusion

1. Open the terminal on your computer.
2. Type the following command and replace “example.com/path-to-page/” with the URL of the page that you are testing.
   curl -IL https://example.com/path-to-page/
3. Hit Enter or Return to run the command.
4. The output will look similar to this example:
   HTTP/2 200
date: Tue, 16 Sep 2025 16:10:21 GMT
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
link: https://mgrtntst.wpenginepowered.com/wp-json/; rel="https://api.w.org/
link: https://mgrtntst.wpenginepowered.com/wp-json/wp/v2/pages/81; rel="alternate"; title="JSON"; type="application/json"
link: https://mgrtntst.wpenginepowered.com/?p=81; rel=shortlink
x-powered-by: WP Engine
x-pass-why: custom-path
cf-cache-status: DYNAMIC
server: cloudflare
cf-ray: 9801a226ae6467c5-DFW
alt-svc: h3=":443"; ma=86400
5. In the output, look for the presence of the x-pass-why header. If you see the x-pass-why header with a value of “custom-path” then the page is successfully excluded from our page cache due to a path cache exclusion.
   x-pass-why: custom-path

Test an ARGUMENT Cache Exclusion

1. Open the terminal on your computer.
2. Type the following command and replace “example.com/path-to-page/” with the URL of the page that you are testing. The URL must also include the argument that you are testing in place of color=green below.
   curl -IL https://example.com/path-to-page/?color=green
3. Hit Enter or Return to run the command.
4. The output will look similar to this example:
   HTTP/2 200
date: Tue, 16 Sep 2025 16:10:21 GMT
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
link: https://mgrtntst.wpenginepowered.com/wp-json/; rel="https://api.w.org/
link: https://mgrtntst.wpenginepowered.com/wp-json/wp/v2/pages/81; rel="alternate"; title="JSON"; type="application/json"
link: https://mgrtntst.wpenginepowered.com/?p=81; rel=shortlink
x-powered-by: WP Engine
x-pass-why: custom-args
cf-cache-status: DYNAMIC
server: cloudflare
cf-ray: 9801a226ae6467c5-DFW
alt-svc: h3=":443"; ma=86400
5. In the output, look for the presence of the x-pass-why header. If you see the x-pass-why header with a value of “custom-args” then the page is successfully excluded from our page cache due to an argument cache exclusion.
   x-pass-why: custom-args
6. To test an argument name that can have any value, simply leave off the argument value from the command like this:
   curl -IL https://example.com/path-to-page/?color=

Test a COOKIE Cache Exclusion

1. Open the terminal on your computer.
2. Type the following command and replace “example.com/path-to-page/” with the URL of the page that you are testing. You must also replace “cookiename” with the name of the cookie, and “cookievalue” with the value of the cookie.
   curl -ILb "cookiename=cookievalue" https://example.com/path-to-page/
3. Hit Enter or Return to run the command.
4. The output will look similar to this example:
   HTTP/2 200
date: Tue, 16 Sep 2025 16:10:21 GMT
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
link: https://mgrtntst.wpenginepowered.com/wp-json/; rel="https://api.w.org/
link: https://mgrtntst.wpenginepowered.com/wp-json/wp/v2/pages/81; rel="alternate"; title="JSON"; type="application/json"
link: https://mgrtntst.wpenginepowered.com/?p=81; rel=shortlink
x-powered-by: WP Engine
x-pass-why: custom-cookie
cf-cache-status: DYNAMIC
server: cloudflare
cf-ray: 9801a226ae6467c5-DFW
alt-svc: h3=":443"; ma=86400
5. In the output, look for the presence of the x-pass-why header. If you see the x-pass-why header with a value of “custom-cookie” then the page is successfully excluded from our page cache due to a cookie cache exclusion.
   x-pass-why: custom-cookie
6. To test a cookie name that can have any value, simply leave off the cookie value from the command like this:
   curl -ILb "cookiename=" https://example.com/path-to-page/

Extensive caching can complicate things if you’re working on your site and expecting to see changes immediately on the frontend. Purging cache is an essential part of the development process. There are two different methods to trigger the purge cache functionality.

Purging cache through the User Portal is considered the recommended method because it does not require access to the wp-admin of your website and allows you to purge individual caches, page cache, and object cache.

1. From the Sites page, click the environment name
2. Select Cache (You may have to expand the Manage dropdown section)
3. You will see the following options:
   • Clear all caches – When used, your website will be slower for a period of time until the pages become newly cached.
     • Page cache (Varnish)
     • Network caches (Advanced Network and Global Edge Security) including CDN cache
     • Object cache (if enabled)
     • NitroPack cache
   • Clear page cache – Clears only the dynamically generated version of your pages (Varnish caching).
   • Clear network caches – Purges the network caches for advanced network and Global Edge Security, including CDN. This option displays only if you have added a domain to the environment.
   • Clear object cache – If enabled, clears stored query results.
   • Clear local cache – See steps to clear local browser cache. Learn more here.

Information

Note

You may still need to purge browser caches, which is done locally, to see your changes appear.

Cache can be purged from the wp-admin dashboard of your website. This method will purge page cache (varnish), Global Edge Security, and advanced network caches. It will not purge object cache.

1. Log in to your website’s wp-admin dashboard
2. Click on the WP Engine plugin tab in the main menu
3. Select Caching
4. Click Clear All Caches 

Information

Note

In a multisite, all subsite caches will also be cleared when using this option.

The customer API can be leveraged to purge cache by making a POST request to the /installs/{install_id}/purge_cache endpoint. Learn how to enable the API and check out our API documentation.

This leverages the same cache purge functionality as the wp-admin button, meaning this method will purge the following caches: page (Varnish), CDN, advanced network, and Global Edge Security. It will not purge object cache.

Through the WP Engine MU plugin there is a function called wpecommon::purge_varnish_cache(). The post ID you want to purge can be passed into this function. Varnish page cache is purged only for that post URL, and not for the entire domain. This can have a positive impact on a website’s performance by keeping all other pages stored in cached.

If wpecommon::purge_varnish_cache() is called without being passed a post ID, then Varnish will be purged for the entire domain.

This function can be built into your PHP code, if you so choose.

Your browser may cache items such as: css styles, cookies and sessions, auth boxes, DNS/IP Addresses, and permalinks. Browser cache generally respects the cache-control headers sent back with the request from the web server.

Meaning if someone requests the /about-me/ page on your site and it has a cache-control time of 10 minutes/600 seconds, the page is not only cached on our server, it’s also cached in the browser for that amount of time.

For static assets, which have long-cache expiration times (images, css, etc), this means the browser will also cache them for the time specified by the server when sending the request back. The default cache expiration for static assets on WP Engine is 365 days.

Most browsers respect CTRL+F5 (Windows) or CMD+SHIFT+R (Mac) for a hard-refresh, which reloads the page and ignores any existing browser cache.

• Google Chrome
• FireFox
• Internet Explorer
• iOS Device (iPhone/iPad)
• Safari

Information

Note

Browser cache can only be purged for your own device. There is no way to force other visitors to purge their browser cache.

Plugins and themes will often cache content as well, which can cause old data to be stored and served. We’ve gathered some common plugins with cache below as an example:

• Autoptimize
• WP Minify
• Fast Velocity Minify

We also recommend checking out our guide on Flywheel for more information on clearing theme cache.

• Check your site for caching or compression plugins and purge their cache.
• Are you using Cloudflare? Login and purge Cloudflare cache.
  • We also suggest installing the Cloudflare plugin to easily purge Cloudflare cache from your wp-admin dashboard.
• Are you using a firewall service, like Sucuri? Log in to their portal and purge caches.
• Check the page in a proxy, like GeoPeeker or kproxy, to see how it looks in other locations.
  • If the changes show correctly, then you’ll need to purge browser cache.
  • If the changes do not show, try purging server caches.
• DNS caching could be at play as well. This easiest way to purge this is simply by restarting your computer or device. Otherwise, you can try flushing your DNS manually.

If you’re still not seeing your updated content, just open a Live Chat (available 24/7) with our Support Team from within your User Portal, and we will gladly help troubleshoot further.

If you’d like to see an updated version of a specific page, but don’t want to clear caches for their whole website, you can manually “bust cache” locally, by adding any random argument onto the end of the URL.

EX: To see a newly generated version of https://somedomain.com/updated-page/ you could go to https://somedomain.com/updated-page/?a=b to force the page to be generated new from the server.

Once it’s loaded, the URL is cached on the server again. Meaning simply reloading the URL will show the same cached version. If you want a new version each time you must change the arg value each reload:

This will only address WP Engine server cache because our server sees the change in URL as a completely different page. Your local browser, caching plugins, and some firewall or proxy service could still see this as the same page and serve from their cache.

When you’re working on Staging or Development environment, using dynamic query strings in the URL for your theme’s stylesheet can be really useful when you want to see new css changes more often. With a dynamic query string in a CSS file URL, it should be uncached every time the page cache clears. By default page html is cached for 10 minutes on WP Engine. If you have that minimum setting for page cache times, your CSS file will get a new query string every 10 minutes when the page cache clears which refreshes cache for the CSS file.

One example that some people use during development is to append a random version number with php. The following examples add a random 10 digit number in the query string.

Example in a <link> tag:

<link rel='stylesheet' href='https://example.com/wp-content/themes/example-theme/style.css?v=<?php echo mt_rand(1000000000,9999999999); ?>' />

Example in a theme or child theme functions.php file:

wp_enqueue_style('theme-stylesheet', get_stylesheet_uri(), array(), mt_rand(1000000000, 9999999999));

Information

Note

Using dynamic query strings is not recommended for live Production environments since caching is important for reducing page loading times.

If you’re attempting to clear CSS cache once on a Production site, you can push a change to the CSS file URL with a new static version number. The following examples are the same as the dynamic options above but use a static number instead of php. The number ‘1.1’ below can be added or changed to something new like ‘1.2’ or ‘2.0’.

Example in a <link> tag:

<link rel='stylesheet' href='https://example.com/wp-content/themes/example-theme/style.css?v=1.1' />

Example in a theme or child theme functions.php file:

wp_enqueue_style('theme-stylesheet', get_stylesheet_uri(), array(), '1.1');

A cURL can tell you quite a bit about where the URL may be getting cached. You can curl from your terminal or with a tool like Online Curl.

You may have to cURL a page a few times in a row to generate cached hits.

This page can be cached but it is the first time it’s been generated by the server, so this specific hit was not served from cache:

This page is cached and this version is served from cache. It is the first time this page has been served from cached.

NEXT STEP: Learn how PHP sessions and cookies work on WP Engine