WordPress on Nginx: Performance and Cache Safety Checklist

July 13, 2026 refresh: This guide now focuses on the decisions and verification steps that keep a WordPress site fast on Nginx without caching a customer’s session, breaking publishing, or exposing fragile server-level instructions. Treat any web-server change as an operations change: take a recoverable backup, test in staging where possible, make one change at a time, and keep a rollback path.

Nginx can be an excellent WordPress web server or reverse proxy, but its speed comes from knowing which responses are safe to reuse and which must stay personal or dynamic. This checklist is for site owners, hosting teams, and agencies who need a practical review before changing an Nginx, PHP-FPM, CDN, or cache setting. It is intentionally code-free; apply supported server changes through your host’s documentation or a qualified administrator.

Start with a baseline, not a configuration change

1. Capture a recovery point. Include WordPress files, database, uploads, the active theme, important configuration, and the hosting account or server settings needed to reverse the change.
2. Record the current behavior. Check an anonymous public page, a logged-in administrator session, a contact form, search, media uploads, scheduled work, and any checkout or account workflow before maintenance begins.
3. Note every cache layer. List the CDN, host cache, Nginx or FastCGI cache, WordPress cache plugin, browser cache, object cache, and PHP opcode cache. A page can look fast while still being stale at one of those layers.
4. Use a low-risk window. Avoid a busy sales, campaign, membership, or publishing period. Make sure the person approving rollback is available.

For a broader operational sequence, start with the FixItPhill WordPress support hub, then use the WordPress update-window checklist to document ownership, testing, and rollback.

Map the request path before tuning it

Write down how a visitor reaches WordPress: DNS and CDN, any reverse proxy, Nginx, PHP-FPM, the database, and third-party services such as payments, forms, search, analytics, and email. This turns a vague “Nginx is slow” report into a testable path.

Also confirm who owns each layer. A managed host may control Nginx and PHP-FPM. A CDN provider may control edge cache behavior. A plugin may add a separate page cache. Changing the wrong layer often creates duplicate caching, redirect loops, stale assets, or an issue that the next support person cannot reproduce.

Make cache safety the first performance rule

Nginx supports FastCGI caching, but the policy matters more than the feature. Cache only public, anonymous responses that are demonstrably safe to share. Keep administrative sessions, preview screens, forms, search results, password flows, membership pages, and other visitor-specific responses dynamic. The official NGINX FastCGI module documentation is the right reference for the cache capabilities available to the administrator maintaining the service.

For WooCommerce, the cart, checkout, and account experience must remain dynamic. WooCommerce documents that those pages show customer-specific information and should be excluded from caching. Review the official WooCommerce cache guidance with the host or CDN team before enabling or broadening a cache.

Cache-review questions

• Can an anonymous visitor see only public content after a cache purge and warm-up?
• Does a logged-in editor see current content, previews, and the dashboard without stale or public output?
• Do forms, search, comments, login, password reset, membership, and ecommerce workflows still receive the right response for the right visitor?
• Does publishing or changing a product purge the relevant pages across WordPress, Nginx, and the CDN?
• Can a support person identify which cache layer served a stale page before disabling everything at once?

Use the WordPress cache and CDN test guide after every cache-policy change. It is better to prove the public and logged-in journeys than to rely on a single speed score.

Keep PHP, WordPress, and the database in the review

Nginx does not run WordPress by itself. Dynamic requests still depend on PHP-FPM, WordPress, plugins, the database, filesystem permissions, and external services. A slow page may be a PHP worker limit, a database query, a remote API call, an oversized image, or an overloaded host rather than a web-server issue.

• Confirm the supported PHP version and required extensions before changing the web-server layer. Use the WordPress PHP version and extension checklist for the application-side review.
• Keep WordPress core, the active theme, and plugins current through a tested maintenance process.
• Remove or investigate inactive components that are no longer required rather than assuming caching will offset their cost.
• Review scheduled tasks, backups, search indexing, and email notifications after maintenance; these often reveal application-level trouble that an anonymous home-page test misses.

WordPress provides a built-in Site Health screen that groups critical issues, recommended improvements, and technical information. Capture its status before and after meaningful changes, but treat it as one signal alongside real visitor workflow tests.

Test TLS, redirects, and proxies as a single path

HTTPS, canonical URLs, redirects, and proxy behavior are connected. A site behind a CDN or reverse proxy can enter redirect loops or report the wrong scheme to WordPress if the layers disagree. WordPress documents HTTPS and reverse-proxy considerations in its HTTPS administration guidance.

After an Nginx, proxy, certificate, or CDN adjustment, check the public home page, a deep permalink, a logged-in dashboard, media uploads, forms, and any payment page. Confirm that canonical tags, sitemap URLs, and internal links consistently use the public HTTPS address. For a focused recovery path, use how to fix mixed content after enabling SSL and how to force HTTPS without breaking WordPress.

Use staged changes and observable rollback

Do not combine a PHP upgrade, Nginx change, cache replacement, CDN rule change, and plugin update in one window. Change one meaningful layer, test the agreed journeys, and record the result. Keep the prior supported configuration and backup reference available until public checks have passed and the site has operated normally for the agreed observation period.

A clean handoff note should state what changed, who approved it, where the recovery point is, the exact workflows tested, cache layers purged, monitoring used, and what remains to be watched. This is especially important for shared hosting and agencies where server access and WordPress access belong to different people.

Post-change verification checklist

• Anonymous public pages render current content without unexpected redirects or browser warnings.
• Logged-in administration, editing, previews, media uploads, scheduled work, and REST-dependent features still work.
• Contact, login, password, membership, and WooCommerce workflows remain private and dynamic.
• Cache purges reach the application, Nginx or host layer, and CDN where applicable.
• Uptime monitoring, error reporting, and the WordPress Site Health review show no new issue requiring action.
• Sitemaps, canonical URLs, robots rules, and key landing pages are reachable for visitors and legitimate search bots.

For an Nginx-hosted build rather than a tuning project, see the WordPress on Nginx LEMP hosting checklist. For ongoing validation, add the WordPress uptime and broken-page monitoring guide and backup and restore-point checks to the maintenance routine.

Sources

• NGINX FastCGI module documentation
• WooCommerce cache configuration guidance
• WordPress Site Health documentation
• WordPress HTTPS administration guidance

Last reviewed July 13, 2026. This support guide is intentionally defensive and does not provide raw server commands, configuration snippets, or access-control recipes.