Playbooks.

Update plugins without ever leaving the site broken. Back up, prove the backup restores, judge each plugin, apply one at a time, verify, roll back on failure.

Match what is installed against what is publicly known to be vulnerable, and judge whether it is actually reachable on this site.

Clear the accumulated junk and optimise the tables, after a backup and never before one.

Know the site is down before the client does.

Never be surprised by an expiry, on the certificate or the domain.

Prove mail actually leaves the site and lands in an inbox rather than junk.

Prove the backup restores, on a schedule, before the day you need it.

Find the scheduled work that has stopped without telling anybody.

Warn before a paid plugin stops receiving security updates.

Clear the spam that WordPress has already flagged, and nothing else.

Test the real pages against WCAG and report each failure with its fix.

A risk-ordered report on the six things most sites get wrong. Changes nothing.

Apply the hardening fixes one at a time, and confirm the site still works after each.

Scan, quarantine, clean, harden, rescan, and produce an incident report you can hand to a client.

When the site is broken, find what did it and fix it, one change at a time, rolling back the moment it gets worse.

Find dead links and bad redirect chains, propose a target, and fix on approval.

List every image that fails to load, and the page it sits on.

A full crawl reported in the order that costs the most traffic.

Audit one page, propose every on-page fix, apply on approval, then recheck.

Buy something from the store, prove it worked, and take the purchase back out. Every morning.

Read what the site is actually running on, so a host moving you to a new PHP version is something you knew about first rather than something a client reports.

Apply the WordPress core update on a schedule, with a backup that came first and a rollback that is already prepared before the first file moves.

A theme update is the one most likely to change how a site looks rather than whether it works, so this checks the appearance and not only the status code.

On a site that is not in English, an out of date translation shows English strings to a customer in the middle of a checkout.

Staging is only worth testing on while it still resembles live, and this says exactly where the two have come apart.

Recover the disk that a decade of unused uploads is holding, without deleting a single file the site still shows.

Plugins you removed years ago left their rows behind, and some of them are read on every page load.

Expired transients are cached values nothing will ever read again, and on a busy site they can be the heaviest thing in the options table.

Every page load reads the autoloaded options first, so when a plugin leaves a megabyte in there, every visitor pays for it.

Count how many people can install a plugin on this site, and how many of them still work there.

Password resets and every critical WordPress notice go to one address, and if it points at somebody who left you find out during an incident.

Scheduled posts publishing at the wrong hour and order timestamps an accountant queries both come from one setting nobody checked.

After a migration every post can return 404 while the homepage looks perfectly fine, and the fix is one action nobody thinks to try.

One checkbox left switched on after launch tells search engines to stay away, and it can cost months of traffic before anybody notices.

A page that used to bring in work now returns nothing, and the only person who knows is the visitor who left.

A redirect pointing at another redirect loses a little of every visit, and a loop loses the whole page.

A full disk stops uploads, stops backups and eventually stops the database, and the first sign is usually a white screen.

Find which plugin is causing the fault, without taking the site down in front of visitors while you look for it.

WordPress puts no limit on login attempts, so a username plus a word list is a workable way into most sites.

A stolen administrator password is how most WordPress sites are actually taken, and a second factor is the only thing that stops it being enough.

A configuration file the web server can write to is a configuration file somebody else can rewrite.

One changed line in a core file is how a site stays compromised long after the plugin that let them in has been removed.

A plugin file edited after installation is either a developer's shortcut you will lose at the next update, or somebody else's code running on your site.

A plugin nobody has touched in three years will not get a fix on the day a vulnerability is found in it.

When a plugin is removed from the WordPress directory it stops receiving updates that day, and it is often removed because of a vulnerability nobody has published yet.

Your account names are half of a login, and WordPress hands them to anybody who asks in five different places.

XML-RPC lets somebody try a thousand passwords in a single request, but switching it off blindly breaks Jetpack and the mobile app.

The REST API answers to anybody by default, and plugins add routes to it that were never meant to be read from outside the site.

The headers a site sends decide what a browser is allowed to do with it, and the one that matters most is also the one that breaks sites when it is added carelessly.

An administrator account you did not create is the clearest sign somebody else has been in, and it usually appears weeks before anything visibly breaks.

Compress the images that are actually slowing pages down, keep every original, and stop before the plugin's free quota runs out.

Serve WebP and AVIF to the browsers that read them, and keep the JPEG for the browsers that do not.

Stop the page jumping while it loads by giving every image a width and a height, and take lazy loading off the image at the top.

Get the stylesheets out of the way of the first paint, one template at a time, without changing how the page looks.

Name the stylesheets loading on pages that never use a single rule from them, and say what they cost.

Stop the scripts that nothing on the first screen needs from holding up the paint.

Stop text being invisible while a font downloads, and preload only the one file the first screen actually needs.

Serve pages from cache to visitors, and never to somebody signed in or halfway through a checkout.

Stop the site repeating the same database queries on every page load, when the host already gives you somewhere to keep the answers.

Serve the static files from an edge close to the visitor without breaking the pages that reference them.

Find the plugin tables that grow forever and are never trimmed, and give the site back the space they hold.

WordPress loads a set of options on every single request. When that set reaches a few megabytes, every page on the site pays for it.

The admin screen calls the server every fifteen seconds. On a small host, a few tabs left open is enough to use every PHP worker the site has.

Read what the host actually gives this site, so a slow page gets blamed on the right thing.

Track the three metrics Google actually uses, template by template, and say plainly where each number came from.

Check the sitemap lists the pages you want found, only those, and that every address in it answers.

Say which pages Google has indexed, which it has dropped and why, from Search Console rather than from a guess.

Find the pages pointing search engines at a different address, which quietly hands their ranking to something else.

Flatten the redirect chains that make every visitor and every crawler take three hops to reach one page.

Find the pages sharing a title or a description with another page, and give each one its own.

Find the pages whose headings do not describe the page, which is the cheapest on-page problem to fix and the most common one.

Show how many clicks from the homepage each page sits, because a page five clicks deep is crawled rarely and ranks badly.

Find the published pages nothing on the site links to, which usually means a menu item was removed and the page was forgotten.

Check the structured data on every template is valid, and that it describes the business the site is actually for.

On a site in more than one language, check every page names its counterparts correctly, because one wrong tag drops a whole language out of the results.

Catch the single setting that tells every search engine to go away, which is left switched on more often than anybody admits.

Find every image on the site with no alt text, and write one for the images that actually carry meaning.

Give Google the path to each page so the search result shows your structure instead of a raw address.

Check the second and later pages of every archive are handled properly, because this is where sites quietly lose half their category pages.

Find the pages with too little on them to rank, and the pages that are near copies of each other, which is usually one location page template.

Confirm every payment method the store offers is switched on, configured and answering, without ever putting a real card through it.

Watch the share of checkouts that end in a failed order, and tell you the morning it moves rather than at the end of the month.

Find the orders that stopped halfway, where the customer paid and the store never noticed.

Find the products the store can sell more of than it holds, before a customer buys one you cannot ship.

Stop sending search traffic to products you cannot sell, and give the visitor somewhere else to go.

Find the places the store takes orders from but has no shipping method for, so checkout ends in an apology.

Check the tax settings still match how the store actually sells, before an accountant finds out they do not.

Watch the background queue that sends the emails, syncs the stock and finishes the orders, because when it stalls nothing on the site looks broken.

Run the database update WooCommerce is waiting for, after a backup, one batch at a time.

Find the store templates the theme copied years ago and never updated, which is how a checkout quietly loses a field.

Measure the uncached request the store makes on every page load, which is the commonest reason a shop feels slow to the person browsing it.

Check the product markup search engines read still matches what the store actually sells today.

Make sure one price is not described three different ways, which is how a store ends up charging in the wrong currency.

Find the discount codes that outlived their campaign, and close the ones you say to close.

Watch the renewals that pay the client's bills, and notice the day they stop going through.

Prove a refund and a cancellation still work, using orders Protuno created itself and never a real one.

Find the analytics tag that loads twice, because it doubles every number you report and always in the flattering direction.

Confirm the events you report as leads and sales are still arriving, by asking the analytics property rather than guessing from the page.

Confirm the enquiries people send are being recorded, and tell a quiet week apart from a broken form.

Watch how much of the enquiry volume is junk, so the real ones stop being lost in the pile.

Build the monthly report out of what actually happened, and leave it as a draft you read before anybody else does.

Know when Google drops pages out of the index on the day it happens, rather than when the traffic report lands.

Make sure a shared link shows a title and a picture rather than a bare address, and fix the pages that do not.

Check what the site loads before anybody has agreed to anything, because that is the part a regulator asks about first.

Watch the pages the campaigns point at, because the homepage being up says nothing about the page you are paying for clicks to.

Prove the people signing up are reaching the list they signed up to, instead of stopping at the form.

Check the site is not throwing away the campaign parameters you attach to every link you pay for.

Watch the links already printed on vans, sitting in old emails and running in live ads, and notice the day one stops resolving.

Compare the tracking on the site before and after a change, so a theme update never quietly deletes the pixel.

Check the conversions the analytics property counts are still the ones the client's report is built on.

Prove whether the uploads folder will run a PHP file, which is the difference between a file-upload bug being an inconvenience and being a takeover.