Tag: playbook

Your site shows a white page, or the message “There has been a critical error on this website.”

You updated one plugin an hour ago, and you have a lot of plugins installed.

Short answer: A plugin list cannot prove a WordPress plugin conflict. Only errors, logs and a clean test can. What a plugin list can do is show you which plugins do the same job, which ones are switched off but still installed, and where to test first. That is the whole job of the Plugin Conflict & Redundancy Check playbook, and this post walks through its two steps.

What this post is, and is not: A method write-up of one read-only playbook, based on its two step files as shown in the Protuno dashboard on 16 October 2026. It is not a result from a real run: no playbook was run for this post, and every picture and plugin name in it is an illustration with example values. It is not a conflict detector, and it does not read error logs.

What A Plugin Conflict Looks Like When It Shows Up

A conflict rarely announces itself with the names of the plugins involved.

It shows up as a symptom. A page that stops loading. A checkout button that does nothing. A spinner in the editor that never finishes. In the worst case, the critical error message, or the white screen.

WordPress’s own training material describes where these come from. The Learn WordPress lesson on plugin and theme conflicts lists the most common causes of a white screen or critical error as an exhausted memory limit, PHP errors, database issues, and plugin or theme conflicts or compatibility issues. Within conflicts, it names code incompatibility with the current WordPress version, JavaScript errors that stop a page loading, and deprecated functions.

So a conflict is one of four possible causes, and the symptom does not say which. That matters for everything that follows. If you are staring at a broken page right now, read the white screen of death post first, because it covers the playbook for exactly that moment.

This post is for the quieter situation. The site works. You want to know where trouble is most likely to start.

Overlap Is Not The Same As Conflict

Two words get used as if they meant one thing. They do not.

An overlap is two active plugins doing the same job. Two page cache plugins. Two SEO suites. Two backup plugins on separate schedules. You can see an overlap from the plugin list alone.

A conflict is two pieces of code interfering with each other so that something breaks. You can only see a conflict from an error, a log, or a test that fails and then passes when one plugin is removed.

Overlap is a sensible place to look first, because two plugins doing the same job can end up competing for the same files and settings. But it is only a place to look. Plugin A and plugin B can have nothing in common and still collide, and two plugins in the same job can sit side by side for years without a problem.

The playbook is built around that gap. It reports overlaps and does not call them conflicts. The step instructions say so directly: say “overlap” or “risk”, never “broken” or “conflicting” as a fact, because the check reads the plugin list, not errors.

That restraint is what makes the report usable. A report that cried “conflict” about every pair of plugins would train you to ignore it.

The Playbook, Step By Step

In the Protuno dashboard the playbook is called Plugin Conflict & Redundancy Check. It carries the Beta label, it has two steps, and it only reads. The public playbooks page lists it under Care with the same name and the same two steps, and says it needs no connector and sets no schedule: it runs when you start it.

Both steps show Automatic backup as None and Approval checkpoint as Off in the dashboard. No step pauses to ask you anything.

A short silent video walks through the same two steps.

Step 1: Plugin Inventory And Classification

The first step reads the site’s plugin list twice: once for active plugins and once for inactive ones. Every call is a read. No plugin is activated, deactivated, updated, deleted or configured.

Each plugin is then sorted into one job from a fixed table, by exact slug. The slug is the part of the plugin path before the first slash, so wordpress-seo/wp-seo becomes wordpress-seo.

Three rules in this step are worth knowing before you read any report.

• The table is closed. A plugin whose slug is not in the table is marked unclassified. The step is told never to infer a job from a plugin’s name or description.
• Protuno’s own plugins are left out. The three connection plugins are listed as “Protuno connection” and are never classified or flagged.
• The counts must add up. Classified plus unclassified plus Protuno connection must equal active plus inactive, and the step checks the sum before it answers.

There is also a size limit. The reply from the plugin list is cut at 8,000 characters, which the step instructions estimate at about 75 plugins per status. If a list is cut, the step uses the complete items it has and records the inventory as partial. It never guesses the missing ones.

The Fixed Table Of Jobs

The table has thirteen jobs. Ten of them can produce an overlap finding, and each carries a severity.

Job	Severity when two or more are active
Page cache	High
Security and firewall	High
SMTP and mail	High
SEO suite	Medium
Asset optimisation	Medium
Backup	Medium
Image optimisation	Medium
Page builder	Medium
Redirects	Low
Anti-spam	Low

Three more jobs are handled differently. Elementor add-on packs count as stacking when three or more are active, and that is rated low. Forms and analytics plugins are listed for information only, because several of each on one site is often normal.

Step 2: Overlap And Conflict Report

The second step makes no calls at all. It composes a report from the inventory, and if the inventory is missing or the first step failed, it stops with a broken-chain message rather than inventing one.

It applies four findings and nothing else.

1. Overlap. Two or more active plugins in the same job, rated by that job’s severity.
2. Several installed. Two or more active forms or analytics plugins, listed under “For information” and not treated as a risk.
3. Add-on stacking. Three or more active Elementor add-on packs, rated low, because of overlapping widgets and extra assets on every page.
4. Inactive plugin. Every inactive plugin except Protuno’s own, rated low.

Inactive plugins never count toward an overlap. The reason they still show up is different. Inactive code is still on disk, and the step’s own wording is that it can still be attacked. If a plugin is not needed, delete it from the Plugins screen. The same wording adds that deleting cannot be undone, so keep the zip or a backup.

Why Each Overlap Matters

For every job, the step has a fixed reason, so the report explains itself instead of only listing names.

• Page cache: both try to own the cache and the advanced-cache.php file, so pages can go stale or break after an update.
• Security and firewall: double login blocking and lockouts, and rules that can block each other.
• SMTP and mail: both rewrite how mail is sent, and one can silently override the other. A separate post covers email deliverability.
• SEO suite: duplicate titles, meta tags, sitemaps and schema.
• Asset and image optimisation: double processing of the same files.
• Backup: two schedules, double load and storage, and no clear answer on which one restores.
• Page builder: two editors loading their assets.
• Redirects and anti-spam: rules evaluated twice, which makes it harder to tell which one acted.

Each finding names the plugins, gives the reason, and offers one safe next step: on staging, keep one, deactivate the other, then check the front end, forms and checkout.

What The Report Looks Like

The report has a fixed layout, so two reports from two sites can be read the same way.

• Plugins read: the active and inactive counts, and whether the inventory is complete or partial.
• Summary: overlaps by severity, inactive plugins, and unclassified plugins that were not assessed.
• Overlaps: a table of severity, job, active plugins, why it matters, and the first step.
• Add-on stacking, Inactive plugins and For information: each its own short section, or “none”.
• Not checked: real runtime errors and hooks, each plugin’s own settings, must-use plugins, and every unclassified plugin.
• Note: a line confirming it was a read-only check and nothing was changed.

“No overlaps found” counts as a pass.

A Five-Minute Version You Can Do By Hand

You do not need a playbook to get the first half of this value. Open the Plugins screen and do this.

1. Sort the installed plugins in your head into jobs: cache, security, SEO, backup, mail, images, redirects, spam, page builder.
2. Write down any job that has two active plugins.
3. Write down every inactive plugin and ask whether anyone needs it.
4. Mark the overlaps by how much damage they could do. A doubled page cache or a doubled firewall is worse than a doubled redirect plugin.
5. Pick one overlap. Test it on staging, not on the live site.

If you test on staging, the staging drift post is about what drifts between staging and live, which matters before you trust a test result.

The playbook applies the same table to every site you point it at, which is the real gain on a client portfolio. On a single site you own, the manual version is fine.

What An Overlap Check Does Not Solve

An overlap report is useful because it is narrow. Here is what it will not do.

• It does not find conflicts between unrelated plugins. Plugins in different jobs can still collide, and the check cannot see it.
• It does not read error logs. Logs are where a real error would show. A related post covers the debug log exposed check.
• It does not judge plugins that are not in its table. They are listed as not assessed, and a re-run gives the same result, because the table is fixed.
• It does not read plugin settings. Two caching plugins with caching switched off in one of them would still be reported as an overlap.
• It does not see must-use plugins. The report says so under “Not checked”.
• It does not fix anything. Fixing an overlap is the site owner’s decision, made on staging first.

That last point is also a safety property. A tool that only reads and reports cannot break a site.

If You Already Have A Real Conflict

Then you need a test, not a report.

WordPress has a supported way to run one. The Health Check and Troubleshooting plugin on WordPress.org describes a troubleshooting mode: a clean session where all plugins are disabled and a default theme is used, but only for your own user until you turn it off or log out. Everyone else keeps seeing the normal site. That is a safer way to answer the question “is it a plugin?” on a live site, because it does not change what the public sees.

The Learn WordPress lesson also starts the same way every careful guide does. Make a backup before changing anything, and use a staging site if you have one. If the broken thing is an update you just ran, the update process playbook post is a related read.

When the cause is a plugin that has stopped receiving updates, the story is different: the premium plugin licenses post and the removed plugin risk post cover two ways a plugin can drift out of support without anything visibly breaking.

Two Outside Views

A tutorial and a forum thread. Neither is an endorsement, and neither describes the Protuno playbook.

In a March 2026 video, Ephraim Creations works through a site that kept crashing and shows the manual route most people take. He switches every plugin off at once by renaming the plugins folder in the host’s file manager, confirms the dashboard loads, renames the folder back so the plugins return in a deactivated state, and then turns them on one at a time until the site breaks again. The video ends with a plug for his own WordPress course.

On Reddit, an r/Wordpress thread titled “How do you figure out which plugin is causing a conflict when your site breaks?” starts with someone describing the manual method and what it costs:

u201cThe only way I could figure out to diagnose it was the classic “deactivate all plugins, reactivate one at a time, keep reloading the broken page.”u201d

Original poster, r/Wordpress, 16 April 2026

An early reply pushes back on that approach:

u201cWP_DEBUG, DevTools, server logs. Randomly deactivating plugins and hoping something happens is not how you troubleshoot issues.u201d

Reply in the same thread, r/Wordpress, 16 April 2026

The original poster answers that logs gave only generic JavaScript failures with no stack trace pointing at a plugin, and that bisecting never isolates the case where two plugins only break when both are active. That is exactly the situation where a list of overlaps gives you somewhere to start.

Where Protuno Fits

The Plugin Conflict & Redundancy Check playbook is the narrow, repeatable part of this problem. It sorts the plugin list into jobs, reports the overlaps, the stacked add-ons and the inactive plugins, and says what to test first on staging. It only reads.

It sits beside the other checks. A related post on the vulnerability scanner is about installed plugins and known problems, which is a different question from whether two of them overlap. The playbooks page lists the playbooks as Protuno publishes them, and this one has its own page at Plugin Conflict & Redundancy Check.

The Point

A plugin list cannot prove a conflict. It can tell you where to look first.

Read the overlaps by severity, test one on staging, and treat a quiet report as a good result. The next time a site shows that critical error, you will already know which pairs of plugins were worth suspecting.

Which job has two active plugins on the site you manage right now?

Sources And Further Reading

• Troubleshooting your site: Plugin and theme conflicts, Learn WordPress
• Health Check & Troubleshooting, WordPress.org plugin directory
• Debugging in WordPress, WordPress developer documentation
• WordPress 7.1.3 Maintenance and Security Release, WordPress.org News, 6 October 2026
• Fix WordPress Errors Fast | Plugin Conflict Debugging (2026), Ephraim Creations, YouTube, 17 March 2026
• How do you figure out which plugin is causing a conflict when your site breaks?, r/Wordpress, 16 April 2026
• Plugin Conflict & Redundancy Check, Protuno playbook page

Your company changed its name. Your site did not hear about it.

The old name is in a hundred places: titles, excerpts, old announcements, a footer line you wrote years ago. Finding them is easy. Changing them safely is where the trouble starts.

Short answer: a find and replace is safe when it only touches plain text, shows you every change as before and after, and refuses to touch anything it cannot read in full. A phrase can also sit inside a link, a block setting or a shortcode, and changing it there can break the thing it belongs to. Protuno’s Find & Replace Text playbook works in two steps: one read-only step that plans, then one write step that waits for your approval and reads every change back.

What this post is, and is not: it is a practical walkthrough of how a Protuno playbook works and how to do the same job by hand. It is not a measured result from a real site, and it does not promise that every occurrence of a phrase on your site will be found. It explains what the playbook reads, what it changes, and what it deliberately leaves for a person.

A phrase in a paragraph is text. A phrase in a link is part of the link.

Why Search And Replace Goes Wrong

The usual tool for this job is a search and replace plugin or a command. They are powerful, and that is the problem. A database-wide replace sees one big pile of text. It does not know that one match is a sentence and another match is the address of a page.

Think about a rename from “Acme Studio” to “Acme Labs”. In a paragraph, the swap is exactly what you want. In a link address such as a URL that contains the old name, the same swap points the link at a page that does not exist. In a block comment that stores a setting, it can change a value the block expects to read back unchanged.

Nothing warns you. The page still loads. The damage shows up later as a dead link or a block that quietly resets itself.

A bulk replace is exactly the moment you want a verified backup. And scope matters too: a replace that runs everywhere also runs on menus, options and page builder data you never meant to touch.

Four Ways To Change Text Across A Site

There are four common ways to change a phrase everywhere. Each one answers a different question.

View	What it tells you	What it cannot prove alone
The WordPress search box in the Posts list	Which posts mention the phrase	Where in the post it sits, or whether it is inside a link
A database search and replace plugin	Every matching string in the tables you pick	Whether a match was text, markup or a stored setting
WP-CLI search-replace	A fast, scriptable replace, with a dry run you can ask for	Which matches a person should have judged first
A scoped, approval-gated playbook	A before and after plan for plain text in posts and pages	Anything outside posts and pages, which it leaves alone by design

None of these is wrong. The WP-CLI search-replace command is well documented, and a plugin such as Better Search Replace is popular for a reason. The mistake is treating a tool that can change everything as if it were a tool that should.

What The Playbook Looks At

Find & Replace Text is a Protuno playbook on the Care side of the public Playbooks page. In the dashboard’s Every Playbook list it sits in the Content group. It is marked Beta, it can change the site, and it has 2 steps. It needs no connector. It reads through the Protuno plugin.

It works on one phrase that you choose, and it works as plain text. The scope is narrow on purpose:

• Titles, excerpts and content of posts and pages.
• Every exact match of your phrase.
• Whether a match also sits inside block markup, an HTML tag or attribute, a shortcode or a link address.

It never changes post meta, options, menus, widgets or page builder data. It changes at most 10 items per run, and a post that is too long to read in full is not changed at all.

You set the phrase in the playbook’s Instructions, one option per line:

Find: Acme Studio
Replace with: Acme Labs
Post types: post, page
Fields: title, excerpt, content

Only Find: and Replace with: are required. The phrase must be at least 4 characters. Replace with: may be empty, which removes the phrase. Post types and fields are optional, and by default the playbook uses both post types and all three fields. Matching is case sensitive and exact, so “acme studio” is a different string from “Acme Studio”. If either required line is missing, the playbook makes no changes and tells you which line to add.

The Playbook, Step By Step

Find & Replace Text is a Protuno playbook with a fixed sequence of two steps. The first step only reads the site. The second changes it, and only after you approve.

#	Step	What it does
1	Scan And Snapshot Matches	Finds your phrase in posts and pages, plans each change as before and after, and records when each item was last modified. It writes nothing.
2	Apply And Verify	After you approve, replaces the phrase in each approved item, skips any item that changed since the scan, and reads each one back to confirm.

Step 1 is read-only. The dashboard shows its Approval checkpoint as Off and its Automatic backup as None, which fits a step that writes nothing. Step 2 has the Approval checkpoint On: the run waits for your approval. Its Automatic backup also shows None, so the safety net here is the approval, the item-level before and after plan, and the recorded before-values, not a site snapshot.

Order matters here. The plan comes before the change, and the approval sits between them. If the order were reversed, you would be approving a result after the fact.

Step 1 does three things worth knowing:

1. It searches posts and pages, including drafts, pending, private and scheduled items, and keeps the first 10 matches in ID order. Anything beyond that is reported as over this run’s limit.
2. It reads each item in full. If the reply is cut short, or the content is longer than 6,000 characters, the item is reported as not checked because it is too long to read in full. A change is never planned from a partial read.
3. It sorts every item into change, review by hand, or no change.

An item goes into review by hand when the phrase also appears inside block markup, a tag or attribute, a shortcode or a link address. Even one such occurrence in any field is enough. Protuno lists it for you to fix yourself rather than guess.

Step 2 is careful in a different way. It records when each item was last modified during the scan. Before it writes, it re-reads the item and compares. If the item was edited in the meantime, it skips it with the reason “changed since the scan”. If the phrase now sits inside markup or a link, or has gone, it skips that too.

Then it writes only the fields that held the phrase, through Protuno’s content update route, which records each changed field’s before-value. After the write it reads the item back. An item counts as changed only when each written field no longer contains the phrase and contains the replacement as many times as the phrase appeared before.

Watch The Walkthrough

The video below follows the two steps in order, from the instruction lines to the plan, the approval and the read-back. It is an illustration built from the playbook’s step names and described behaviour. It shows no real site and no measured result.

What Find And Replace Does Not Solve

A scoped replace is safe because it is narrow. That also means it leaves things alone.

• It does not change post meta, options, menus, widgets or page builder data. If your old name lives in a menu label or a builder template, you fix it there.
• It does not change an item where the phrase also sits in a link, block settings or a shortcode. Those go on the review by hand list.
• It does not handle more than 10 items per run. A site with hundreds of matches needs several runs.
• It does not read posts that are too long to read in full, and it says so.
• In a scheduled run, step 2 is skipped, so a scheduled run never makes the change. A person starts the run and approves it.

A tool that says what it did not cover is more useful than one that reports a clean sweep. The same thinking sits behind the permission model for agents: the smaller the reach, the easier it is to trust.

Questions To Ask Your Current Tooling

Whatever you use for bulk text changes, ask it these:

• Does it show me every change as before and after, before anything is written?
• Does it tell me when a match sits inside a link or a setting, or does it replace it anyway?
• Can it limit itself to titles, excerpts and content, or does it search the whole database?
• What happens if someone edits a post between the preview and the write?
• Is the before-value of every changed field recorded, so I can undo it?
• Does it read the result back, or does it assume the write worked?

If the answer to most of these is “I am not sure”, you are relying on luck, and a rollback plan is worth having before the next bulk change.

Which Check Are You Actually Running?

If you need to know	Evidence to look at	Next action
Which posts mention the phrase	Search results from the Posts list	Open the posts that matter and read them
Whether a match is plain text	The post in the code editor, or the plan from step 1	Change plain text, review the rest by hand
Whether the change landed	A read-back of each written field	Confirm the count of replacements matches the count of matches
Whether you can undo it	Recorded before-values for each changed field	Use Rollback on the run in the app

Rollback is part of the design. Every change the playbook makes is recorded with its before-value, field by field, and Roll back in the app undoes the changes it made.

Fixing Findings In The Right Order

When the plan comes back, do not treat every line the same way.

Priority	What to do
First	Read the review by hand list. These are the matches the playbook refused to change, and they are where a blind replace would have caused damage.
Second	Read the before and after snippets for the items marked to change. Look for a replacement that reads oddly in context.
Third	Check the not checked list. Long posts need a manual pass.
Last	Approve the run once the plan reads the way you want.

Two rules help:

1. Have a restore point first. Step 2 shows no automatic backup, so take your own before approving anything on a site you care about.
2. Re-check after the change. Open two or three changed pages and a page from the review by hand list. Read them as a visitor would.

A Five-Site Audit You Can Do This Week

You do not need the playbook to test your own process. Pick five sites you look after and, for each one, write down:

• The phrase that changed most recently, such as a brand name, a product name or a price label.
• How many posts and pages mention it, from the Posts list search.
• How many of those mentions are inside a link or a shortcode.
• Whether the site has a restore point you could use today.
• Who would approve a bulk change, and where that approval is written down.

Then decide, for each site, one of these:

• Fix now: the matches are plain text and a restore point exists.
• Test first: copy the site to staging and try the replace there. See staging drift for why staging and live can disagree.
• Replace by hand: the matches sit inside links or settings.
• Leave it: the old phrase is harmless, and you note who decided and when.
• Investigate: matches show up in places you did not expect, such as old drafts.

Why Old Text Quietly Comes Back

A bulk replace is a one-time event, but old wording finds ways back in: a teammate pastes from an old document, or a reusable block still holds the old name. That is why the playbook reports what it left alone. If you want to keep content tidy in other ways, the Disable Comments playbook and the image alt text audit follow the same read first, change second pattern, and the broken link audit is a useful follow-up after any large text change.

Two Outside Views

A tutorial and a forum thread. Neither is an endorsement.

Extreme How To’s video walks through a plugin route: install Better Search Replace, type the text or URL to find and the replacement, pick the wp_posts table, run a test, then run the replace. The test step is the part worth copying. It is also where the plugin route stops: the plugin counts matches in a table, and it does not say which ones are plain text and which sit inside a link or a block.

A short tutorial on finding and replacing a URL or text in WordPress with a search and replace plugin, including a dry run before the real change.

Extreme How To’s, “How to find and replace URL or text WordPress [2026 Full Guide]” on YouTube, 14 Aug 2026

On Reddit, an r/Wordpress thread is titled as a migration that still cannot update every reference to a local address. I could not read the replies, so this post does not summarise them. The title alone shows the shape of the problem: after a move, old addresses survive in places a simple text search does not reach, which is why a replace needs a plan before it needs a button.

“Migrating from Studio still can’t update all references to local”

r/Wordpress, “Migrating from Studio still can’t update all references to local”

Where Protuno Fits

Protuno’s Super Agents page describes the Care agent, Wren, as the one that runs updates behind a restore point and watches the jobs that quietly stop. This playbook is one of the Care playbooks that can change a site, so it asks first.

The pattern is the same every time. Protuno plans the change, shows it to you, waits for you, then writes only what you approved and reads it back. You can see every step written out on the Playbooks page and meet the agents on the Agents page.

The fields it works with, title, excerpt and content, are the same ones the WordPress REST API reference for posts documents.

Sources And Further Reading

• wp search-replace: the WP-CLI command reference, including the dry run option.
• Better Search Replace: the plugin on WordPress.org.
• Posts REST API reference: the post fields the playbook works with.
• How to find and replace URL or text WordPress [2026 Full Guide]: Extreme How To’s on YouTube, 14 August 2026.
• Migrating from Studio still can’t update all references to local: an r/Wordpress thread.

The Point

A find and replace should be boring. You pick a phrase, you see what will change, you approve it, and you check that it worked.

The risk was never the swap. It was the swap in the wrong place.

So when you last changed a phrase across a site, did you know which matches were text and which were part of something else?

You switched comments off. Your site still takes them.

That is the quiet trap in WordPress. One checkbox sounds like a site-wide switch, and it is not one. If you want to disable comments WordPress-wide, that single setting is not enough.

Short answer: the Settings > Discussion checkbox only sets the default for posts you write from now on. Every older post, page and media item keeps its own comment and ping setting. To really close comments, you need to close the defaults and the existing items, and keep the comments you already have untouched. Protuno’s Disable Comments playbook does exactly that in two steps: one read-only step that plans, then one write step that waits for your approval.

What this post is, and is not: it is a practical walkthrough of how a Protuno playbook works and how to do the same check by hand. It is not a measured result from a real site, and it does not promise that a closed item will never receive a spam attempt. It explains what the playbook reads, what it changes, and what it refuses to touch.

A setting is a default. An item is a fact.

Why The Settings Checkbox Falls Short

Open Settings > Discussion in WordPress and you will find the box that says people can post comments on new posts. WordPress’s own documentation words it carefully: it is the setting for new articles, and individual articles can override it.

That wording matters. The box is a template that gets copied onto each new post at creation time. Posts that already exist are not rewritten when you change the template.

So a site that turned comments off two years ago can still have a hundred older posts with comments open. Spam bots do not care which setting you changed last. If you have ever had to clear a flood of junk, you have met the result. We covered the cleanup side in WordPress Spam Comments: The Playbook, Step By Step. This post is about closing the door instead of mopping the floor.

There is a second, easier-to-miss setting. Comments and pings are separate switches. A post can have comments closed and still accept pings, the link notifications other sites send. WordPress’s documentation lists them as two different options. Pings are the same family of traffic as xmlrpc.php, so closing comments but leaving pings open leaves half the door ajar.

Four Ways To Look At The Same Problem

There are four common ways people turn comments off. Each one answers a different question.

View	What it tells you	What it cannot prove alone
Settings > Discussion default	New posts will start with comments closed	Whether any existing post is still open
Bulk edit in the Posts list	The posts you selected are now closed	Pages, media items, and posts you did not select
A plugin that removes comments sitewide	The comment feature is hidden or blocked in the site	Whether the stored setting on each item changed, and how you undo it
Auto-close after a number of days	Old posts close on a schedule	Posts newer than the cut-off, and pages and media

None of these is wrong. They answer different questions, and the mistake is treating the first one as if it answered all of them.

The part people forget is media. WordPress can keep a comment status on attachment pages too, so an old image can be a place where comments are open even when no post looks open. A hand check that only looks at the Posts screen never sees it.

What The Playbook Looks At

Disable Comments is a Protuno playbook in the Content group of the Every Playbook list. It is marked Beta and shown as Can Write, with 2 steps. You will find it in the dashboard’s Every Playbook list, not on the public playbooks page.

It is built around one rule that is worth reading twice. The playbook only closes comments and pings. It changes two Discussion defaults, and each item’s comment status and ping status. It never deletes, approves, unapproves or edits a comment, and it never touches any other field.

That scope is the reason it is safe to describe. A tool that can “manage comments” is a broad promise. A tool that can only flip two switches on a list you approved is a small one.

The Playbook, Step By Step

Disable Comments is a Protuno Content playbook with a fixed sequence of two steps. The first only reads the site. The second changes it, and only after you approve.

#	Step	What it does
1	Comments Baseline And Snapshot	Reads the two Discussion defaults, counts open and closed posts, pages and media, counts existing comments, and plans up to 25 items to close. Writes nothing.
2	Apply Comment Closures	After approval, closes the defaults and the planned items, reads every change back, and checks that the comment count has not changed.

Here is how each step works, based on the step instructions shown in the dashboard.

Step 1: Comments Baseline And Snapshot

This step is 100 percent read-only. It begins with the before-values: whether new posts accept comments, and whether they accept pings.

Then it reads posts, pages and media, newest first, 100 per page, asking only for the id and the two status fields. Drafts, private, pending and scheduled posts are included, not just published ones. The instructions cap the read at 5 pages per type.

An item counts as open when its comment status is open, or its ping status is open. The instructions call out one case by name: pings open with comments closed is still open. WordPress’s default “Sample Page” is often exactly like that.

It also counts existing comments, page by page, and writes down the number. That count is the control for step 2.

Finally it builds the close list: open items in the order posts, then pages, then media, newest first, at most 25. Each item’s current values are written beside it, so the change can be undone later. The step ends with a plan block that step 2 reads, and nothing else.

Step 2: Apply Comment Closures

The dashboard shows this step with an approval checkpoint turned on, which means the run waits for you. Step 1 has no checkpoint because it only reads.

After you approve, the step does the following, in this order:

1. If either default is open, it closes both defaults. Nothing else is sent in that settings call.
2. It re-checks the planned items. An item that is already closed or missing is skipped, not rewritten.
3. It closes each remaining item, changing only the comment status and the ping status. Each item’s previous values are recorded.
4. It reads everything back. An item only counts as closed when the read-back shows both comments and pings closed.
5. It counts comments again and compares with step 1. The count must match, or the step fails.

The order is the point. The re-check protects against a plan that went stale while you were reading it. The read-back protects against a write that quietly did not stick. The comment recount is the proof that nothing was deleted along the way.

The report ends with three honest tables: the defaults with before and after values, the items closed, and anything skipped or failed. It says plainly that the Discussion defaults are not covered by rollback, so it tells you the before-values to set them back by hand. The items are covered by rollback, and the report says so.

The clip above is an illustration of the two steps and their order, built from the playbook’s real step names. It is not a recording of a run and it shows no results.

What Disable Comments Does Not Solve

A two-switch playbook has edges. Here they are, so nobody is surprised.

• It does not delete or moderate comments. Existing comments stay as they are. If you want spam cleared, that is a different job, covered in WordPress Spam Comments.
• It closes up to 25 items per run. A site with a few hundred open items needs several runs. The plan says how many remain open after each one.
• It reads a limited window. Step 1 reads at most 5 pages of 100 per type, newest first. On a very large site, treat the first runs as a start, not a full census.
• It does not remove the comment form from your theme. A closed item stops accepting new comments. How your theme displays a closed notice is a theme matter.
• It does not stop spam signups or other abuse. If bots register accounts, that lives elsewhere. See WordPress User Roles for the access side.
• The defaults are not rolled back by Rollback. Only the item changes are. The report gives you the before-values.
• It has no automatic backup of its own. The dashboard shows Automatic backup as None for both steps. The safety net is the recorded before-values and Rollback for items. Take your own restore point first if the site matters.

A Small Test You Can Run Today

You do not need Protuno to see the problem. WordPress exposes each public post’s comment and ping status in its REST API. Try this on your own site:

# Replace example.com with your domain
curl -s "https://example.com/wp-json/wp/v2/posts?per_page=100&_fields=id,comment_status,ping_status"
curl -s "https://example.com/wp-json/wp/v2/pages?per_page=100&_fields=id,comment_status,ping_status"
curl -s "https://example.com/wp-json/wp/v2/media?per_page=100&_fields=id,comment_status,ping_status"

Write down, for each type:

• how many items returned "comment_status":"open"
• how many returned "ping_status":"open" with comments closed
• how many are closed on both

Then compare with Settings > Discussion. If the setting says closed and your list still shows open items, you have just seen the gap this playbook exists for.

Three cautions. This only sees what the public API shows, so private and draft items are missing from it. Each call returns at most 100 items, so if you get exactly 100 back, there are more. And counting open items tells you what exists, not whether anyone is using it.

Questions To Ask Your Current Tooling

If you already use a plugin or a bulk action to turn comments off, ask it plainly:

• Does it change the stored setting on each existing item, or only hide the form?
• Does it cover pages and media, or only posts?
• Does it close pings as well as comments?
• Can you see the before-values, and can you undo item changes?
• Does it prove that your existing comments are untouched afterwards?
• Does it wait for you before it writes?

A good answer to the last two matters most. A write that cannot be undone and cannot show what it did is the kind of write you should not run on a client site.

Which Check Are You Actually Running?

If you need to know	Evidence	Next action
Will new posts accept comments?	Settings > Discussion	Close the default
Are existing posts open?	Each item’s comment status	Close items, with a way back
Are pings still open?	Each item’s ping status	Close pings with comments
Did anything get deleted?	Comment count before and after	Compare the two numbers
Did the change actually stick?	A read-back after the write	Only trust the read-back

Fixing Findings In The Right Order

If your check finds open items, here is a sensible order.

Priority	Finding	Why
1	Open defaults	Every new post inherits them, so the problem grows
2	Open posts with the most traffic	They are the likeliest spam targets
3	Pages that accept comments	Often forgotten, rarely meant to be open
4	Media items with comments open	Invisible from the Posts screen
5	Pings open with comments closed	Same family of traffic, easy to miss

Two practical rules apply whatever tool you use:

1. Take a restore point first. The playbook records before-values, but a backup of the database is still the cleanest way back. See WordPress Rollback After An Update for what a rollback can and cannot undo.
2. Re-check after the change. Run the same count again and compare. If the numbers did not move, the write did not land.

A Five-Site Audit You Can Do This Week

Pick five sites you look after. For each one, record:

• the Discussion default for comments and for pings
• the count of open posts, pages and media
• the count of existing comments
• whether comments are actually wanted on this site

Then decide for each site:

• Fix now: comments are not wanted and items are open.
• Test first: comments are used on some posts, so list which and close only the rest.
• Replace: a plugin hides the form but items stay open underneath.
• Remove: a comment plugin you no longer need.
• Accept with owner and date: comments stay open on purpose, with a named person and a review date.
• Investigate: the numbers do not match what the owner expects.

The decision that is easy to skip is the last one. “Open on purpose, owned by someone, reviewed on a date” is a perfectly good answer. “Open because nobody noticed” is not.

Why Comment Settings Go Stale

Comment settings drift for ordinary reasons. A new plugin imports old posts with comments open. A theme change adds a feature that re-enables them. A migration copies content but not the default. A team member publishes a page from a template that was built years ago.

None of it is dramatic. It is just that a setting you checked in March says nothing about the post you published in June.

That is why it helps to treat this as a check you repeat, not a task you finish. The Settings screen answers one question once. The items answer it again every time something new is created.

Two outside references show how this looks in practice. A YouTube tutorial covers turning off comments on WordPress posts, and an r/Wordpress thread asks whether comments should stay in core at all.

A short tutorial on turning off comments on WordPress posts.

Entrepreneurs Skool, “Disable Comments On WordPress Posts” on YouTube, 28 Aug 2026

“There is no single “turn off comments” switch. It’s a dance of around 7 setting hooks, last time I checked.”

r/Wordpress, “Move Comments to a plugin in 8.0”, September 2026

The video title promises an easy fix. The Reddit reply explains why that is only half true: the setting is spread across several places, which is the gap the two steps above are built to cover.

Where Protuno Fits

Protuno is a set of Super Agents for WordPress, each running playbooks against your connected sites. Disable Comments is one of the playbooks in the Content group, available in the dashboard. Other playbooks are listed at protuno.com/playbooks, and the agents are at protuno.com/agents.

This one changes the site, so it needs the Protuno plugin connected. It plans first, you approve, and it writes only the two comment fields. A human decides every change, and the playbook reports what it did in plain tables.

If you also care about the other side of tidy access, see WordPress Security Audit for the wider read-only picture.

The Point

Closing comments is not one click. It is a default, a list of items, and a proof that nothing was deleted.

The only honest report is the one that shows the before, the after, and a read-back in between.

When did you last count how many of your old posts still take comments?

A lapsed license does not break a site.

It does something quieter: it stops the updates.

Short answer: A premium plugin keeps running after its license ends, but WordPress plugin updates from the vendor, including security fixes, can stop arriving. To find out where you stand, list every installed plugin, work out where each one gets its updates from, read the license record each vendor’s system left on the site, and sort every plugin into a clear state. When a state cannot be read, call it unknown. Never call it fine. That is the order the Premium License Expiry playbook in the Protuno dashboard follows, and it is a check you can run by hand.

What this post is, and is not: A practical way to find out which premium plugins on a site have lost their update feed, and how to word what you find. It is not a ranking claim, not legal advice about licensing, and not a result from a real run: no playbook was run for this post, and every visual is a labelled illustration. The step names and rules come from the playbook as the Protuno dashboard shows it. The playbook is Beta and read only.

Free plugins from the WordPress directory update from one place. Paid plugins update from many.

Why A Lapsed License Is Easy To Miss

Nothing visible happens on the day a license expires. The plugin still loads. The pages still render. The client sees no difference.

What changes is the supply. A WooCommerce.com subscription, for example, is described by WooCommerce as giving you access to product updates and support for the duration it covers, billed annually or every two years. When that period ends without a renewal, the entitlement goes with it.

Freemius describes licenses in similar terms: they control access to premium features based on the plan, the billing cycle and the number of allowed activations. Easy Digital Downloads Software Licensing works through its own license records too. Each vendor keeps a different record, in a different place, in a different shape.

That is the real problem. There is no single license screen for a WordPress site. There is one screen per vendor, and nobody opens six of them on a Tuesday.

The risk is not the expiry itself. It is the length of time between a security fix being published and anyone noticing the plugin never received it. WordPress 7.1.3, a security release with 7 security fixes, came out on 6 October 2026. Core has its own update path. A premium plugin with a lapsed license may get nothing from its vendor.

Three Places A Plugin Gets Its Updates

Source	How the site learns about updates	What a lapse looks like
The WordPress directory	Core checks the directory and records what it finds	Not a license issue. A plugin pulled from the directory is a different problem
The vendor’s own updater	The plugin asks the vendor’s server, using a license key	The key stops working. The plugin runs, and the update offer disappears or fails
No updater at all	Nothing feeds it	The plugin was installed from a zip and never checks for anything

The third row is the dangerous one, because it looks exactly like a healthy site. A plugin that has no updater does not show an error. It just never shows an update.

A Small Test You Can Run Today

Open the plugin list on one site. For each plugin you did not get from the WordPress directory, write down:

• The plugin name and version.
• Whether it is active.
• Which company sells it, and where you log in to see its license.
• The expiry date that account shows, or “no account found”.
• Whether the Updates screen has ever offered an update for it.

Then ask one blunt question of every row: if this vendor published a security fix this morning, would this site hear about it?

A rough way to see what WordPress itself knows about a site’s plugins, from a terminal with WP-CLI:

wp plugin list --fields=name,version,status,update

The update column shows what the site currently believes. It cannot tell you why a plugin shows nothing. A blank can mean up to date, or it can mean nothing is checking. That ambiguity is the whole point of this post.

The Playbook, Step By Step

Premium License Expiry is a Protuno Maintenance playbook. In the Protuno dashboard it carries a Beta label, is read only and runs seven steps, plus a Brief and Schedule screen. The public playbooks page lists a playbook with the same job under the shorter name License Expiry, described as warning before a paid plugin stops receiving security updates, and shows four steps. This post follows the dashboard’s names and seven steps. Check which version your account shows.

#	Step	What it does
1	Enumerate Plugins And Update Sources	Makes one read-only call that lists every installed plugin with its name, version, active state and update source. A plugin that is installed but absent from the update records has no updater feeding it. It stops if the core plugin and update records cannot be read
2	Scan EDD Licenses	Reports the cached Easy Digital Downloads license records that really exist in the site’s options: a prefix, a status, an expiry and whether a key is present. No records is a normal, clean result. It never prints a key
3	Scan Freemius Licenses	Reports the cached Freemius license state: module, plan, expiry date, and whether it is lifetime or expired. A lifetime license is never reported as expired
4	Scan WooCommerce Subscriptions	Reports whether the site is connected to WooCommerce.com, and for each subscription its product, expiry date, and whether it is active, expiring or expired
5	Classify Each Plugin	Gives every plugin one class, with a confidence level and the evidence behind it
6	Optional Live License Recheck	Makes no remote call. It needs an approval that a playbook has no interactive step for, and a vendor store address that standard WordPress options do not store. It will not guess one
7	License Expiry Report	Turns the classes into one report with a status of ok, warn or stopped, headlining the dangerous states first

The order is the safety. Nothing is written at any step, and nothing is called healthy because it was not found broken.

Seven Classes, And What Each One Means

Class	Plain meaning
valid	A license record was read and it is current
expiring-soon	A record was read and the expiry is close
expired-still-running	The license has ended, the plugin is still active. Updates are off, but the plugin works
lapsed	The license has ended in a way the record marks as lapsed
lifetime	A record was read and it has no expiry
nulled-suspect	A signal that may point to an unlicensed or tampered copy. Worded as “possible unlicensed or nulled copy (confidence: low, medium or high), needs verification”
unknown	The state could not be determined

Two of these deserve a pause.

unknown is the honest class. The playbook’s rule is that an ambiguous or absent status is unknown, never valid, and that a vague match is never asserted as valid. A plugin the system cannot read gets reported as “unknown (not determined)”. It does not get the word fine.

nulled-suspect is the class that can do harm if it is worded carelessly. A weak signal, for example a name with “Pro” in it and no entry in the update records, is not evidence of anything. Many paid plugins never appear in those records until their own updater has run. So every nulled-suspect line carries a confidence level, and a low-confidence line is a prompt to verify, never an accusation.

What The Report Treats As Urgent

Finding	Confidence	How it is treated
expired-still-running	High, because a license status was actually read	Headline. The plugin works, but security updates are off
lapsed or expiring-soon	Read from a record	Warning
nulled-suspect	Medium or high	Warning, worded as a possible unlicensed copy that needs verification
nulled-suspect	Low	Listed under “Needs verification”. Never urgent
unknown	Not determined	Reported as unknown. Does not change the status

For a low-confidence line, the advice is deliberately mild: open the plugin’s own license or settings page and confirm the license is active. If it is, there is nothing to do. The report does not tell you to remove, replace or switch a plugin on a weak signal.

The status follows the same logic. The report is warn when any plugin is expired-still-running, lapsed or expiring-soon, or when a nulled-suspect has medium or high confidence. Low-confidence rows alone leave the status at ok, because otherwise every site whose connector plugin updates itself would be flagged.

What A License Check Does Not Solve

• Whether the plugin is any good. A valid license on an abandoned plugin is still an abandoned plugin. Our post on what a removed plugin leaves behind covers that side.
• Whether a plugin has a known vulnerability. A license is about the update supply. Matching installed versions against vulnerability data is a different check, covered in vulnerability monitoring.
• Vendor records the site does not keep. The playbook reads cached records on the site for Easy Digital Downloads, Freemius and WooCommerce.com. A vendor with its own system, or an account that only lives on the vendor’s server, is not covered by those steps.
• A live answer from the vendor. Step 6 makes no remote call. What you get is what the site last recorded, not today’s answer from the vendor’s server.
• Renewals. It reports. It never renews, updates or changes a license.
• Sites that cannot run PHP. If the check cannot read the site’s own records, it says so and stops. It does not infer a license state from anything else.

Which Check Are You Actually Running?

If you need to know	The evidence	Next action
Whether a paid plugin is still being updated	The update source and the license record, side by side	Renew, or plan a replacement
Whether an installed plugin has a known security hole	Version against vulnerability data	Read the vulnerability monitoring approach
Whether an update is safe to apply	A backup, a test and a rollback path	See how a safe update playbook is written down
Whether the license cost belongs in the care plan	The number of paid plugins and their renewal dates	See care plan economics

A Five-Plugin Audit You Can Do This Week

Pick five premium plugins across your busiest client sites. For each, record:

1. The vendor and the account that owns the license. Is it your account, the client’s, or a former developer’s?
2. The expiry date, or “not found”.
3. The date of the last update the site actually received.
4. Whether the plugin is active and whether anything depends on it.
5. Who gets the renewal email, and whether that address still works.

Then pick one outcome per plugin: renew now, move the license to the right owner, replace the plugin, leave it with a dated note, or confirm the license state with the vendor.

The fifth question is the one that bites. A renewal notice that goes to a former contractor’s inbox is how a license lapses without anyone deciding to let it. Writing the owner and the renewal date into the maintenance contract is a small change that closes it.

If A License Has Already Lapsed

Do these in order:

1. Take a backup, and make sure it restores.
2. Check whether the vendor has published updates since the license ended.
3. Renew, or schedule the plugin’s replacement.
4. After renewing, re-read the Updates screen and confirm the offer comes back.
5. Test the update on a copy before applying it live.

If an update goes wrong, a clear undo is what matters. Our post on what an automatic rollback really reverses is a good test of any undo claim. If you suspect a plugin has already been used against the site, start with the first hour after a hack and ignore this post.

Two Outside Views

A tutorial and a forum thread. Neither is an endorsement.

Presslyte’s tutorial on updating WordPress plugins safely walks through a five-step routine: back up, review, update one plugin, check the site and repeat. It also says that if the update source or support status is unclear, you should stop and verify it before going on.

A beginner tutorial on updating WordPress plugins safely: back up, review, update one plugin, check the site and repeat.

Presslyte, “How to Update WordPress Plugins Safely” on YouTube, 2 Sep 2026

On Reddit, an r/Wordpress thread asks whether people wait for Black Friday to buy yearly plugin licenses, and the replies talk about monthly versus annual plans, lifetime deals and whether a first-year discount is worth it. It is a useful reminder that every yearly license is also a renewal date someone has to own.

“A lot of plugin vendors discount only the first term, and year two renews at full price.”

r/Wordpress, “Are you waiting for BlackFriday/CyberMonday with plugin purchases?”, September 2026

Where Protuno Fits

In the Protuno dashboard, Premium License Expiry sits with the Care playbooks. It is a Beta playbook that only reads, so it does not change a plugin, renew a license or print a key. It needs the Protuno plugin on the site first, and on the one connected site in the dashboard it is not switched on, so there is no run to show here.

It does not decide whether to renew, and it does not replace asking the vendor. If a site is behind on core, update it first: WordPress 7.1.3, a security and maintenance release, came out on 6 October 2026.

Sources And Further Reading

• Managing WooCommerce.com Subscriptions: WooCommerce’s guide to what a subscription includes, connecting a site through the Update Manager, and renewal.
• Freemius Developer Documentation: Licenses: how Freemius describes licenses, renewals and activations.
• get_plugins() reference: the WordPress function that reads the installed plugins and their plugin data.
• WordPress 7.1.3 Maintenance And Security Release: the 6 October 2026 release.
• How to Update WordPress Plugins Safely: Presslyte on YouTube, 2 September 2026.
• Are you waiting for BlackFriday/CyberMonday with plugin purchases?: an r/Wordpress thread.

The Point

A lapsed license does not announce itself. The plugin keeps working, and the updates stop.

List every plugin, find where each one gets its updates, read the license records, and write unknown when you cannot tell.

Which premium plugin on your busiest site has no renewal date written down anywhere?

The update passed on staging. You pushed it to live. Live broke.

Nobody did anything wrong in the update itself. The test was honest. It was just run against a site that had quietly stopped being a copy of the one that matters.

That gap has a name worth using with clients: drift. A WordPress staging site and its live twin start identical on the day the clone is made, and then they separate, one small change at a time, until the test tells you about a site that no longer exists.

Short answer: a staging site is only as useful as the distance between it and live, and that distance is measurable. Before you trust a staging test, compare six things: plugin and theme versions, database content, settings rows, the search engine visibility flag, cron, and the caching and CDN layer. If any of them differ in a way that touches the change you are testing, the test proved less than you think.

What this post is, and is not: this is a comparison routine you can run yourself on two sites you control, from outside and from inside. It is not a claim that a matched staging site makes an update safe, and it is not a review of any specific host’s staging feature. Hosts implement staging differently, so confirm how your own host’s push behaves before you rely on it.

Why A Matching Staging Site Stops Matching

Nobody decides to let staging drift. It happens because the two sites are used by different people for different reasons.

Live gets content. Orders, posts, form entries, new users, a plugin the client installed after seeing it recommended somewhere. Staging gets experiments. A theme tweak nobody reverted, a plugin activated to test one thing six weeks ago, a constant added to wp-config.php during a debugging session.

Both sites are being maintained honestly. They are just being maintained in different directions.

The failure this produces is specific and it is the worst kind: a false pass. A failed staging test is useful, because you learn something before the client does. A passed staging test on a drifted site teaches you nothing and feels like proof. You then push to live with the confidence of someone who tested, which is exactly the confidence that skips the backup step.

That is why drift belongs in the same conversation as the update process written out before it runs. A pre-flight that includes “did staging actually match” is a different pre-flight from one that only asks “did staging pass”.

Why Core Version Drift Is Worse This Month

WordPress 7.1.3 shipped on 6 October 2026 as a maintenance and security release, with 7 security fixes and 4 bug fixes. The announcement recommends updating immediately.

Live sites that take a release like that quickly move to a new core version. A staging copy cloned last month does not move with them. It sits on the old core until somebody remembers it exists.

So the first drift of the season is the boring one: live runs the patched core and staging runs the one before it. Any test you run on staging now is a test of a version your live site has already left. The plugin updates you queue up next are tested against the wrong foundation.

The Six Things That Drift First

Across sites, the same six categories separate before anything else does. They are listed here in the order you should check them, which is roughly the order of how often they bite.

#	What drifts	How it usually happens	What it costs you
1	Plugin and theme versions	Live gets updates, staging does not, or the reverse	You test against code the live site is not running
2	Database content	Live keeps collecting orders, posts, users and form entries	Queries behave differently at a different row count
3	Settings rows	A plugin reconfigured on one site only, usually during debugging	The feature you tested is configured differently on live
4	Search engine visibility flag	The clone discourages search engines, and a push carries it back	Live goes no-index without anyone noticing
5	Cron	Staging cron is disabled to stop duplicate emails	Scheduled work passes on staging because it never ran
6	Caching and CDN	Staging has no page cache and no CDN in front of it	Nothing you measured about speed transfers to live

Four and six deserve a sentence more than the table gives them. Cron, row five, is the other quiet one, and it gets its own check further down.

The visibility flag is the one that turns a maintenance task into an SEO incident. Most staging clones are deliberately set to discourage search engines, which is correct for staging. The danger is the direction of travel: if a full database push moves that option row back to live, the live site is now asking not to be indexed, and nothing on the front end looks wrong. What that setting actually does, and what it does not do, is covered in the robots.txt myth. Read that before you decide how worried to be.

Caching is the one people misread. A staging site usually runs with the page cache off and no CDN pointed at it, which makes it a reasonable place to test functionality and a poor place to test anything about speed or headers. If your test involved a page loading faster, you measured a site with a different delivery layer. The WordPress page cache header lies explains why the header you would check to confirm this is itself not trustworthy on its own.

One small setting helps with all six, and it is easy to skip. WordPress lets a site declare an environment type: local, development, staging or production. A site that never sets it is treated as production. If staging and live each declare what they are, plugins and hosts have something honest to read, and you have a one-line fact to compare.

Comparing The Two Sites From Outside

Start outside, because it needs no access and it catches the loudest differences in a couple of minutes.

Request the same path on both hostnames and compare the responses. You are looking for four things:

1. The HTTP status and the final URL after redirects. A staging site that redirects somewhere unexpected is telling you its site URL rows are wrong.
2. The X-Robots-Tag response header, and the robots meta tag in the HTML, on both.
3. Any cache or CDN headers present on live and absent on staging, or the reverse.
4. The generator tag and any versioned asset URLs, which give you a rough read on whether core and plugin versions line up.

Then fetch /robots.txt on both and read them side by side rather than skimming.

curl -sI https://example.com/ | grep -i -E "^(HTTP|location|x-robots-tag|cache-control|age|cf-cache-status|x-cache)"
curl -sI https://staging.example.com/ | grep -i -E "^(HTTP|location|x-robots-tag|cache-control|age|cf-cache-status|x-cache)"

This outside pass will not tell you about settings rows or database size. It will tell you within minutes whether the two sites disagree about what they are, which is the category of drift most likely to cause a visible incident.

Comparing The Two Sites From Inside

The inside pass is where the real distance shows up. On both sites, record the same short list, then diff it:

• WordPress core version.
• Every installed plugin, its version, and whether it is active. Inactive but installed counts.
• Every installed theme and which one is active.
• The values of blog_public, home, and siteurl.
• The row count of your largest content tables, and the total number of rows in the options table.
• Whether DISABLE_WP_CRON is defined, and when the next scheduled event is due.
• The environment type each site declares, and any constants in wp-config.php that exist on one site and not the other.

Two of these are easy to get wrong. Inactive plugins matter because a push can activate them and because they still receive updates. And the options table is worth counting rather than eyeballing: the autoloaded portion of it behaves differently at different sizes, and the autoload query everyone is running covers how to measure it properly.

Cron deserves its own check rather than a line in a list. A staging site with cron disabled will pass a test of anything scheduled, because nothing scheduled ran. You did not test the feature. You tested that the feature did not crash while sitting still. The failure that never alerts you is the same failure mode on live, which is a useful reminder that this is not a staging-only problem.

One more inside check is worth the minute it takes: the PHP version. Staging and live on the same host usually match, but not always, and a staging environment left on an older branch will accept code that live rejects outright. The WordPress PHP version problem is the longer argument for treating this as a scheduled concern rather than an occasional one.

What A Push Overwrites

Before you push staging to live, the question to answer is not “is the code ready”. It is “what on live is about to be replaced”.

A files push, a database push and a combined push each replace something different. The database push is the one that ends careers, because live kept collecting real work while staging sat still, and a full database push replaces that work instead of merging it. It also carries the options table, which is how a staging no-index flag reaches a production site.

Two rules make this survivable. Take a restore point immediately before the push and confirm it is real, which is the whole argument of verifying a WordPress backup. And know in advance what a rollback can and cannot reverse, as set out in what an automatic rollback can undo and what it destroys.

After the push, re-check the same six categories against live. Re-check the visibility flag and cron first, because those are the two that fail silently.

A 2026 guide to creating a WordPress staging site, in about three minutes.

Robbie’s Tutorials, “How to Create a WordPress Staging Site [2026 Full Guide]” on YouTube, 25 Jun 2026

Has a migration or update ever gone wrong on a live site? What happened?

r/Wordpress, “How do you handle moving WordPress sites between local/staging/production?”, August 2026

Both are about getting a staging copy right. The video covers setting one up. The thread is a working question about moving sites between local, staging and production, and the line quoted above is the one this post answers: what goes wrong, and how you would have known.

What Comparing Staging To Live Does Not Solve

A matched staging site is a better test. It is not a safe one.

Even with zero drift across all six categories, a staging test cannot tell you whether:

• the update behaves the same under real traffic, because staging has none;
• a third party integration will respond, since most are pointed at test credentials or nothing at all;
• an email actually sends, because staging usually has outbound mail suppressed on purpose;
• a payment path completes, for the same reason;
• a scheduled job runs correctly over days rather than in a single manual trigger;
• the CDN in front of live will serve the new asset, since staging is not behind it; or
• the change interacts badly with data volumes that only exist on live.

None of that is an argument against staging. It is an argument against reading a staging pass as a guarantee. The honest sentence to put in a client report is the same one that belongs in any check: what was tested, on what, and what was not assessed.

There is also a drift you cannot close by matching. A staging site matched to live on Monday has drifted again by Friday, because live kept working. A comparison is a snapshot, so the useful question is not whether staging matched, but when you last checked that it did.

Sources And Further Reading

• WordPress developer reference: wp_get_environment_type() lists the four environment types and says an unset site is treated as production.
• WordPress developer handbook: Editing wp-config.php documents the WP_ENVIRONMENT_TYPE and DISABLE_WP_CRON settings used in the inside pass.
• WordPress documentation: Reading Settings screen describes what the “Discourage search engines from indexing this site” box does.
• WordPress 7.1.3 Maintenance and Security Release is the release announcement of 6 October 2026.

Which Of Your Staging Sites Is Still A Copy?

If you run twenty sites, you probably have twenty staging environments, and you almost certainly do not know which ones still resemble the sites they were cloned from.

Pick five. Run the outside pass, then the inside pass. Record the drift age, the version differences, the visibility flag, and the cron state for each pair.

So: on the last update you pushed from staging, could you have said, with evidence, how far that staging site had drifted from live before you trusted the test?