Production-Readiness Checklist

Work through them before you call anything done, not after.

Most public checklists of this kind read like the feature list of a hosting plan. Have caching. Have backups. Have monitoring. The trouble is that having a thing and the thing working are two different states, and the failures I get called in for almost always live in the gap between them. So each section below opens with the reason it is there, and a handful of the individual checks exist because that exact item failed quietly on a real site and cost me a week before I noticed.

Answer each one yes or no. If an item needs a "well, mostly", write it down as a no and come back to it.

Infrastructure

Infrastructure rarely fails on the day you get it wrong. You size a box for the traffic you have today, the business grows, and the first symptom is a contact form timing out on a Friday afternoon eight months later. Everything in this section has that shape: the decision is cheap now and expensive later, and the bill arrives on somebody else’s schedule, usually while the one person who understands the setup is away.

• The server is correctly sized for real traffic, not guessed at.
• PHP, web server, and database versions are current and supported.
• DNS records are documented and email authentication (SPF, DKIM, DMARC) is in place.
• SSL is valid and renews automatically, with no mixed-content warnings.
• A staging environment mirrors production closely enough to trust.
• Deployments follow a defined process with a clear rollback path.

Security

Nobody is targeting you. That is the part smaller businesses get right and then draw the wrong conclusion from. The traffic that finds your login page is automated and indiscriminate, it arrives whether you are interesting or not, and it does not stop. So the question is never why anyone would bother with you. It is whether the dull defences are actually switched on, and whether anyone would notice if one of them quietly was not. Every item here is dull on purpose.

• Admin logins are protected with strong credentials and two-factor authentication.
• A firewall or WAF is active and rate limiting blocks brute-force attempts.
• File and directory permissions are locked down, not left at defaults.
• Core, plugins, and themes are on a patch schedule, not updated ad hoc.
• Security headers are set and verified.
• An incident response plan exists and names who does what.

Performance

Performance work fails in a particular way: you optimise the thing you can see, and the slow thing is somewhere you are not looking. I spent the better part of a week on a client homepage whose Largest Contentful Paint would not come down, chasing DOM size and CSS delivery. I did get the DOM down, rebuilding star ratings that were drawing ten SVG nodes each into two, and capping a slider that was cloning slides without limit. It moved the metric by nothing at all. The real cause was the hero image being served as AVIF, on the reasoning that AVIF is the newer format and the smaller file. Lighthouse’s mobile profile applies a 4x CPU throttle, and AVIF costs far more to decode than WebP does. The 19 KB the newer format saved on the wire was handed straight back, several times over, in decode time on a throttled processor. Switching the hero to WebP brought the paint down when nothing else had. A smaller file is not automatically a faster paint, and finding one real cause is not the same as finding all of them.

Two of the checks below look oddly specific, and they are. On that same site the purge routine called a method that no longer existed and swallowed the failure, so every "cache cleared" it reported back was a lie. Separately, the cache directory had become root-owned, and the preloader ran for seven and a half minutes writing zero pages, with no error logged anywhere, while real visitors were served uncached PHP. Neither failure was visible from the outside. A cache operation that cannot fail loudly will eventually fail quietly, and you will spend the following week measuring the wrong thing.

• Core Web Vitals (LCP, INP, CLS) are measured and within target.
• Images are optimised and served at the right dimensions.
• Caching is configured at the page, object, and edge layers as appropriate.
• Render-blocking assets are minimised and non-critical scripts deferred.
• The database is clean, indexed, and free of orphaned data.
• A CDN serves static assets close to your audience.
• Cache purges are verified to have actually emptied the cache, not merely to have returned success.
• Cache and preload directories are writable by the web user, not owned by root.

Operations

Operations is the section people set up once and then trust forever, and the trust is the failure mode. A backup you have never restored is a hypothesis. An alert nobody has ever received is a hypothesis. A scheduled job is the worst of the three, because WordPress cron is not cron: WP-Cron only runs when somebody loads a page, so on a quiet site the 4am job simply never fires, however healthy the settings screen looks. That screen will keep telling you the job is scheduled right up until the day you check what actually executed. The items here are written so you have to prove each one rather than believe it.

• Uptime and error monitoring alert you before clients notice a problem.
• Backups run automatically and have been restored at least once to prove they work.
• Every system and credential is documented somewhere your team can find it.
• Analytics capture the events that actually inform business decisions.
• There is a single owner for the system, not a diffuse "someone should".
• A maintenance routine is scheduled, not left to whenever something breaks.
• Scheduled jobs run from real system cron, not from visit-triggered WP-Cron.