The WordPress Hardening Checklist We Run Before Every Launch

WordPress sites don't get hacked because WordPress is insecure. They get hacked because launch day ends at 'it looks done.' Security is a checklist, not a product. This is ours — the same one that runs before any client site meets the public internet.

Maintenance is a product

Sites don't decay because of hackers and core updates; they decay because nobody's job is 'keep it excellent.' Updates run until something breaks, then maintenance gets funded retroactively with interest.

The retainer structure that works is small and relentless: weekly updates in staging, monthly regression checks, quarterly performance and uptime reviews, and a human who knows the site answering within hours.

The cost comparison that convinces finance: one emergency weekend versus twelve months of quiet Tuesdays.

The launch-week readiness list

1. Backups verified by an actual restore, not a green dashboard icon
2. Rollback plan rehearsed: one command back to last-known-good
3. Error monitoring on production with an owner assigned
4. Core Web Vitals re-tested on production hardware, not staging
5. 301s spot-checked from the old sitemap, robots and canonicals audited
6. The 'who gets paged' list updated and acknowledged before Friday

Audit before architecture

Every rebuild that goes smoothly started with an inventory nobody wanted to write: templates in use, plugins with business logic buried inside, integrations with tribal knowledge as documentation. Skipping the audit doesn't save the week — it bills the month.

We export the plugin list, crawl every template, and interview whoever touches the site weekly. The output is a one-page map of what the site actually does, as opposed to what anyone remembers it doing.

Ninety percent of rebuild surprises were knowable on day three. The other ten percent are why timelines have buffers, not excuses.

We don't do rescue projects anymore. We do builds that never need rescuing.Humdan Ali, founder

Technical debt has an interest rate

Nobody feels technical debt on the day it's taken. It arrives eighteen months later as 'a simple change' quoted at three weeks: the workaround that became load-bearing, the plugin forked and now unforkable.

The honest measure is drag per quarter — how much slower is each change than the one before it. When drag doubles, consolidation pays for itself faster than new features.

Performance is architecture, not decoration

Speed work fails when it's scheduled as polish at the end — by then the decisions that mattered are entrenched: a builder emitting four wrappers per element, a slider library loaded for one page, fonts subset for nobody.

We budget performance like features: a 100-point Lighthouse target has an implementation plan from the wireframe. Image pipelines, script governance and font discipline are agreed before visual design polishes anything.

Teams that treat speed as a launch-week task end up shipping apology notes. Teams that budget it ship numbers.

The best code on a client site is the code nobody has to think about for five years.ALIFY engineering notes

Where to start this week

Today, before anything else: audit admin users, kill xmlrpc if unused, force 2FA, and confirm backups actually restore. Twenty minutes, four holes closed.

Then keep it honest with a short list:

• Every change request returns with a bigger estimate than the last one
• Two plugins conflict and the fix is a third plugin
• Mobile LCP is over 4 seconds and nobody remembers why
• Put the date on the calendar — playbooks without Fridays are just reading

And when the scope outgrows the spreadsheet, that's precisely what our team is for.

Straight answers

How do you handle deployments and downtime risk?

Versioned releases to staging first, database-free deploys where possible, rollback rehearsed before it's needed. Launches happen mid-week mornings, never Fridays, never unattended.

How long does a typical WordPress or Shopify build take?

Six to ten weeks for most marketing sites and stores: two for discovery and architecture, three to five for design and build, and one hardening week we refuse to skip. Rushed timelines are available; we just document what you're trading.

Who owns the code and hosting?

You do — repositories, credentials, hosting, everything. Agencies that hold infrastructure hostage are telling you about their retention strategy, not their confidence in their work.