Author: Aditya Sharma

Increase WordPress Memory Limit: 4 Safe Ways That Work
You open your site and see a white screen or a line like this: “Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)”. That is PHP telling you a request used more memory than it was allowed to. This guide shows how to increase the WordPress memory limit, how to check that the change took effect, and what to do when raising it does not help.

The number in the error is the limit in bytes. 268435456 bytes is 256 MB, 134217728 is 128 MB and 67108864 is 64 MB. Knowing which limit you hit tells you where to look first.

What the Memory Limit Error Actually Means

Every PHP request gets a fixed budget of memory. When WordPress, your theme and your plugins together need more than that budget, PHP stops the request and logs the fatal error. Visitors see a blank page or a critical error message. You may also see it only in the admin, only when saving a large page, or only during an import.

The wording of the message matters. “Allowed memory size of X bytes exhausted” means the limit was reached. “tried to allocate Y bytes” is just the last small request that tipped it over, so it is rarely the real cause. The plugin or function named in the file path after the message is a better hint.

The limit is set by your host first, and WordPress can only work inside it.

WordPress Memory Limit vs PHP Memory Limit

There are two settings, and people mix them up. The PHP memory_limit is a server setting in php.ini that caps every PHP script. The WordPress memory limit, WP_MEMORY_LIMIT, is a constant that asks PHP for a specific amount just for WordPress.

The official wp-config.php documentation says WP_MEMORY_LIMIT lets you set the maximum memory PHP can use, and that it may be needed when you see the “Allowed memory size of xxxxxx bytes exhausted” message. It also says that by default WordPress tries to raise memory to 40 MB for a single site and 64 MB for multisite. Those are small numbers for a modern site with a page builder and WooCommerce.

There is a second constant, WP_MAX_MEMORY_LIMIT, used in the admin area. Its default is 256 MB. Admin tasks such as image processing and updates can need more than front end pages, so WordPress allows a higher ceiling there.

The key point is that WP_MEMORY_LIMIT cannot go above what the server allows. If the host caps PHP at 128 MB, setting WordPress to 512 MB changes nothing. That is why the first job is to find your real current limit.

Check Your Current Memory Limit First

Do not guess. Open Tools, then Site Health, then the Info tab, and expand the Server section. You will see the PHP memory limit and the WordPress memory limit side by side. If the two differ, the lower one usually wins in practice.

You can also create a small file that prints the value with phpinfo(), then delete it straight away so it does not stay public. Your host dashboard often shows the same number under PHP settings.

Look at the numbers with the error in mind. If the error says 134217728 bytes and Site Health shows 128M, the two agree and the fix is to raise the limit. If the error shows a smaller figure than Site Health, another layer, such as a host rule or a plugin, is lowering it for that request.

Write down the number. After each change in the next sections, check it again. A change that does not move the number did not work, whatever the file says.

Method 1: Raise WP_MEMORY_LIMIT in wp-config.php

This is the method most guides start with because it needs no server access beyond your files. Connect with SFTP or your host file manager and open wp-config.php in the site root. Back it up first.

Add this line above the comment that says “That’s all, stop editing”:
```
define( 'WP_MEMORY_LIMIT', '256M' );
```
Save, then reload Site Health to see the new value. For admin only tasks you can also raise the admin ceiling:
```
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
```
The WordPress documentation notes this line has to be placed before wp-settings.php is loaded. If you add it below, it is ignored. Keep a copy of the file and read our guide on checking that wp-config.php is not exposed so you do not leave a backup copy readable on the web.

Method 2: Change memory_limit in php.ini or .user.ini

If wp-config.php does not move the value, the server limit is the cap. The PHP manual describes memory_limit as the maximum amount of memory a script may allocate, which stops badly written scripts from using all server memory. You can change it in php.ini when you have access to it.

On shared hosting you often cannot edit the main php.ini, but you can add a .user.ini file in the site root with one line:
```
memory_limit = 256M
```
PHP re-reads .user.ini on a timer, commonly every five minutes, so the change may not show at once. On a VPS, edit php.ini for your PHP version, then restart PHP-FPM or the web server. Always confirm the PHP version in use first, since each version has its own file. If you are on an old release, the PHP end of life guide explains why upgrading also helps.

Method 3: Use .htaccess on Apache

On Apache with mod_php you can set the value in .htaccess:
```
php_value memory_limit 256M
```
This works only in that setup. On PHP-FPM or CGI it can cause a 500 error because the directive is not allowed there. If the site breaks after the edit, remove the line and use Method 2 instead. Always keep the old .htaccess so you can restore it in seconds.

Method 4: Ask Your Host to Raise It

Many managed hosts lock the setting. If every method above leaves the number unchanged, open a ticket with the exact error text and the limit you need. Ask for the PHP memory limit for the account, not just for WordPress. Most hosts agree to 256 MB or 512 MB within minutes, and some offer it as a toggle in the control panel.

Be specific in the ticket. Say which site, which PHP version, the exact fatal error line and the date and time it happened. Support can then match it to their server logs and often finds a stricter per-process cap you cannot see from inside WordPress.

If the host refuses to go beyond 128 MB while your plugins need more, that is a signal about the plan, not about WordPress.

When a Higher Limit Does Not Fix It

Sometimes you raise the limit twice and the error comes back with a new, larger number. That points to a leak or a runaway loop, not a budget problem. The documentation says it plainly: if you see out of memory issues even with an elevated limit, you should debug your installation, because heavy functions tied to one action may belong in a cron job.

Turn on logging by setting WP_DEBUG and WP_DEBUG_LOG in wp-config.php, reproduce the error, then read wp-content/debug.log. The file path after the fatal error names the plugin or theme. Deactivate it and test again.

Common causes are a plugin that loads every post into memory, a runaway scheduled task, a bloated database and missing caching. If scheduled jobs are involved, our WP-Cron guide shows how to inspect them. A large autoload table or leftover data also costs memory on every request, which the database cleanup guide covers. A persistent cache reduces repeated work, as the object cache article explains.

How Much Memory Do You Actually Need

Bigger is not always better. A brochure site runs well on 128 MB. A site with a page builder, a store and a few dozen plugins is comfortable at 256 MB. Large imports, backups and image regeneration can ask for 512 MB for a short time.

Page builders, store plugins and security scanners are the usual heavy users. A single product import with thousands of rows can spike memory far above normal traffic, which is why a limit that works all week can still fail during one scheduled job.

Setting a very high limit on a small server can hurt. Each PHP worker may reserve that much, so a busy site can run the whole machine out of memory and fall over for everyone. Raise it in steps, test, and stop when the error goes away.

Safe Order of Operations

Follow the same order every time so you can undo any step.

A silent walk-through of the steps. All scenes are illustrations with example values, not a real run.
1. Back up and test restore. Take a full backup and test that it restores, as described in the backup verification guide.
2. Read the current limit. Check Site Health and note the error text.
3. Raise WP_MEMORY_LIMIT. Set it to 256M in wp-config.php and re-check.
4. Use php.ini or ask the host. If the number did not change, use .user.ini or php.ini, then ask your host.
5. Debug and find the plugin. Enable debug logging, find the plugin behind the error and fix or replace it.
6. Remove debug settings. Switch them off when you are done and keep the limit as low as works.
If the white screen already blocks the dashboard, the critical error playbook walks through recovery step by step. For a wider performance view, see autonomous performance optimization.

Two Outside Views

Two public sources say the same thing in plain words. The first is the spoken line from the WP Workshop video 4 Ways to Increase WordPress Memory Limit:

“What this error means is quite simply that WordPress tried to use more memory than what the web host allows.”
WP Workshop, YouTube

The second is a 2024 thread on r/Wordpress. The poster hit the 256 MB error on a simple Elementor site, and a reply gave the best next step:

“Have you enabled debugging? That will give you a better idea of the cause.”
r/Wordpress, 2024

One view explains the cause, the other says where to look. Together they match the order above: confirm the limit, then read the log.

A Careful Version You Can Do By Hand

You do not need a tool for this. Work on one change at a time and write down what you saw after each one.

Start with a backup you have restored at least once. Open Site Health and copy the memory numbers into a note. Add the WP_MEMORY_LIMIT line to wp-config.php, save, and reload Site Health. If the number moved, test the page that failed. If it did not move, undo the edit and go to .user.ini, then to your host.

Keep the old copy of every file you touch. If the site breaks, put the old copy back before you try anything else. Once the error is gone, turn debug logging off and clear caches. Check the log again the next day for repeats.

Common slips are placing the define line after wp-settings.php is loaded, setting WordPress above the server cap, editing php.ini for the wrong PHP version, and using a huge value such as 2048M to cover a plugin that leaks.

The Point

The memory limit is a budget, and the host sets the ceiling. Raise it in small steps, confirm the number really changed, and stop when the error goes away. If it keeps coming back with a larger figure, the cause is a plugin or task, so read the log.

What is a good WordPress memory limit? 256 MB suits most sites. Start there and only raise it with evidence from the log.

Will raising the limit slow my site? No, memory is only used when needed. The risk is on shared servers where too many workers each hold a large budget.

Why does Site Health still show the old value? The server limit is lower, the file was cached, or the define line sits in the wrong place. Check each in that order.

Sources And Further Reading
October 29, 2026
WordPress Critical Error: A WP Doctor Playbook Guide
The message is short and unhelpful: “There has been a critical error on this website.” WordPress shows it when PHP stops on a fatal error, and it tells you nothing about which plugin, theme or setting caused it. Most site owners respond by changing several things at once, which makes the next failure harder to read than the first.

This guide walks through how the WP Doctor playbook approaches that situation, step by step, and then shows the careful way to do the same work by hand. WP Doctor is run by the Super Agent Wren in the Care group. It diagnoses a problem you report and matches it to a known cause. It applies a fix only for safe WordPress-level causes and hands everything else back with exact steps.

A fatal error has one visible symptom and many possible causes. A plugin update that needs a newer PHP version, a theme function that no longer exists, a memory limit that is too low, and a half-finished core update can all produce the same screen. The page gives no hint which one you are looking at.

The usual panic response makes it worse. Deactivating every plugin, switching themes, raising limits and clearing caches in one sitting can make the site load again, but it leaves you without an explanation, and the cause is still there for the next update. Good diagnosis is mostly about changing one thing at a time and writing down the state before and after.

This matters most if you look after sites for other people. A client who sends a screenshot of the error expects an answer, not a list of things you tried. A repeatable order of work, with a written record at the end, is what lets you give that answer calmly.

What The WP Doctor Playbook Is

WP Doctor is a Care playbook with five steps. You start it by asking in your AI app, for example “Wren, run WP Doctor on my site.” It needs no connector, and it produces a Markdown report covering findings, evidence, changes made and the recheck result.

It changes the site in step 4 only, and your AI app asks you before any step that changes the site. The playbook page also recommends connecting a staging copy before a live site.

Step 1: Gateway And Environment Probe

The first step checks how Protuno reaches your site and what it can do there, without changing anything. This is the part people skip by hand. Before you chase a plugin, confirm what you can actually see: can you reach wp-admin, can you read logs, do you have file access, and is there a staging copy.

By hand, write down your PHP version, WordPress version, the list of active plugins and the active theme before you touch anything. If you also keep an eye on core update readiness, you will already have most of that list.

Step 2: Reproduce And Health Baseline

The second step reproduces the reported problem and records site health before any change. A baseline matters because it is the only way to tell later whether a fix helped or just moved the failure somewhere else.

By hand, load the failing URL, note the exact message and the time, then load two or three pages that still work. Record which pages fail and which do not. A failure on one template points somewhere different from a failure on every page, including wp-admin.

Step 3: Collect Evidence And Match Signature

Step three gathers evidence and matches it to a known failure pattern, or hands the case back. The handing back is deliberate. If nothing matches, WP Doctor applies nothing and gives you the case with what it found.

The evidence that matters most by hand is the PHP error itself. WordPress can write it to a log file when debugging is enabled. The official debugging documentation describes WP_DEBUG and WP_DEBUG_LOG for this. The log line names a file path, and the path usually names the plugin or theme folder responsible. Turn debugging back off when you are finished, and keep the log out of public reach, because paths and warnings help an attacker.

Step 4: Safety Snapshot And Apply Fix

Step four is the only step that changes the site. It saves a confirmed copy of what it will touch, applies one matching safe fix, rechecks, and restores the copy if health gets worse. Two details matter here: it applies one fix, not a batch, and it can undo its own change.

The playbook page says it applies a fix only for “safe WordPress-level” causes but does not list which specific causes qualify. To find a plugin or theme conflict, it may switch plugins off and on with the site in maintenance mode. If you want to practise that technique on a staging copy first, see how to isolate a plugin conflict.

Step 5: Verify And Report

The last step reruns the check that failed and writes up what was found and changed. The report is the part that outlives the incident. Six months later, when the same error returns after an update, a written record of what the cause was and what fixed it saves the whole diagnosis.

By hand, keep a plain text note per incident: date, message, log line, the one change you made, and the result. If a broken page also shows up as a spike of missing URLs, 404 monitoring will show the damage that visitors saw.

Read the report in the order it is written. Findings tell you what was seen. Evidence tells you why the finding is believed. Changes made lists anything that was altered, which should be empty if the case was handed back. The recheck result tells you whether the failing check now passes. If the recheck still fails, treat the case as open, whatever the findings say.

When a case is handed back, the exact steps are the useful part. They are written for you to carry out or pass to your host, so read them before you decide the playbook failed. A clear hand-off for a server problem is a correct result, because a server problem cannot be fixed from inside WordPress.

What The Playbook Does Not Do

WP Doctor is narrow on purpose. Server and CDN problems, uncertain causes, and suspected malware are diagnosed and handed off, never fixed. If no known failure pattern matches, it applies nothing and hands off. It fixes only what matches a known pattern, so unmatched problems get no automatic fix.

That boundary is a feature. A fatal error that is really a compromised file should not be “fixed” by an automated tool that restores the site to look healthy. If you suspect that, start with a malware scan and treat it as a security incident.

A Careful Version You Can Do By Hand

You can follow the same discipline without any tool. Work in this order and stop as soon as the site recovers:
1. Take a backup you have verified first. Files and database, stored off the server.
2. Record the baseline. Versions, active plugins, the exact message, which pages fail.
3. Read the error. Check the email WordPress sends to the admin address when it detects a fatal error, and the debug log. Both name the file involved.
4. Change one thing. Deactivate only the plugin the log names, or rename its folder over FTP if wp-admin is unreachable.
5. Recheck. Reload the failing page and the working pages from your baseline.
6. Write it down. Cause, change, result.
The limit of the manual route is time and recall. It works well for one site you know. It gets slow across many sites, and it depends on you remembering what you changed. If updates keep triggering these errors, a clear auto-updates policy reduces how often you meet them.

A few habits make the manual route safer:
- Use a staging copy when you have one. The WP Doctor page makes the same recommendation, and it applies to manual work too.
- Do not edit files on the live site without a copy. A typing slip in a PHP file can turn one error into a different one.
- Do not leave debugging on. Log files can expose paths and warnings you do not want public.
- Do not stack changes. If two changes fix it, you will not know which one mattered.
WordPress also sends the site admin an email when it detects a fatal error, and that email can include a link to recovery mode. If you have not received one, check the spam folder and confirm the admin address in settings is one you still read.

Two Outside Views

A 2024 thread in r/Wordpress titled “There has been a critical error on this website” has a commenter giving the common advice:

“Easiest way to fix this is to find the plugin causing the error.”
r/Wordpress, 2024

That matches the approach in this guide: find the cause first, then change one thing at a time.

In the video “How to Debug Critical Errors on your WordPress Website?” the presenter, speaking for the Techril channel, describes the screen and the first thing to check:

“Now, you’re just met with this error. There has been a critical error on your website. Please check your site admin email inbox for instructions.”
Techril, YouTube

The presenter then asks whether you can still reach the admin area, which is the same first question the careful version above starts with.

A silent walk-through of the steps. All scenes are illustrations with example values, not a real run.

Where Protuno Fits

Protuno gives you WP Doctor as one of its playbooks. You ask for it in your AI app, it works through the five steps above, and the changes happen only after your AI app asks you. The output is the Markdown report, so the incident record is written for you. Because it hands back anything it cannot match, you still make the decisions that matter.

The Point

A critical error is not a mystery, it is a missing log line. Record the state, read the error, change one thing, check the result and write it down. A tool can run that loop for you, and the loop is worth keeping even when you run it yourself.

Sources And Further Reading
October 29, 2026
WordPress Crawl Depth: Why Buried Posts Never Rank
Open Google Search Console’s Page Indexing report on a site with more than a few hundred posts and the same two lines show up: “Discovered – currently not indexed” and “Crawled – currently not indexed.” Click into either one and the URLs are almost never the newest posts or the homepage. They are the posts buried four, five, six clicks deep, the ones no menu, no “related posts” widget, and no other article links to. Google found them. It just never came back.

That gap between “found” and “indexed” has two names. People who build site navigation call it click depth, the number of clicks from the homepage. Google’s own documentation calls the same distance crawl depth. This post uses crawl depth, since that is the term Google’s own pages use, but every count below is the same count either way.

The Screen That Started This Check

“Discovered – currently not indexed” means Googlebot’s crawl scheduler put a URL on the list and then never got around to fetching it. Google’s own help documentation defines the status plainly: “The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl.” (Google Search Console Help, Page Indexing report) The practical pattern reported across SEO forums and tools is consistent: pages with a high crawl depth, especially anything more than three or four clicks from the homepage, show up disproportionately in this bucket.

The fix is rarely “write a better page.” It is “put a link somewhere Google already looks.”

What Crawl Depth Actually Counts

Crawl depth, or click depth, is the smallest number of clicks it takes to get from the homepage to a given page, following only the links a browser could actually follow. A page linked directly from the main navigation menu sits at depth 1. A page one click into a category archive from that menu item sits at depth 2. A blog post that only shows up on page 5 of the blog archive sits at depth 5: four clicks through the archive pages (2, 3, 4 and 5), then one more click to open the post.

The homepage is depth 0. Nothing sits at a negative depth, and nothing below the homepage counts the click needed to load the homepage itself.

This is a structural measurement, not a visual one. A link in the footer counts exactly the same as a link in the hero banner, as long as both are real, crawlable anchor tags in the rendered HTML. A link that only appears after a reader clicks a “load more” button that fires JavaScript with no underlying URL does not count, because Googlebot never gets the click.

Why Depth Zero Is The Homepage, Not The Logo

A common mistake when counting depth by hand is starting from a page rather than the actual root URL. The homepage is whatever resolves at the bare domain, not the page the site’s logo links to if that happens to differ (some sites point their logo at a different “home” than the domain root, usually by accident after a migration or a find and replace on URLs). Before counting anything else, confirm the domain root and the logo link go to the same URL. If they do not, the site has two different depth-zero candidates depending on how a visitor arrived, and any depth count built on the wrong one will be off by one everywhere downstream.

How Google Treats A Page Three Clicks Deep

Google’s own crawl budget documentation lists “popularity” as one of two drivers of crawl demand, and defines it in one plain line: “URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems.” (Google Search Central, Crawl Budget Management) A page reachable in one or two clicks, linked from dozens of other pages on the same site, looks more “popular” by that measure than one reachable only by chance. This is distinct from PageRank in the classic sense, but it borrows the same intuition. Depth is a proxy for how much the site itself seems to vouch for a page.

The practical effect shows up as a widening gap the deeper a page sits. A page at depth 1 or 2 on a well-linked site gets recrawled on a schedule close to the site’s overall crawl rate. A page at depth 5 or 6 might get its first crawl weeks after publish, and a recrawl only when something else on the site changes enough to trigger a fresh pass. For a site publishing daily, that lag compounds: today’s post is buried under tomorrow’s before Google ever came back to look twice.

A silent walk-through of the steps. All scenes are illustrations with example values, not a real run.

Where Depth Quietly Grows: Menus, Pagination, Tags

Three structural habits add depth without anyone deciding to:
- Paginated archives. A category page showing 10 posts per page puts post 11 at depth 3 (category, then page 2, then the post) and post 31 at depth 5, just from pagination, with no other link path shortening it.
- Tag and taxonomy sprawl. Tags that exist mainly as metadata, with no link to them anywhere but the post footer, create a path that technically “links” to related posts but adds a hop that readers and crawlers rarely use on purpose.
- Menu pruning. Every time a navigation menu gets trimmed for a cleaner header, whatever used to hang off the removed menu item loses its shortest path to the homepage and falls back to whatever the next-shortest internal link offers, which is often a lot deeper. If the old menu target was deleted rather than unlinked, also check which 404 errors actually cost you.
None of these habits are mistakes on their own. A publication with thousands of posts cannot put all of them in the main menu. The problem is that none of these choices get revisited once made, so depth creeps upward every time new content is added below the fold of an existing archive.

Measuring Crawl Depth On Your Own Site

A rough measurement takes four steps and no paid tool:
1. List the main navigation links. These sit at depth 1 by definition, assuming the homepage links to them directly.
2. Open each one and list what it links to. Everything found this way, that was not already counted at a shallower depth, sits at depth 2.
3. Repeat outward. Depth 3 is everything newly reachable from a depth-2 page, and so on. Stop once a check of 15 to 20 sample URLs, picked from across the site’s age and traffic range, stabilizes into a clear pattern (most content lands at depth 2 to 3, with a long tail past depth 5).
4. Cross-check against Search Console. Export the Page Indexing report, filter to “Discovered – currently not indexed” and “Crawled – currently not indexed,” and spot-check ten of those URLs for how many clicks it actually takes to reach each one from the homepage. A strong correlation between high depth and non-indexed status confirms the diagnosis; a weak one means something else (duplicate content, a noindex tag left on by accident, a canonical pointing elsewhere) is the more likely cause.
Dedicated crawler tools automate steps 1 through 3 and report depth directly, but they are optional for a site under a few thousand URLs. The manual version above is slower, not less accurate, and depth is only one line in a fuller technical SEO audit.

Three Fixes That Do Not Require A Redesign
- Add a “recent in this category” or “related posts” block that links by topic, not just by date. This creates new depth-2 and depth-3 paths into older content without touching the main menu.
- Link forward from new posts into relevant older ones, inside the body text. A single contextual link from a high-traffic new post can cut an old post’s depth by two or three in one edit.
- Build or fix an HTML sitemap page, and link to it from the footer. This does not replace the XML sitemap submitted to Search Console, but it gives Googlebot, and readers, one more guaranteed short path to everything the site considers worth listing.
None of these require touching the primary navigation, which is usually the part of the site most resistant to change because it affects every visitor, not just the ones arriving from search.

What Shallow Crawl Depth Does Not Solve

Reducing crawl depth gets a page crawled more often. It does nothing for page speed, for whether the content actually answers the query, or for whether the server itself responds fast enough to make a healthy crawl rate worth having. A CDN that is not actually serving cached responses undercuts crawl efficiency in a different way than depth does, by making every fetch, shallow or deep, slower and more expensive for the crawler’s time budget. The two problems get confused because they both show up as “pages not getting indexed,” but they need separate checks and separate fixes.

Depth also does not fix duplicate or near-duplicate content. A page reachable in one click that duplicates another page’s content is not going to outrank or out-index its twin just because it is shallow. Depth is a necessary condition for a healthy crawl pattern. It is not a sufficient one, and redirect chains waste crawls in their own way.

A Careful Version You Can Do By Hand

For a site with no budget for a crawler subscription, the honest manual version is exactly the four-step process above, done with a spreadsheet and a few hours of clicking. The limitation is scale: hand-counting depth past a few hundred URLs becomes impractical, and any manual count is a snapshot, not a live monitor, so it goes stale the moment the menu or a major archive page changes. For a site that size, rerun the check quarterly, or any time the navigation changes, rather than treating one count as permanent.

Two Outside Views

A thread in r/SEO asked the direct question: “Does click depth have an impact on seo?” The original poster described a site with “3 clicks depth for strategic pages” and asked whether adding a mega menu to cut that to one click would help rankings.

Short answer is yes, but 3 clicks is fine. Most people are trying to reduce it from 6-9 clicks.
r/SEO, 2022

Another reply in the same thread cautioned against over-correcting with navigation changes: “The mega menu can affect your DOM and your site speed. You can try to internal linking from the other blog articles, also your blog category structure has to be great.”

A short YouTube explainer, “What is Crawl Depth in SEO?” from the channel Sabir Ali, frames the same idea from the crawler’s side rather than the link structure’s side.

This video will explain what crawl depth is in SEO and why it’s important for your website’s ranking.
Sabir Ali, YouTube

Both sources land on the same practical number that keeps surfacing in this research: three clicks or fewer for anything that matters, with real damage usually starting past six.

The Point

Crawl depth is the kind of problem that never announces itself. Nothing breaks, no error appears in wp-admin, and the posts affected still look fine to a human who finds them directly. The only visible symptom is a Search Console report quietly filling up with “discovered” and “crawled” rows that never flip to “indexed.” Counting clicks from the homepage, by hand if needed, is one of the few SEO checks that costs nothing but time and tells a site owner exactly which pages the site itself is hiding from its own crawler.

Sources And Further Reading
- r/SEO: “Does click depth have an impact on seo?” read live, thread dated 2022.
- YouTube: “What is Crawl Depth in SEO?” (Sabir Ali) short explainer, verified live.
- Google Search Console Help: Page Indexing report, “Discovered – currently not indexed”
- Google Search Central: Crawl Budget Management for large sites
October 28, 2026

WordPress Spam Registrations: The Playbook, Step By Step

Open the Users screen and filter to Subscriber.

If the list is full of accounts you do not recognise, with usernames that look machine-made, you are looking at the thing this post is about.

The harder question is not how to delete them. It is which settings let them in, and whether the comment queues are filling up through the same open door.

Short answer: WordPress spam registrations are new accounts created on a site by people you did not invite. Two settings decide how easy that is: whether anyone can register, and which role a new account gets. A read-only playbook can check both, count the comment queues and list accounts that are worth a look, without changing a user or a comment.

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 and on its public page on 27 October 2026. It is not a result from a real run: no playbook was run for this post, and every number in the images and video is an example value. It does not say how spam accounts get past a registration form on any particular site, because that depends on the site.

Two Doors Spam Walks Through

A WordPress site has two common ways for a stranger to leave something behind. One is an account. The other is a comment.

The account door is set in two places on the Settings, General screen. The WordPress documentation for that screen describes the first as “Anyone can register”, a checkbox for when “you want anyone to be able to register an account on your site”. The second is New User Default Role, which “allows you to select the default Role that is assigned to new users”. The valid choices it lists run from Subscriber up to Administrator.

Those two settings work together. Open registration with a Subscriber default is a small risk. Open registration with a higher default role is a different kind of problem, because every stranger who signs up arrives with more power. The user roles post explains what each default role can do.

The comment door is set on the Settings, Discussion screen. The documentation for that screen lists, among others, a checkbox that only lets logged-in, registered users comment, and a setting that closes comments on older posts after a number of days. A site where comments stay open everywhere and anyone can register has two open doors, and the queues behind them can grow without anyone noticing.

An exposure audit reads both doors in one pass. It does not close either.

What An Exposure Audit Looks At

The playbook’s public page says it looks at three things:

Comment settings and queue sizes. Whether comments and pings are open by default, where they are still open, and how many comments sit in each queue.
Users by role and recent signups. How many accounts exist in each role, and how many registered in the last 30 days.
Accounts worth a look. Accounts with a throwaway email domain or a username that looks machine-made.

It then gives an exposure rating and the next steps that apply. The next sections go through how.

The Playbook, Step By Step

The Comment & Signup Spam Exposure Audit playbook has two steps, in a fixed order. In the dashboard it carries a Beta label, sits in the Content group and only reads. The public page files it under Security, says it needs no connector, and says it runs when you start it with no schedule set. This post uses the public page’s category.

A silent walk-through of the two steps. All scenes are illustrations with example values, not a real run.

Step 1: Read Exposure Signals

Step 1 is read-only. Every call it makes is a GET. It does four things:

It reads the settings that open the doors: the default comment and ping status for new posts, whether anyone can register, the default role, whether comments are held for moderation, whether commenters must be registered, and whether comments close on old posts.
It counts the comment queues: held for moderation, spam, trash and approved. It reads them 100 at a time, up to 20 pages, and reports “2000+” when a count hits that limit.
It looks at where comments are still open on posts, pages and media, reading up to 10 pages of each.
It counts users by role and how many registered in the last 30 days, using the 500 newest accounts.

From those users it picks out accounts worth a look. That part gets its own section below.

Step 2: Spam Exposure Report

Step 2 makes no calls. It takes the numbers from step 1 and rates exposure as Low, Medium or High from fixed rules, then writes a report with these headings: Comments, Signups, Accounts worth a look, Not readable on this connection, Next steps, and Note.

“Not readable on this connection” matters. If an option cannot be read, the report says so instead of guessing.

How To Read A Rating

Rating	It is given when any of these is true
High	Pending plus spam comments are 500 or more.
High	10 or more accounts are worth a look.
High	Comments are open on more than half of posts and 50 or more are pending.
High	Registration is open and the default role is above Subscriber (above Customer on a shop).
Medium	Pending plus spam comments are 50 or more.
Medium	At least one account is worth a look.
Medium	New posts are open for comments by default.
Medium	Registration is open.
Low	None of the above.

The rules are plain counts, so you can check any rating against the numbers in the report. A Medium rating on a site that simply allows registration is not an alarm. A High rating because the default role is above Subscriber is worth fixing today.

The report’s next steps depend on what it found. They can point to the Spam Comment Deleter playbook when pending plus spam is 50 or more, to the Disable Comments playbook, to a review of the listed accounts in the Users screen “before changing anything”, and to fixing the default role or unticking “Anyone can register”. If something could not be read, it adds a pointer to check Settings, General and Discussion by hand.

What “Worth A Look” Means

This is the part most likely to be misread, so the step file is strict about it.

Only accounts with the Subscriber role, or Customer on a shop, are considered. An account is called worth a look for one of two reasons:

Its email is on a fixed list of 30 throwaway domains, such as mailinator.com.
Its username looks machine-made. Two patterns count: a username with no separator that ends in six or more digits, or one of ten or more characters that switches between letters and digits four or more times.

A few rules sit around that:

The report shows only the username and the email domain, never a full email address.
It says “worth a look”. It never calls an account fake, a bot, a spam account or malicious.
It never recommends deleting, banning or removing a user.

The caution is fair. A real person can have a username that ends in digits, and a real person can use a throwaway address for a free download. A flag is a prompt for you to open the account and decide, nothing more. The playbook only reads, so no account changes whichever way you decide.

What The Settings And The Public Page Say

The two sources agree on the substance. Both say the playbook only reads, has two steps and needs no connector, and the public page says no step is set to pause for your approval. The one difference found is the group label: the dashboard says Content, the public page says Security.

The settings panels for both steps, viewed in the dashboard on 27 October, show Automatic backup None and Approval checkpoint Off. For a playbook that changes nothing, that fits: there is nothing to back up and nothing to approve.

What The Playbook Does Not Do

The step files and the public page set clear limits:

It does not stop anyone registering. There is no blocklist and no email check at signup.
It does not say how an account got in. It reads signals; it does not trace them.
Counts stop at 2,000 comments per queue and at the 500 newest users, and the report says when a count hit its limit.
It flags only Subscriber and Customer accounts. An account with a higher role is not flagged for its email or username.
It does not approve, trash or delete any comment, and it does not change any user.
“Worth a look” is not a verdict. A clean report is not proof that nothing is wrong.

A plugin that blocks signups is a separate tool. A read-only audit tells you how exposed you are; it does not close anything.

Two cases deserve their own posts. If spam accounts keep appearing after you close registration, the question changes from exposure to compromise, and WordPress Hacked: The First Hour, In Order covers what to do first. And if you want to know which accounts can be found from outside, the user enumeration post is about the routes that list usernames.

A Careful Version You Can Do By Hand

You can read the same signals yourself. It takes longer as the site count grows.

Open Settings, General. Note whether “Anyone can register” is ticked and what New User Default Role says. If registration is open and the role is above Subscriber, fix that first.
Open Settings, Discussion. Note whether commenters must be registered, and whether comments close on older posts.
Open Comments and read the count beside Pending, Spam and Trash.
Open Users and click Subscriber. Read the usernames and the email domains on that list. A page of near-identical names is a reason to look closer.
Write down what you found and the date, so the next check has something to compare with.
Only then decide what to change. Closing registration and trashing spam are separate decisions, and neither needs to happen the same day.

On one site this is a short job. Across twenty sites it becomes a recurring chore, and the repeatable part is the reading. The judgement stays with you: which accounts to open, and whether a site needs open registration at all.

The two-factor post is the next layer if a flagged account turns out to be a real one with a weak login. It separates turning two-factor on from enforcing it.

Two Outside Views

A hosting company’s video and a forum thread. Both are about neighbouring problems rather than signup spam itself, and neither describes the Protuno playbook. They are here for the habit they share with it: read what is there before you change anything.

Ahosting INC’s “Could Not Create Directory in WordPress: Find the Folder First (2026)“, published 5 October 2026, is about a plugin install error, not about accounts. Its advice is to diagnose first: find the folder path, check disk space and inode limits, and only then look at folder modes.

Check both your space and inode gauges in your control panel or you will end up chasing permission ghosts forever.
Ahosting INC, Could Not Create Directory in WordPress: Find the Folder First (2026), auto-generated English captions, 5 October 2026

It is a hosting company’s explainer that points to its own written guide, and the captions are automatic. The same video is a source in the file permissions post, which covers the error itself.

In an r/Wordpress thread, a poster describes investigating a compromised site. They say an attacker used a valid administrator session, installed a file manager plugin and used it to upload executable PHP files. Their main lesson:

A successful WordPress admin login should be treated as a full application compromise.
u/ThaiHeartly, r/Wordpress, 11 August 2026

The poster says how the administrator session was first obtained is unknown. This is one poster’s account that I could not verify, and some replies asked whether the write-up was machine-written, which the poster denied. My reading, not theirs, is that the playbook would not see a case like this. It flags only Subscriber and Customer accounts, and an account created with a higher role is outside what it flags. The user roles post is the place to look at those.

Where Protuno Fits

The Comment & Signup Spam Exposure Audit playbook is the reading part of this job. It reads the comment and signup settings, counts the queues and the recent signups, lists accounts worth a look, and writes a Low, Medium or High rating with the rule that decided it. It needs no connector, runs when you start it and has no schedule set. It changes nothing.

Two other playbooks cover the writing side, and the report points to them when they apply. Spam Comment Deleter trashes comments confirmed as spam, and Disable Comments stops new comments. Protuno publishes its playbooks as written-out steps you can read first. The playbooks page lists them, and this one has its own page at Comment & Signup Spam Exposure Audit.

The Point

Open registration is a choice, and the default role decides how big a choice it is. The comment queues are a second door. Neither tells you anything until someone reads them.

Read both doors, treat a flag as a question, and keep the decision about each account with a person. A rating on paper is a reading list, not a verdict.

If someone registered on your busiest site tonight, would you know which role they got?

Sources And Further Reading

October 27, 2026

WordPress File Permissions: Check The Owner First

A plugin install stops with “Installation failed: Could not create directory.” An upload in the media library says “Unable to create directory wp-content/uploads/2026/10. Is its parent directory writable by the server?” Or an update stops on a screen that says “To perform the requested action, WordPress needs to access your web server. Please enter your FTP or SSH credentials to proceed.”

The advice for all three is usually a number: set the folder to 777. The WordPress handbook warns against it, and a hosting company’s video about the first error says you never need it. These messages are not asking for a bigger number. They say WordPress tried to write something and the server refused, and the refusal has more than one possible cause.

Short answer: find out who owns the files and which account PHP writes as, then read the mode. WordPress itself decides whether it can write by comparing owners, not by reading digits. For servers where PHP runs as the file owner, the handbook’s baseline is 755 for directories and 644 for files, with wp-config.php at 440 or 400, and it treats 777 as a number to question. The number is the last thing to change.

What this post is, and is not: a walk-through built from the WordPress handbook, the WordPress 7.1.3 source on GitHub, two videos and one forum thread. I did not test anything on a site, and the commands near the end are read-only ones I have not run. The right values depend on your host, so the post says where to measure instead of giving one number to copy. Latest checked: WordPress 7.1.3 (6 October 2026) is the current stable release and 7.2 Beta 1 came out on 20 October. Neither announcement mentions file permissions or the filesystem.

Four cards in a row showing the WordPress write test: create a test file in wp-content, compare the owner of that file with the owner of a core file, write directly from PHP when the owners match, and ask for FTP or SSH details when they differ. — Illustration of the check described in the WordPress 7.1.3 source. Example wording, not a screenshot.

Three Digits, Three Audiences

A mode is three digits: the owner, the group, and everyone else. Read is 4, write is 2 and execute is 1, and each digit is the sum. So 7 is read, write and execute, 5 is read and execute, and 4 is read only. That is the scheme the handbook’s file permissions page describes.

Mode	Owner	Group	Everyone else
755	read, write, execute	read, execute	read, execute
644	read, write	read	read
777	read, write, execute	read, write, execute	read, write, execute

“Everyone else” means every other account and process on that server. The handbook’s warning about 777 is about those accounts and processes, not about visitors reading files.

How WordPress Decides It Can Write

Before it writes during an install or update, WordPress runs a small test. In the 7.1.3 source it is the function get_filesystem_method() in wp-admin/includes/file.php. Unless the FS_METHOD constant is defined, it works like this:

It tries to create an empty file named temp-write-test- plus a random string inside the wp-content directory.
If that works, it compares the owner of the new file with the owner of a WordPress core file.
If the two owners match, it writes directly from PHP.
If they differ, or the test file could not be created at all, it falls back to SSH or FTP and shows the credentials screen quoted at the top.

There is one more branch. A caller can allow “relaxed” ownership, and then a writable directory is enough to alter existing files, though that mode never creates new ones. The code comment says so.

Two consequences follow from reading the code. I have not run either. First, a folder at 755 that is owned by the account PHP runs as passes the test, so no 777 is needed. Second, loosening a folder to 777 does not fix an owner mismatch. PHP can create the test file, but if PHP runs as a different account from the one that owns the core files, the new file has a different owner and WordPress still asks for FTP details. The same prompt also appears when the test file cannot be created at all, which is why it can mean two different problems.

The handbook describes the working case for servers it calls “suexec”, where PHP runs as the owner of the files. There, it says, WordPress “will not ask for FTP credentials when upgrading or installing plugins”.

FS_METHOD is the documented override. The handbook’s wp-config page says it forces the filesystem method and that you should generally change it only if you have update problems. It also says “direct” is chosen automatically when appropriate, and that forcing it is “fraught with opening up security issues on poorly configured hosts”. In the code, defining it skips the test above. It does not change who owns anything.

What The Handbook Recommends

The handbook’s file permissions page gives a scheme for servers where PHP runs as the file owner, and its hardening page repeats the key values.

What	Handbook value	Where it says so
Directories	755 or 750	File permissions page, the suexec scheme
Files	644 or 640	Same scheme
wp-config.php	440 or 400	Same scheme. The hardening page says only you and the web server should be able to read it, which “generally” means 400 or 440
Upload directories	Not 777: “No directories should ever be given 777, even upload directories”	Same scheme
wp-content	Writable by your user account and the web server process	Hardening page
Plugin files	Writable only by your user account	Hardening page

The page also notes that wp-config.php is “initially created with 644 permissions, and it’s a hazard to leave it like that”.

Three cautions on that table. First, the handbook says permissions differ from host to host, and that its guide covers general principles. Second, the page is not consistent about 777. Its general section says to start restrictive and raise permissions until it works, lists modes to try in order, and ends with “Only use 777 if necessary, and hopefully only for a temporary amount of time.” It also says “when you see 777 ask why it’s necessary”. Third, the hardening page says automatic updates run as the file owner and set files to 0644 and directories to 0755, so a mode you set by hand on core files is not guaranteed to survive. Check after an update, and read the auto updates post for what updates run on your site.

777 In Plain Terms

The handbook says 777 makes a file or directory readable, writable and executable by all users, groups and processes. Its worst case is that if an attacker can upload or modify a file to execute code, “they will have complete control over your blog, including having your database information and password.”

The description of that same video, from Ahosting INC, is blunter. It says the usual advice is to make wp-content 777, and “You never need it.”

The better fix is the one the handbook points to: any file that needs write access from WordPress should be owned, or group-owned, by the account WordPress runs as. That means changing the owner, then keeping the mode at 755 or 644. It does not mean raising the mode until the error goes away.

Four Causes, One Message

The same sentence can come from causes that have nothing to do with a mode.

Four cards in a row naming four causes of the same WordPress could not create directory error: wrong owner, mode too strict, disk or inode limit, and security module. — Illustration. Each card is a cause named in the handbook or the Ahosting video.

Wrong owner. The Ahosting video says that if a 755 mode fails to let you write to a directory, the folder likely belongs to a different user account.
Mode too strict. The Ahosting video says a security plugin may have hardened folders to 555. The handbook’s .htaccess example says a mode set too low stops the server reading the file, which causes an error.
Disk or inode limit. The Ahosting video says WordPress creates every empty folder before it writes a file, that each folder needs an inode, and that an account near its inode limit can fail on folders while the storage gauge still shows room. It also says the server needs slightly more than twice the unpacked plugin size to hold the zip and the extracted copy.
A security module. The handbook says SELinux denials are often hard to tell from regular permission errors. It is typically installed on Red Hat family systems, and it can block writing the .htaccess file.

I confirmed that the sentence “Could not create directory.” appears in the 7.1.3 file wp-admin/includes/file.php, and that the upload message above appears in wp-includes/functions.php. I did not count the places the Ahosting video says the sentence comes from.

Find The Cause In Order

The Ahosting video’s order is a good one: find the path, check space and inodes, then look at modes and ownership, and only then change anything. Adapted, with two extra steps:

Read the full message. The Ahosting video says the Install Now button drops the folder path from its output, and shows two ways to retrieve it, which its written guide also covers. The path tells you which folder failed.
Ask WordPress what it can write. Go to Tools, then Site Health, then the Info tab, and open Filesystem Permissions. In 7.1.3 it lists the main WordPress directory, wp-content, uploads, plugins, themes and fonts, plus the must-use plugins directory if it exists, each as Writable or Not writable. It asks PHP, so it reports what the web process can do, not what your own login can do.
Check space and inodes. Look at both gauges in your hosting panel, or run the commands below on a server where you have a shell.
Compare owner and mode. List the owner, group and mode of wp-config.php, wp-content, uploads and plugins, and compare the owner with the account PHP runs as. Your host can tell you which account that is. A command-line php run reports the command-line user, which may not be the one that serves pages.
Check for a security module. On Red Hat family systems, ask whether SELinux is enforcing.

df -h
df -i
stat -c '%U %G %a %n' wp-config.php wp-content wp-content/uploads wp-content/plugins
getenforce

These are read-only commands, and I have not run them on a site. stat -c is the GNU form and differs on macOS. getenforce exists only where SELinux is installed. On shared hosting without a shell, the same information is usually in the file manager and the hosting panel.

Write down the result before you change anything. If the owner is the account PHP runs as and the modes match the handbook’s table, the mode was never the problem, and the next suspect is space, inodes or a security module.

The Outside View Is A Different Check

Nothing about a mode is visible over HTTP. An outside check can only show a file being served that should not be, and two earlier posts already cover that: the exposed twin of wp-config.php and the debug log that is readable from outside. Run those alongside this one. This post is the inside view.

For a wider look at a whole install, the hardening measurements test advice on live sites before repeating it, which is the right habit for any permission change too.

What Correct Permissions Do Not Solve

Permissions say who on the server may touch a file. They are a small part of the picture.

A write made through WordPress. WordPress writes as whichever account PHP runs as. A plugin weakness, or a stolen administrator login, can make it write something unwanted even when the modes are correct.
An administrator. Anyone who can install plugins or edit files from the dashboard works around the filesystem question. Who really has the keys is the check for that.
File contents. A mode says nothing about whether a file changed. If something looks wrong, a malware scan and the first hour after a hack are the next steps.
A tightened mode that gets reset. The handbook says automatic updates set files to 0644 and directories to 0755.
A full account. As above, the error can come from space or inodes, and chasing a mode will not fix it.

A permission pass belongs inside a bigger one. The security audit walk-through puts the order of work in one place.

Two Outside Views

Both picks below are about spam accounts, which is a neighbour of this topic rather than the same one. They are here for the point in the previous section: a correct mode does not say anything about who is allowed to create an account or what a form lets through.

A video. WP Ultimate Security’s “Stop Fake and Spam Email Signups in WordPress“, published 3 August 2026, walks through two features of its own plugin, an email blocklist and email verification. It blocks addresses and whole domains, and it checks sign-ups, comments and WooCommerce checkout for badly formed, disposable or no-MX-record addresses. It tests each one on screen.

It’s a simple way to keep spam accounts out and block problem users without having to delete anyone’s account manually.
WP Ultimate Security, Stop Fake and Spam Email Signups in WordPress, auto-generated English captions, 3 August 2026

It is a vendor’s tutorial for its own plugin, and the description says the features need both the free plugin and its Pro version. I did not test the plugin, and the captions are automatic. Nothing in the video touches file modes.

A thread. In an r/Wordpress thread, a poster running a course site on Tutor LMS, with registration set to need manual administrator approval, describes accounts with crypto, casino and pharma names appearing as approved with no approval step and no notification email.

Lately though, my site has been flooded with user registrations that are somehow automatically approved, no admin input required.
u/realcryptogd, r/Wordpress, 18 September 2026

The replies disagree. One says this is a backdoor symptom and suggests checking for hidden administrators, webshells in uploads and files in mu-plugins. Another asks why a backdoor would need registration open, and suspects a second registration endpoint that skips the approval step. The poster tried hiding the default login page and says it did not help, and the thread does not report a cause. My reading, not theirs, is that this is the kind of problem where a folder’s mode cannot tell you anything, because the accounts are created by the application, not by a file write. It is one poster’s account that I could not verify, and the replies are guesses.

The Point

Pick one site you manage. Without changing any mode, can you say which account owns wp-content and which account PHP writes as?

If not, the number on the folder is not the thing to look at yet. The question is what WordPress sees when it tests a write, and what you would do if the answer were different on the next site.

Sources And Further Reading

Changing File Permissions, Advanced Administration Handbook, WordPress Developer Resources, page read 27 October 2026.
Hardening WordPress, Advanced Administration Handbook, page read 27 October 2026.
Editing wp-config.php, WordPress upgrade constants, Advanced Administration Handbook, page read 27 October 2026.
wp-admin/includes/file.php at the 7.1.3 tag, WordPress source on GitHub, read 27 October 2026.
wp-admin/includes/class-wp-debug-data.php at the 7.1.3 tag, WordPress source on GitHub, read 27 October 2026.
get_filesystem_method(), Code Reference, WordPress Developer Resources.
Site Health screen, WordPress.org Documentation.
WordPress.org News: WordPress 7.1.3 Maintenance and Security Release, 6 October 2026; WordPress 7.2 Beta 1 is Ready for Download and Testing, 20 October 2026.
Could Not Create Directory in WordPress: Find the Folder First (2026), Ahosting INC, YouTube, 5 October 2026, and its written guide. Used for the causes and the diagnosis order.
Stop Fake and Spam Email Signups in WordPress, WP Ultimate Security, YouTube, 3 August 2026.
Spam user registration automatically approved even though the registration process requires MANUAL admin approval, r/Wordpress, 18 September 2026. Title shortened.

October 27, 2026

WordPress Core Update Readiness: The Playbook, Step By Step
Open the WordPress dashboard and click Updates.

A new version is waiting, with an Update Now button next to it.

The click is easy. The harder question is which of your active plugins say they were tested with that version, and you would like the answer before you press the button, not after.

Short answer: A WordPress core update means moving to a new version of WordPress itself. A minor release such as 7.1.3 can install in the background on most sites, while a major release such as 7.2 usually waits for you to start it, depending on how the site was set up. Each plugin states which WordPress version it was tested up to. The Major Update Readiness playbook reads that stated version for up to 20 active plugins and your theme from wordpress.org, compares each one with a target version you set, and writes a planning report that rates the site Not ready yet, Check first or Looks ready on paper. It only reads. It starts no update, and “declared compatible” never means the update will go well.

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 and on its public page on 26 October 2026. It is not a result from a real run: no playbook was run for this post, and every plugin name, version and count in it is an illustration with example values.

Minor Releases Install Themselves, Major Ones Usually Wait For You

The WordPress documentation on updating describes two kinds of core update. Minor and security releases can be applied in the background on most sites. For major feature releases, the same page says you still click Update Now yourself.

That is the default most sites follow, not the only one. The developer documentation says installations created on WordPress 5.6 or later get major core updates by default, unless a version control checkout is detected, while older ones keep the old behaviour. So whether 7.2 waits for a click depends on the site. WordPress Auto Updates: Which Ones To Switch On covers how to check yours.

That split matches the release page today. WordPress 7.1.3, released on 6 October 2026, is a maintenance and security release with 7 security fixes and 4 bug fixes, and its notice says sites that support automatic background updates will begin updating automatically. WordPress 7.2 is a different kind of release. Beta 1 came out on 20 October 2026, the notice says not to install or test it on production or mission-critical sites, and the scheduled final release date is 8 December 2026.

So there is a date, and the work comes before it: knowing what is installed and what each plugin says about the new version. After the final release, moving to 7.2 is a major update, which on many sites waits for a click and on some may start on its own.

This post uses 7.2 as the example target because it is the next major release. Neither notice names a plugin, and this post does not test any plugin against 7.2.

What “Tested Up To” Actually Means

Every plugin on wordpress.org carries a readme file, and the developer documentation on how that file works defines the field. “Tested up to” is the version of WordPress that the plugin has been tested against. It ignores minor versions, so a plugin only needs to name the major version, and the plugin directory adds the minor version automatically.

Three things follow from that wording:
- It is a statement by the plugin’s developers. The readme is theirs. The field is a claim about testing, not a check anyone else ran.
- It covers minor releases. A plugin that says it was tested up to 7.1 is covered for 7.1.3, because the field ignores minor versions.
- A lower number is a gap, not a verdict. A plugin that says 7.1 when the target is 7.2 has not declared the new version yet. That can mean a real gap or a readme nobody has updated. The field cannot tell you which, and the playbook does not pretend it can.
The playbook is strict about its words for the same reason. Its step files say “declared compatible” means the plugin’s wordpress.org page says it was tested up to that version, nothing more. They forbid the phrases “will work”, “is safe to update” and “will break”.

The Playbook, Step By Step

The Major Update Readiness playbook has two steps, in a fixed order. In the dashboard it carries a Beta label, sits in the Maintenance group and only reads. The public page files it under Care, says it needs no connector, and says it runs when you start it with no schedule set. This post uses the public page’s category.

A silent walk-through of the two steps. All scenes are illustrations with example values, not a real run.

Set The Target First

You set the target in the playbook’s Instructions with a line like “Target WordPress version: 7.2”. Step 1 takes its major and minor numbers.

Without that line the run stops and checks nothing. Step 1 makes no tool calls at all, and step 2 prints a short “not run” note that says how to add the line. The step files say the playbook never guesses a target and never borrows the plugins’ own tested values as one, because a verdict without a target would mislead.

Step 1: Inventory And Compatibility Lookup

Step 1 is read-only. It does five things, in order:
1. It asks the site, through its REST API, for the active plugins and the active theme. It leaves out Protuno’s own connector plugins, matched by exact folder name, so a plugin that merely has “protuno” in its name is judged like any other.
2. It takes at most 20 active plugins, in alphabetical order by folder name, and looks each one up on wordpress.org. It reads the version, the tested-up-to version, the minimum WordPress version, the PHP requirement and the last-updated date.
3. It looks up the active theme the same way. If the theme returns no tested value, it is “not scored (no compatibility data)”.
4. It sorts each plugin into exactly one class. The first match wins.
5. It flags a plugin as STALE when its last update is 12 months or more old, and notes whether wordpress.org has a newer version than the installed one.
The five classes, in the order the step file applies them:
- NOT ON DIRECTORY: wordpress.org has no listing. The plugin is not scored.
- NOT CHECKED: the lookup failed. The step file says never to call this “not tested”.
- REQUIREMENT CONFLICT: the plugin’s minimum WordPress version is higher than the target.
- NOT TESTED YET: the tested-up-to version is lower than the target. The versions are compared as numbers, so 6.10 counts as higher than 6.9.
- TESTED: the tested-up-to version equals or exceeds the target.
Step 2: Readiness Report

Step 2 makes no calls. It reads the block step 1 produced and writes one planning report. If step 1’s block is missing or step 1 failed, it says “BROKEN CHAIN” and stops.

It counts before it decides. N is the number of NOT TESTED YET plugins, C the number of requirement conflicts and S the number of stale plugins. A plugin that is both NOT TESTED YET and STALE counts in both N and S. The rating then follows fixed rules:

Rating When it applies
Not ready yet Any requirement conflict, or 3 or more NOT TESTED YET
Check first 1 or 2 NOT TESTED YET, or any STALE plugin
Looks ready on paper None of the above

The “Check these first” table is ordered the same way every time: requirement conflicts, then plugins that are NOT TESTED YET and STALE, then NOT TESTED YET, then STALE only, then NOT CHECKED. Every row gets one action. The three allowed actions are “wait for an update that declares” the target, “test on staging first”, and, for stale plugins only, “consider a maintained alternative”.

The report has a fixed layout: a rule-check line that shows N, C and S and the rating they give, the rating, a summary line, the “Check these first” table, the plugins declared compatible, the plugins not scored (with the theme), a “Before you update” list, a “Not checked” list and a closing note that nothing was changed.

How To Read A Rating

The rating is a count, not a prediction. Take an illustrative site with 12 active plugins. If 2 are NOT TESTED YET and none is stale or in conflict, the rating is Check first, because 1 or 2 is Check first. If a third joins them, it becomes Not ready yet. If one plugin requires a higher WordPress version than the target, the rating is Not ready yet even when every other plugin is TESTED.

The rule-check line prints N, C and S so you can see why the rating came out the way it did. The wording “on paper” is deliberate: the best rating still only says what wordpress.org pages declare.

What The Settings And The Public Page Say

The two sources agree on the substance. Both say the playbook only reads, has two steps and needs no connector, and the public page says no step is set to pause for your approval. The only difference I found is the group label: the dashboard says Maintenance, the public page says Care.

I opened the settings panel for both steps in the dashboard, view only. Both show Automatic backup None and Approval checkpoint Off. For a playbook that changes nothing, that fits: there is nothing to back up and nothing to approve.

What The Playbook Does Not Do

The step files and the public page set clear limits:
- It starts no update. It does not edit the site, and it is a planning report only.
- It checks at most 20 active plugins and the theme. Plugins beyond the first 20 are not checked.
- It does not check inactive plugins, custom code inside plugins and themes, or the host’s PHP version against each plugin’s PHP requirement.
- It does not score premium or custom plugins that are not on wordpress.org. They are reported as not on the directory.
- It does not read known issues reported outside wordpress.org.
- “Declared compatible” is not a promise that the update will go well.
Two of those limits are covered by other Protuno posts. A premium plugin that is not on wordpress.org is outside this playbook, and the Premium Plugin Licenses post covers premium plugins whose updates stop quietly. The host’s PHP version is a separate question, and the PHP version post covers it. A plugin that has been pulled from the directory should also come back as not on the directory, and the removed plugin post explains why nobody tells the site.

A Careful Version You Can Do By Hand

You can do the same reading without a playbook. It takes longer as the plugin count grows.
1. Write down the target version, for example 7.2.
2. Open Plugins, filter to Active, and list every plugin and the theme.
3. For each one, open its wordpress.org page and read the Tested up to and Last updated values. For a premium plugin, read the vendor’s changelog or support page instead.
4. Mark each plugin as tested, not tested yet, or not found. Flag anything not updated in 12 months.
5. Take a restore point, and check that it restores. The backup verification post explains why a file with a hopeful name is not a backup.
6. Run the update on a staging copy first and check the front end, forms and checkout. The staging drift post lists what stops a staging copy matching the live site.
7. Know how you would undo it. The rollback post explains what a rollback after an update can and cannot undo.
At 20 plugins, step 3 is 20 page visits and a spreadsheet nobody keeps. That is the repeatable part, and it is the part the playbook takes over. The judgement stays with you: which plugin matters most, and what you will test.

The report’s own closing advice is a restore point, a staging test and plugin updates before the WordPress update. If a site already has two plugins doing the same job, the plugin conflicts post covers a separate read-only report on that.

Two Outside Views

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

Ahosting INC’s “Problems Auto-Updating Plugins and Themes: Fix It (2026)“, published 14 October 2026, is about the Site Health warning “Your site may have problems auto-updating plugins and themes”. It is not about plugin compatibility or core updates. Its useful point is what a green result measures: in the presenter’s account, a pass only means your code is not blocking updates, so a full disk or locked file permissions can still stop real ones.

A clean diagnostic report proves your code and your interface are aligned.
Ahosting INC, Problems Auto-Updating Plugins and Themes: Fix It (2026), auto-generated English captions, 14 October 2026

The parallel is worth keeping in mind. A “tested up to” value and a “Looks ready on paper” rating also measure one narrow thing. The video is a hosting company’s explainer tied to its own blog post.

In an r/Wordpress thread titled “Did your sites actually update to 7.1.2, or do you just have auto-updates turned on?”, the poster argues that the sites that fall behind are often the managed ones, not the neglected ones:

It’s the client site with change control and a staging step, where the 7.1.2 ticket is still waiting on a reviewer who’s on holiday until Monday.
u/Capital_Attention702, r/Wordpress, 30 September 2026

One commenter in the same thread recommends setting WP_AUTO_UPDATE_CORE to 'minor' in wp-config.php, so that urgent security patches arrive without major updates. That matches what the developer documentation says the 'minor' value does. These are people’s accounts, not data. The thread also makes claims about attacks on 7.1.2 that I did not check, so I have left them out. A readiness list is something that reviewer on holiday could pick up and work from.

Where Protuno Fits

The Major Update Readiness playbook is the reading part of this job. It lists the active plugins and the theme, looks each one up on wordpress.org, compares them with a target you set, and writes a rating with a “Check these first” list. It needs no connector, runs when you start it and has no schedule set. It starts no update.

A different playbook, Plugin Safe Update, is the one that applies plugin updates one at a time and then checks the site. The update process post is a written-out sequence for applying updates. Protuno publishes its playbooks as written-out steps you can read first. The playbooks page lists them, and this one has its own page at Major Update Readiness.

The Point

A major WordPress release comes with a date. The plugins on your site each say what they were tested with, and that is information you can read before you press the button.

Set the target, read what each plugin declares, treat a gap as a question, and keep the judgement about what to test first. A rating on paper is a reading list, not a promise.

If WordPress 7.2 were released tomorrow, could you list the plugins on your busiest site that say they were tested with it?

Sources And Further Reading
October 26, 2026

Rating	When it applies
Not ready yet	Any requirement conflict, or 3 or more NOT TESTED YET
Check first	1 or 2 NOT TESTED YET, or any STALE plugin
Looks ready on paper	None of the above

WordPress Auto Updates: Which Ones To Switch On

The Plugins screen has an “Automatic update” column for every plugin. Tools, then Site Health, may say “Your site may have problems auto-updating plugins and themes”. Neither tells you what you most want to know: whether updates are actually arriving.

Two bad arguments dominate: turn everything on, because unpatched sites get compromised, or turn everything off, because one auto-update once broke a client site. Both treat auto-updates as one switch. WordPress documents four types of automatic update, and core splits into three kinds, which makes five decisions on a normal site.

Short answer: core minor and security releases on, and translations on, which is the default. Plugins and themes on for chosen items, once you can say what breaks if that item breaks. Core major releases decided on purpose, because the default depends on when the site was built. Then check the version, not the setting.

What this post is, and is not: a policy framework built from WordPress’s documentation and one community thread. I did not test it on a site, and the commands near the end are read-only ones I have not run. It does not claim any setting is safe on your sites.

Illustration of five cards for WordPress automatic updates: core minor on by default, core major depends on when the install was created, plugins and themes off unless chosen per item, and translations on by default. — Illustration, not a screenshot. The five decisions and the defaults the WordPress documentation gives for them. It is not a measurement of any site.

The Five Decisions, Not One

The admin spreads these across the Updates, Plugins and Themes screens. The documentation describes them like this.

Decision	Where it is controlled	Default, as documented
Core minor and security releases	Updates screen, the `WP_AUTO_UPDATE_CORE` constant, or a filter	On
Core major releases	The same three places	Depends on the install
Plugins	The “Automatic update” column on the Plugins screen, per plugin, or a filter	Off, except special cases
Themes	The theme’s detail view on the Themes screen, per theme, or a filter	Off, except special cases
Translations	Updates screen, or a filter	On

Three notes matter more than they look.

Plugin and theme auto-updates are per item, since WordPress 5.5, so you can update the contact form plugin and leave the booking engine alone.

The “special cases” are real. The documentation says plugins and themes update by default only “in special cases, as determined by the WordPress.org API response, which is controlled by the WordPress security team for patching critical vulnerabilities”. That is the route a forced security push takes, and the same page says a filter returning false switches off even those.

The core major default depends on when the site was built. Before WordPress 5.6, every site got minor core updates and translations only. From 5.6, fresh installations get minor and major updates by default, unless WordPress detects a version control checkout. Existing installations keep the old behaviour unless an administrator, a constant or a filter changes it. So two sites on the same version can differ. That is the documentation’s account; I have not tested it.

Core Minor Releases: On

The documentation describes minor core updates as maintenance and security releases, and says the core developers made “a conscious decision to enable automatic updates for minor releases and translation files out of the box”. It calls disabling them “strongly discouraged”.

The alternative is a person who has to notice an advisory and act on every site, every time, and people go on holiday. The exception is a site so tightly coupled to core internals that a point release is genuinely risky, and that site has a bigger problem than this setting.

Core Major Releases: Decide On Purpose

A major release can change things that page builders, commerce extensions and custom blocks build on. It is a piece of work with a staging test and a date, not a background task. Applied automatically, you learn about a compatibility problem from a visitor instead of from a test.

Because the default depends on the install, decide it explicitly. The documented way to hold a site at minor releases is the constant below: its 'minor' value allows minor updates and blocks major ones.

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

The documentation says this constant overrides the Updates screen, so it can quietly outrank what the screen shows. Write down that you set it: a constant nobody remembers is how a site gets stuck, as the thread below shows.

Holding is not ignoring: a site two majors behind has stopped being conservative and started accumulating a migration. The next major is visible already. WordPress 7.2 Beta 1 came out on 20 October 2026, with the final release scheduled for 8 December 2026, and the notice says not to run it on production sites. Try it on a copy. A commenter in an r/Wordpress thread on that beta, quoted below, puts the priority in one line.

Plugins: Selectively, And Here Is The Sort

A blanket policy does the most damage here. Sort the plugin list into four buckets by one question: what happens on this site when this plugin changes without warning?

Bucket	Characteristics	Auto-update
Low blast radius	Narrow function, no front end output, no checkout path, no custom code depends on it	On
Security critical, low coupling	Firewall, spam, login protection, where being a week behind is the real risk	On
High blast radius	Checkout, payments, booking, membership, page builder, anything the revenue path runs through	Off, test first
Customised or coupled	Your child theme, filters or custom code reach into it	Off, always

The fourth bucket gets forgotten. A plugin can be stable and still break the site on update, because what breaks is your code reaching into it, and on an inherited site nobody recorded that. If an update breaks something and you cannot tell which plugin, Find A WordPress Plugin Conflict Without Downtime is the method.

Two things change the sort. A plugin updated by its vendor instead of WordPress.org depends on that vendor’s licence staying valid: Premium Plugin Licenses: The Updates That Stop Quietly covers a lapse. And a plugin can be pulled from the repository, after which its updates simply stop: When A WordPress Plugin Is Removed From The Repository, Nobody Tells The Site covers that. In both, the setting reads as enabled and nothing arrives.

Themes: Mostly A Non-Decision

An inactive theme you do not plan to use should be removed, as the Site Health screen documentation recommends.

The active theme splits the way plugins do. A theme used as shipped can be a candidate. A theme with changes made inside it must not auto-update, because an update replaces its files. The Theme Handbook says it plainly about editing a parent theme’s functions.php: “the next time your theme is updated, your function will disappear!” A child theme exists for exactly this. If you do not know whether the active theme was edited in place, assume it was until somebody checks.

Before You Turn Anything On

Three things should be real first. Each has its own post.

A restored backup, not a backup job. Without a test restore, auto-updates go on over an untested safety net. See Verify A WordPress Backup, Or You Only Have A File With A Hopeful Name.
A rollback you have reasoned about. See WordPress Rollback After An Update: What It Can Undo, And What It Destroys.
A check that runs after the update. The outcome that matters is the site still working. See The WordPress Update Process, Written Out Before It Runs.

WordPress added a rollback for plugin auto-updates in 6.6, and it is narrow. The testing notes say it “includes the ability to perform rollbacks when fatal errors occur during attempted plugin auto-updates by default”, and that only active plugins undergo the loopback test. A plugin that updates cleanly and then breaks checkout is not a fatal error, so it needs a check of its own.

What An Enabled Setting Does Not Prove

A green setting says the system is permitted to update. It does not say an update has arrived. Three things sit between the two.

Something overrides the setting. The documentation says the WP_AUTO_UPDATE_CORE constant overrides the Updates screen, and that AUTOMATIC_UPDATER_DISABLED turns off every type of automatic update. A .git, .hg or .svn folder in the WordPress directory or a parent counts as a version control checkout, with a filter to override that. A host or plugin can also remove the controls: if they are missing on 5.5 or later, WordPress’s help page says, “it probably means the feature was partially or completely deactivated by your hosting company or by a plugin.”
The schedule never runs. The documentation says auto-updates “rely on WordPress Cron tasks to actually perform the update”, and by default run twice per day. If WP-Cron is switched off and nothing replaced it, nothing triggers: WordPress Cron Not Running: The Failure That Never Alerts You. The poster in the thread below names DISABLE_WP_CRON for this reason.
The update arrives late. A commenter in the same thread says one host batches minor core releases, so an “immediate” update arrived overnight. That is one person’s report, not documented behaviour. Ask your host.

Illustration of three ways a WordPress auto-update setting can read on while the site stays behind: a constant or filter overrides it, WP-Cron never runs, or the host delivers the update late. — Illustration, not a screenshot. Three ways “on” and “up to date” differ. The example lines are the ones named in the documentation and the thread below.

WordPress’s own Site Health test, introduced in 5.5, is described in the code reference as one that “Tests if plugin and theme auto-updates appear to be configured correctly.” Configured, not delivered: a pass is not evidence that the last update arrived. By default WordPress also emails the site owner when plugin or theme auto-updates succeed or fail, so check that address reaches someone who reads it.

Check The Version, Not The Setting

The boring check is to read the version. Recent releases show why.

WordPress 7.0.2, 17 July 2026, fixed one critical and one high severity issue. The notice says: “Due to the severity, the WordPress.org team have enabled forced updates via the auto-update system for sites running affected versions.”
WordPress 7.1.2, 22 September 2026, fixed one critical issue. Its notice says sites that support automatic background updates will start the update automatically, not that it is forced.
WordPress 7.1.3, 6 October 2026, has 7 security fixes and 4 bug fixes, with the same automatic wording.

Note the July wording: forced updates go “via the auto-update system”. The notice does not say what happens on a site where that system is switched off, so the version number is what answers it.

If you can run WP-CLI, these four commands answer most of it. They only read.

wp core version
wp config get WP_AUTO_UPDATE_CORE
wp plugin list --fields=name,version,update,auto_update
wp cron event list

In order, they print the installed version, read the constant from wp-config.php (a site that does not set it follows the defaults above), list each plugin’s version, update status and auto-update state, and show what is scheduled and when it next runs. Without WP-CLI, the Updates and About screens show the version, and Site Health shows cron problems. I have not run these commands for this post; they come from the WP-CLI handbook.

A 33-second silent walk-through: the five decisions, the install-age default, sorting plugins, three ways “on” fails, checking the version, and writing the policy down. All scenes are illustrations with example values.

The PHP Version Underneath All Of It

One constraint sits below every policy here. Core and plugins raise their PHP requirements over time, and no auto-update setting changes the PHP version the host runs. The WordPress PHP Version Problem: A Third Of Sites Get No Security Fixes is about that. Check it before you write an update policy, not after.

Outside Views

A video about the warning. Ahosting INC’s “Problems Auto-Updating Plugins and Themes: Fix It (2026)“, published 14 October 2026, explains the Site Health warning and says it is not about the server. In its account, WordPress runs a stand-in plugin through your update filters and compares the result with whether the “enable auto-updates” link is still shown, and a mismatch raises the warning. A pass, it says, only means your code is not blocking updates, so a full disk or locked file permissions can still stop real ones.

A clean diagnostic report proves your code and your interface are aligned.
Ahosting INC, Problems Auto-Updating Plugins and Themes: Fix It (2026), auto-generated English captions, 14 October 2026

It is a hosting company’s explainer, tied to its own blog post. The mechanism is the video’s account: the code reference says only that the test checks whether auto-updates “appear to be configured correctly”, and I did not confirm the stand-in plugin detail.

A thread from people living with it. In an r/Wordpress thread titled “Did your sites actually update to 7.1.2, or do you just have auto-updates turned on?”, the poster says the reply they keep getting is “auto-updates are on, we’re fine”, and asks readers to check wp-config.php:

If there’s a WP_AUTO_UPDATE_CORE set to false in there, left over from some migration or a dev who wanted control back in 2021, that site hasn’t updated itself since 2021, and nothing in the dashboard is going to tell you.
u/Capital_Attention702, r/Wordpress, 30 September 2026

One reply, from someone who says they checked a few client installs after 7.1.2, found two causes: an old staging habit that left the constant set to false, and a host that batches minor releases. It ends on the same check:

another was on a host that batches minor cores, so “immediate” was more like overnight. wp core version (or just glancing About on each site) is the boring check that actually answers the question.
u/jenish_o4o2, r/Wordpress, 30 September 2026

These are two people’s accounts, not measurements. The thread also makes claims about attacks on 7.1.2 that I did not check, so I have left them out.

A video on the manual routine. BloggersPassion’s “How to Safely Update Your WordPress Website, Themes & Plugins Safely (Step by Step)“, published 16 September 2026, is about updating by hand, not about auto-updates. Its order is a full backup first (shown with UpdraftPlus), a staging copy if the host offers one, one update at a time with a check after each, then core, theme and plugins, and finally the homepage, a blog post and the contact form. That is the routine an auto-update skips, which is why the checks in this post matter.

you will know exactly which update caused it instead of guessing.
BloggersPassion, How to Safely Update Your WordPress Website, Themes & Plugins Safely (Step by Step), auto-generated English captions, 16 September 2026

It is a short beginner tutorial from a blogging site’s team, with about a hundred views when I read it, and it says nothing about how auto-updates behave. I use it only for the one-at-a-time, check-after-each habit.

A thread about the next major release. In an r/Wordpress thread titled “WordPress 7.2 Beta 1 is ready to test”, the poster lists what they like in the beta (more consistent icons, a faster admin, client side media processing support and the secrets API) and asks for thoughts. The replies are a handful of short opinions. One is about the very thing a major update puts at risk:

My favourite feature is not breaking my site, prioritize that.
u/geistly36, r/Wordpress, 22 October 2026

That is one commenter’s wish, not a measurement, and I did not check the poster’s feature list against the beta notice.

Writing The Policy Down

A policy in somebody’s head is not a policy. For each site in your care list, record five lines:

Core minor state, and whether the WP_AUTO_UPDATE_CORE constant is set.
Core major approach and the date it is next reviewed.
The plugin buckets, and which plugins are on auto-update.
Whether the active theme was edited in place.
The date you last read the version number, and the date a backup was last restored.

If someone else runs your updates, WordPress Maintenance Plans: What The Contract Should Name is about what a maintenance contract should name.

What This Does Not Solve

An auto-update policy is a narrow instrument.

It does not make a site secure. Being current is a floor, and an update will not say whether a site is misconfigured or already compromised.

It does not protect against a bad release. If an author ships a broken version, auto-updating means you receive it first, and the 6.6 rollback covers fatal errors, not a page that loads and works wrongly.

It does not prove updates arrive. The absence of an update looks the same as there being nothing to update.

And it does not remove judgement. The sort into buckets is a human reading of one site, which changes whenever a plugin is added or custom work is commissioned.

The Point

Pick any site you manage with auto-updates enabled on at least one plugin. Without opening the dashboard, can you say which WordPress version it runs and when a plugin on it last updated?

If not, the question worth asking is not which switches you have turned on. It is how you would find out if one of them quietly stopped working, and who would notice first: you, or the client?

Sources And Further Reading

Upgrading WordPress, Configuring Automatic Background Updates, WordPress Developer Resources, page read 26 October 2026.
Plugin and themes auto-updates, WordPress.org Documentation, page read 26 October 2026.
WP_Site_Health::get_test_plugin_theme_auto_updates(), Code Reference, WordPress Developer Resources.
Help test WordPress 6.6, Make WordPress Test, 3 June 2024 (Rollback Auto-Updates).
WordPress.org News: WordPress 7.0.2 Release, 17 July 2026; WordPress 7.1.2 Release, 22 September 2026; WordPress 7.1.3 Maintenance and Security Release, 6 October 2026; WordPress 7.2 Beta 1 is Ready for Download and Testing, 20 October 2026.
Child Themes, Theme Handbook, WordPress Developer Resources.
Site Health screen, WordPress.org Documentation.
wp core version, wp config get, wp plugin list and wp cron event list, WP-CLI Handbook.
Problems Auto-Updating Plugins and Themes: Fix It (2026), Ahosting INC, YouTube, 14 October 2026.
Did your sites actually update to 7.1.2, or do you just have auto-updates turned on?, r/Wordpress, 30 September 2026.
How to Safely Update Your WordPress Website, Themes & Plugins Safely (Step by Step), BloggersPassion, YouTube, 16 September 2026.
WordPress 7.2 Beta 1 is ready to test, r/Wordpress, 20 October 2026.

October 26, 2026

WordPress Featured Images: The Playbook, Step By Step
Open a published post in the editor and look at the sidebar.

Where a thumbnail should be, there is a link that says Set featured image.

On one post that is a small gap. On a site with a few hundred posts, it is a list nobody has ever written down.

Short answer: A WordPress featured image is the single picture that represents a post, page or custom post type. Posts published without one show a gap wherever a theme or block expects it. The Bulk Featured Images playbook finds published posts that have none, matches each to an image already in your media library by name, and sets the image only when the match is clear: one image, not used on another post, from a title of at least two key words. It never uploads, generates or replaces an image.

What this post is, and is not: A method write-up of one playbook that can change the site, based on its two step files as shown in the Protuno dashboard and on its public page on 23 October 2026. It is not a result from a real run: no playbook was run for this post, and every post title, image name and count in it is an illustration with example values.

What A WordPress Featured Image Is

The WordPress theme handbook defines featured images, also called post thumbnails, as images that represent an individual post, page or custom post type. A theme can show one on an archive page, in a header or above a post.

Two details from the handbook matter here:
- A theme must declare support for featured images before the Featured Image interface appears on the Edit screen. The handbook shows this as a line of code in the theme’s functions file.
- Once support is declared, the Featured Image meta box shows in the sidebar of the Edit Post and Edit Page screens. If a user cannot see it, they can turn it on in their screen options.
Under the hood, the REST API describes the field as featured_media, “The ID of the featured media for the post”, an integer. The playbook’s step files use that same field. A post with featured_media of 0 has no featured image, which is how step 1 finds its candidates. For writing, WordPress has a core function, set_post_thumbnail(), that “sets the post thumbnail (featured image) for the given post.”

In block themes, the Post Featured Image block displays the image. The block documentation says it is primarily nested inside a query loop block.

Latest changes checked on 23 October 2026: WordPress 7.1.3 (6 October) is the current stable release, and 7.2 Beta 1 came out on 20 October. Neither announcement mentions featured images. So everything above comes from the theme handbook, the REST API reference and the block documentation, not from release notes.

Why Posts End Up With None

There is no single cause, and this post did not measure any of them. Three ordinary routes are enough to explain a long list:
- The post was written before the theme declared featured image support, so the box was never on the screen.
- The post was imported or created in bulk, and nobody opened it afterwards.
- The author left the Set featured image link alone, because the post looked fine without it.
None of those throws an error. The only sign is a missing picture where a layout expects one.

Why It Matters Beyond The Thumbnail

A missing featured image can show up in a theme’s archive page, in a Post Featured Image block, and in links shared elsewhere.

A post on WordPress Open Graph tags covers six ways share previews break silently. A forum thread covered below shows the same problem from a site owner’s side: links to a blog showing a random uploaded image as the thumbnail. One reply there says the cleanest fix is to set a featured image on each post you actually share. That thread is about a WordPress.com free plan, so the options on a self-hosted site differ.

A featured image also needs its own alt text. A post on an image alt text audit shows how a crawl reported 17,261 images missing alt text when the real count on those pages was zero. Counting images is harder than it looks.

The Playbook, Step By Step

The Bulk Featured Images playbook has two steps, in a fixed order. In the dashboard it carries a Beta label and can change the site. The public page files it under SEO and says it needs no connector, while the dashboard lists it under Content. This post uses the public page’s category. It runs when you start it, and no schedule is set.

A silent walk-through of the two steps. All scenes are illustrations with example values, not a real run.

Step 1: Find And Snapshot Matches

Step 1 is read-only. The step file says it writes nothing, and that step 2 makes the change straight after it.

It works in a fixed order:
1. It lists published posts, newest first, 50 at a time, asking only for the id, the title and featured_media. It pages through at most 6 pages, which is 300 posts.
2. It keeps the posts whose featured_media is 0. These are the candidates, newest first. It checks at most 25 and counts the rest as “remaining”. It also notes every image id that is already some post’s featured image.
3. For each candidate, it takes the post title in lower case, removes punctuation, and removes a list of filler words. What is left are the title’s key words.
4. For each candidate, it searches the media library for images, with those key words as the search. The step file says WordPress returns only images whose name contains every word. It sends up to six of these searches at a time.
If a reply is cut off, the step asks again with half the page size. It never matches against a cut list.

The step file calls the key words “dish words”, and its filler list includes words such as recipe, homemade, creamy and crispy. It reads as written with recipe-style titles in mind. Other titles are matched the same way, so the result depends on image names resembling titles.

The Three Outcomes

Step 1 sorts each candidate by the number of results, with no judgement involved:
- HIGH: exactly one image matches, that image is not already used as another post’s featured image, and the title has at least two key words. Only HIGH is ever applied.
- MEDIUM: two or more images match, or the one match is already used on another post, or the title has only one key word. MEDIUM is never applied. It is listed for a person.
- NONE: no image matches.
Three outcomes for a post with no featured image. Example titles and image names, not a real run.

Step 1 ends by handing step 2 a fixed block. It holds the scanned count, one line for every post it checked, the list to apply, and the number remaining. The step file requires one line for every candidate searched, so the block can be checked against the count.

Step 2: Apply And Verify

Step 2 reads that block and does three things.

First, it re-checks the posts on the apply list in one call. A post whose featured_media is no longer 0, or that is missing, is skipped as “changed since the scan”. It is never written.

Second, for each remaining post it makes one write with the post id and the image id, and nothing else. The step file says the write records the post’s previous value, which is what the run’s Rollback restores. A write that errors is marked failed, and the step keeps going.

Third, it reads the posts back. A post counts as set only when its featured_media now equals the image id.

The step stops without writing in three cases. If the block from step 1 is missing or step 1 failed, it reports a broken chain. If step 1 produced more than one apply list, it reports a broken chain, because the list cannot be trusted. If the apply list says none, it reports “Nothing to apply”.

The two steps and what each hands on. Settings as shown in the dashboard, not a real run.

The report has a fixed layout. A summary line gives the counts for set, skipped, failed, to review, no match and left for the next run. Then come tables for the images set, the posts skipped or failed, the posts to review and the posts with no match, and a closing note on how to undo.

What The Settings And The Public Page Say

This is the one place where the sources disagree, so read it closely.

The public page says a run you start pauses before step 2 and waits for your approval. It also says a scheduled run skips step 2, so a scheduled run never makes the change.

I opened the settings panel for both steps in the dashboard. Both show Automatic backup None and Approval checkpoint Off. The dashboard’s card text also says the playbook waits for your approval.

This post does not decide which is right. Before a first run on a live site, check the Approval checkpoint setting on your own copy of step 2. The undo that step 2’s file describes works from the recorded before-value for each post, which for these posts is “no featured image”, not from a backup.

What The Playbook Does Not Do

The step files and the public page set clear limits:
- It never uploads or generates an image, and it never replaces an existing featured image.
- It changes one field only, the featured image. It sends no title, content, excerpt, status or meta.
- It scans at most 300 of the newest published posts and checks at most 25 per run, so a large backlog takes several runs.
- It never sets an image on a MEDIUM or NONE post. Those are listed for you.
- It does not judge the picture. A name match is a hint about a file name, not proof that the image fits the post.
- It does not look at image size, format or alt text.
That last limit is worth planning for. A post on an image weight audit found a page carrying 2,590 KB of images, with a single 794 KB file still being served. A matched image can still be a heavy one.

A Careful Version You Can Do By Hand

You can do a rough version of this without any playbook. It follows the same order.
1. Request your published posts from the REST API, asking only for id, title and featured_media, for example /wp-json/wp/v2/posts?per_page=50&_fields=id,title,featured_media. Posts with a featured_media of 0 have no featured image.
2. For each of those, take the key words from the title and search the media library by those words.
3. If exactly one image comes back, check it is not already the featured image of another post, and look at the picture before you use it.
4. If two or more come back, or the title is one word long, decide by eye and write down why.
5. Open the post, choose Set featured image, pick the image and save.
6. Write down the before-value for every post you change, which is “none”, so you can undo it.
7. Share one updated link and look at its preview. Platforms cache old previews, so a link shared before the change can keep showing the old one.
Seven steps for 25 posts is why such a list tends not to get written. That is the part a playbook takes over.

If your bigger worry is unused files in the library, the Unused & Duplicate Media playbook post covers the other side of the library. If you want to see how other playbooks handle changes in small batches, the Disable Comments post and the Find And Replace post each describe a two-step playbook that plans changes and waits for you.

Two Outside Views

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

In a September 2026 video, the Quick Tutorials Vault channel shows how to add a featured image in WordPress. The presenter goes to Posts, picks a post, clicks Edit, and points to the Set featured image option on a post that has none. The presenter then selects the image, saves, and uses View post to confirm the image appears. It is a one-post, by-hand method, which is the baseline this playbook is compared against. The video does not cover finding posts that have no featured image.

On Reddit, an r/Wordpress thread titled “How to set the image that shows up in my link thumbnails?” starts with a blog owner whose shared links showed “no title” and a random uploaded image as the thumbnail. A reply says:

“the cleanest option without wrecking your homepage is to set a featured image on each post/page you actually share, not on the home page.”
Reply in the thread, r/Wordpress, 8 October 2026

The same reply adds that the poster is on a WordPress.com free plan, where control over the social image is limited, and that Facebook and iMessage can keep showing an old preview until you refresh it in their debugger. The thread is about that plan, so treat it as one site owner’s problem, not a rule for every WordPress site.

Where Protuno Fits

The Bulk Featured Images playbook is the repeatable, bounded part of this job. It finds published posts with no featured image, matches them to library images by name, and sets only clear one-image matches, at most 25 per run, then reads each change back and records the before-value so it can be rolled back. It needs no connector, runs when you start it, and has no schedule set.

Protuno publishes its playbooks as written-out steps you can read first. The playbooks page lists them, and this one has its own page at Bulk Featured Images. If the undo model is your main concern, a post on rollback after an update explains why restoring files and restoring a database are not the same decision.

The Point

A featured image is one field on a post. Nobody notices it is empty until a layout, an archive or a shared link shows the gap.

Find the empty ones, match only what is clear, change nothing else, and keep the before-value so any change can be undone. The matches that need a human eye should go to a human.

How many of your published posts would show a gap if you asked for the ones with no featured image today?

Sources And Further Reading
October 23, 2026

Find A WordPress Plugin Conflict Without Downtime

Picture a site with twenty-six active plugins. A page has stopped working. The screen either says “There has been a critical error on this website.” or says nothing at all, and a button simply does nothing.

You suspect a plugin. The usual advice is to switch every plugin off, then switch them back on one at a time. That works. It also means up to twenty-six checks, and a site stripped of its features for as long as the walk takes.

Short answer: do the test on a copy of the site, not the live one. If the fault only shows on live, pause the plugins for your own browser session instead. Then halve the list each round rather than walking it. Twenty-six plugins is about five rounds and one confirming check, not twenty-six checks.

What this post is, and is not: this is a method for finding which plugin is involved in a fault you can reproduce. It names a suspect, it does not fix anything. Knowing that two plugins clash does not tell you which one should change, and sometimes the cause is not a plugin at all. It does not cover faults that come and go, which need logs and time rather than toggling.

Illustration comparing a walk through 26 plugins, up to 26 checks, with halving the list, five rounds that leave 26, 13, 7, 4 and 2 candidates before each round. — Illustration, not a screenshot. The same 26 plugins, searched two ways. The counts are arithmetic, not a measurement.

Why The Usual Advice Needs One Edit

The official guidance already says most of this. The Learn WordPress lesson on plugin and theme conflicts tells you to take a backup, make a staging site, read the error log, try a default theme, then deactivate all plugins and reactivate them one at a time while checking the site after each one. WordPress.com’s own video on the same problem says you can do it on the normal site, “but I suggest using a staging site.”

So the advice is sound. Two things get lost when it is repeated in one line: where you do it, and how many steps it takes.

On a personal blog neither matters. On a site that takes orders, switching every plugin off is a visible change for every visitor. WordPress also lets plugins run their own code when they are activated or deactivated, which is one more reason to do the toggling somewhere nobody is watching.

This method assumes you can still reach the dashboard. If you cannot, start with WordPress White Screen Of Death: The Playbook, Step By Step and come back. And if you are asking which plugins overlap rather than which one is broken, that is a different question, covered in WordPress Plugin Conflicts: The Playbook, Step By Step.

Decide Where To Test First

The right place depends on who can see the fault.

Where the fault shows	Test here	Why
For every visitor	A staging copy	You can break it freely
Only when logged in	A staging copy, or a session pause	It depends on your session or role
Only for anonymous visitors	A staging copy	A paused session is yours, not the visitor’s
Only on live, never on the copy	A session pause on live, and treat the copy as the bug	The copy differs from live in some way

The last row matters most. A fault that lives on production but not on a fresh copy is often environmental rather than a plugin pairing.

A 33-second silent walk-through: where to test, the session pause and its limits, halving the list, the record sheet, and what isolation does not do. All scenes are illustrations, and the plugin counts are arithmetic, not a measured result.

Method One: Reproduce It On A Copy

Take a staging copy, and before you touch a single plugin, confirm that the copy shows the same fault. If it does not, you have learned something useful instead of wasting an hour.

The usual reasons a copy behaves differently:

A different PHP version.
A different object cache, or none.
A licence key that is only valid on the live domain.
A CDN or firewall in front of live that the copy does not have.
Data that exists only in the production database.

WordPress Staging Site: What Drifts From Live is about exactly these differences. Before you change anything, take a backup you could restore. Verify A WordPress Backup, Or You Only Have A File With A Hopeful Name is about what “could restore” has to mean.

One current reason to have a working copy: WordPress 7.1.3 (6 October 2026, 7 security fixes and 4 bug fixes) is the current stable release, and its notice does not mention plugin changes. WordPress 7.2 Beta 1 came out on 20 October, with the final release scheduled for 8 December 2026. The beta notice says not to run it on production and to use a test environment instead. A copy that can run a beta is also a copy you can bisect on.

Method Two: Pause Plugins For Your Session Only

Sometimes the fault only exists on live, and you have to work there. WordPress has a supported way to do that without changing what visitors see.

The Health Check & Troubleshooting plugin describes a troubleshooting mode like this:

Troubleshooting allows you to have a clean WordPress session, where all plugins are disabled, and a default theme is used, but only for your user until you disable it or log out.
Health Check & Troubleshooting, WordPress.org plugin directory, page read 23 October 2026

There is a catch, and the page states it. When I read it on 23 October 2026 it showed version 1.7.1, 200,000+ active installations, “tested up to” 6.6.10 and “last updated 2 years ago”, under a banner saying the plugin has not been tested with the latest three major releases of WordPress and may no longer be maintained. I have not tested it on 7.1. It may work fine, so try it on a staging copy before you rely on it on a client’s live site.

Two limits apply to any session-scoped pause.

First, it only helps with faults you can see while logged in as yourself. A fault that only affects anonymous visitors will not show inside your own paused session, because you would be testing a setup no visitor is using.

Second, some plugins cannot be paused from the plugin list. Must-use plugins are enabled automatically on every site, do not appear in the default plugin list, and cannot be disabled from wp-admin. To disable one you remove its file from wp-content/mu-plugins. Hosts commonly use them for their own features. I have not tested whether a session pause leaves them running, so check the Must-Use section of your own Plugins screen before you trust a “clean” session.

Method Three: Halve The List, Do Not Walk It

Whichever place you test in, stop switching plugins one at a time.

Write down every active plugin and its version.
Switch off half of them, and test the broken page.
If the fault is gone, the suspect is in the half you switched off. If it is still there, the suspect is in the half you left on.
Take the suspect half, split it, and repeat.
When one plugin is left, switch it off and on once more and check that the fault goes and comes back.

Active plugins	Walking the list, worst case	Halving, rounds
8	8	3
16	16	4
26	26	5
50	50	6

That table is arithmetic: each round removes half the candidates. In practice each round is a page load, probably a cache clear, and a person checking carefully. The saving grows with the list.

Keep related plugins in the same half. WordPress 6.5 added a “Requires Plugins” header: a plugin that declares it cannot be activated until the plugins it needs are active, and a plugin that others need cannot be deactivated while they are active. That only covers plugins that declare it. For shop add-ons and builder add-ons that do not, check by hand which one needs which parent, and put them together.

A genuine conflict involves two plugins, and switching off either one can make the fault vanish. Halving finds one of them. Once you have a suspect, put it back on, then switch off plugins that do a related job and see whether the fault goes that way too. Two different plugins that each cure it when switched off alone are your pair.

Write each round down as you go: which plugins were off, which page you tested, whether the fault was still there, and the time. By round four you will not remember round one, and a wrong note sends you down a branch that cannot hold the answer.

A blank record sheet for a plugin bisection with header fields for environment and versions, and five empty rows for plugins switched off, page tested, whether the fault was still there, and time. — Illustration of a blank sheet. No results are shown. Keep it as a plain text note if you prefer.

Read The Log Once First

Before any toggling, turn on logging and reproduce the fault once. The WordPress handbook’s example sets WP_DEBUG and WP_DEBUG_LOG to true and WP_DEBUG_DISPLAY to false, which writes errors to wp-content/debug.log and keeps them off the page.

A fatal error line names a file, and a path under wp-content/plugins/ names the plugin. That can end the search in one step. Afterwards, check that the log is not publicly readable: Is Your WordPress Debug Log Exposed Right Now? is about that.

An empty log does not clear the plugins. A conflict that produces wrong output rather than an error can leave nothing in the PHP log, and the browser console is the next place to look. Some failures leave no log at all, as the thread below shows.

Two Outside Views

A video from the platform side. WordPress.com’s own video, “What to Do When a WordPress Plugin or Theme Isn’t Working“, published 28 July 2026, follows the standard route. It deactivates the plugin WordPress names, uses recovery mode if the dashboard is unreachable, and for an unknown conflict deactivates all plugins, switches to a default theme and reactivates them one by one. On where to do it, the English captions say:

You can do this on your normal site, but I suggest using a staging site.
WordPress.com, What to Do When a WordPress Plugin or Theme Isn’t Working, English captions, 28 July 2026

It is a hosting company’s tutorial for its own platform, so the screens are theirs. The method is the general one.

A thread from people living with it. In an r/Wordpress thread titled “This error occurs when I activate certain plugins”, the poster gets a 500 error after activating plugins and says they have already tried deactivating all other plugins and themes. One reply starts where this post does:

Enable your debug.log – in the majority of cases, it’s a PHP error happening and this will show up in your debug.log.
u/jedidave, r/Wordpress, 30 July 2026

Another reply, from someone who says they are a developer at SeedProd, one of the plugins in the thread, points out that there may be no log to find, because a hosting resource limit can end the PHP process before it writes an error:

That pattern points at a resource ceiling rather than a bug in either plugin.
u/nick_kimuli, r/Wordpress, 30 July 2026

That is one person’s diagnosis, and it comes from a plugin vendor, so treat it as a lead to check with the host, not a verdict. It does show a useful outcome of isolation: the answer can be “not a plugin”.

What This Does Not Solve

Isolation names a suspect. It does not do any of the following.

It does not say which plugin is at fault. In most real conflicts both plugins behave to their own specification and the combination fails.

It does not help with intermittent faults. If the problem appears for one visitor in fifty, a round that passes proves nothing, because you may simply not have hit it.

It does not explain a fault that started with an update. Then the question is what changed, not which plugins clash. The WordPress Update Process, Written Out Before It Runs is about recording the before state, and WordPress Rollback After An Update: What It Can Undo, And What It Destroys is about what a rollback does and does not restore.

It does not help when the plugin no longer gets fixes. You can isolate it perfectly and have nowhere to go. When A WordPress Plugin Is Removed From The Repository, Nobody Tells The Site covers that case.

It does not cover causes outside plugins, such as the PHP version or a host limit, which the Reddit thread above is about.

And it does not reduce the number of plugins. A site with fifty active plugins will have another conflict.

The Point

Finding the plugin is a skill. Doing it somewhere nobody is watching is a habit.

So for the site in your care list with the most active plugins: if a page broke this afternoon, could you reproduce it on a copy, or would you start switching plugins off on the live site?

And if the answer is the copy: when did you last check that it still behaves like live?

Sources And Further Reading

WordPress 7.1.3 Maintenance and Security Release, WordPress.org News, 6 October 2026.
WordPress 7.2 Beta 1 is Ready for Download and Testing, WordPress.org News, 20 October 2026.
Health Check & Troubleshooting, WordPress.org plugin directory, page read 23 October 2026 (version 1.7.1).
Troubleshooting your site: Plugin and theme conflicts, Learn WordPress.
Debugging in WordPress, Advanced Administration Handbook, WordPress Developer Resources.
Must-Use Plugins, Advanced Administration Handbook, WordPress Developer Resources.
Introducing Plugin Dependencies in WordPress 6.5, Make WordPress Core, 5 March 2024.
Activation / Deactivation Hooks, Plugin Handbook, WordPress Developer Resources.
What to Do When a WordPress Plugin or Theme Isn’t Working, WordPress.com, YouTube, 28 July 2026.
This error occurs when I activate certain plugins, r/Wordpress, 30 July 2026.

October 23, 2026

WooCommerce Shipping Zones: Regions That Cannot Check Out

A payment gateway failure makes noise. The order fails, a customer emails, and somebody notices within the day.

A shipping zone gap makes almost none.

A customer in an uncovered region fills a cart, enters an address, and gets a sentence. On the cart it reads “No shipping options were found for” and then the address. At checkout it reads “There are no shipping options available. Please ensure that your address has been entered correctly, or contact us if you need any help.” Many customers take that as a typo, retype the address once, and leave.

From the store’s side, nothing failed. No order was placed, so nothing sits in the orders list. The store owner’s week looks normal.

Short answer: a WooCommerce shipping zone only serves the regions listed in it, and a customer is matched to the first zone, from the top of the list, whose regions fit their address. If that zone has no method available for their cart, they get the “no shipping options” message and the search stops there. Find the gaps by listing your zones in order against where your orders and traffic come from, then test an address from each suspect region on a staging copy.

What this post is, and is not: this is a mapping exercise and a test you can run on a staging copy of a store, using your own zone settings and your own order history. It does not tell you what to ship, where, or at what price. It tells you which regions currently resolve to no usable method, which is a different and more answerable question.

A shipping zone list read from top to bottom. An address enters at the top and stops at the first matching zone, Domestic. The Local zone below it is greyed out and never reached. A Rest of the world box sits at the bottom. — Illustration, not a screenshot. The zone names are examples.

How The Matching Actually Works

Zones feel like a list of places you ship to. They behave like a routing table.

WooCommerce’s documentation says it plainly: a customer is assigned the first zone they match, and each customer matches only one zone. They are offered only the methods inside that zone, not the methods from every zone that could have fitted. The matching code agrees: it sorts zones by their saved order and takes the first match.

Three consequences follow, and each produces a real gap.

Order matters. A broad zone placed above a narrow one swallows it. A zone for a whole country sitting above a zone for one postcode range inside that country means the narrow zone’s rates are never offered. The list is drag-sorted, so it can drift whenever somebody adds a zone in the wrong place.
A match with nothing usable is still a match. If the winning zone has no method, or only methods that are switched off or not yet earned, the customer is not passed down to the next zone. They are matched and then offered nothing.
The bottom zone is where everyone else lands. WooCommerce keeps a default zone called Rest of the world for any address no other zone matched. Adding methods to it is optional, so on a store that never added one, every unlisted region gets the same message.

An empty zone is not always a mistake. The documentation describes it as the way to exclude a region when you use Rest of the world: add a zone for the region with no methods, and customers there are told no shipping is available. So the question is not “is there an empty result”. It is “was each empty result a decision”.

The Conditions That Hide Inside A Zone

A zone can look right in the admin and still hand the customer nothing, because a method can exist and not be available for a given cart.

What is set	What the customer sees	Where to look
A method switched off in the matched zone	The zone looks populated in the list, and the customer gets nothing from it	The Enabled toggle on each method inside the zone
Free Shipping set to need a minimum order amount	Under the threshold, Free Shipping is not offered	The “Free Shipping requires” setting on the method
Free Shipping set to need a coupon	Nobody without the coupon sees it	The same setting, plus the coupon’s own free shipping option
A zone limited by postcode	An address just outside a range or wildcard falls through to a lower zone	The zone’s postcode list, which takes ranges and wildcards, one entry per line
A shipping extension with its own rules	Rates that depend on conditions the core settings do not show	The extension’s settings, after the core ones look right
No address entered yet	The line “Enter your address to view shipping options” in the shipping section. Normal, not a gap	The Shipping options setting named “Hide shipping costs until an address is entered”

If Free Shipping is the only method in a zone, a cart under its threshold has no method at all, which looks identical to a missing zone. Every row except the last ends at the same empty section, and nobody can tell the causes apart without the cart and address that reproduce it.

One more setting sits upstream. The General settings page has a Shipping location(s) option, and the zone documentation says to check it before building zones. If it is wrong, no zone edit will fix what customers see.

Mapping Zones Against Where Orders Come From

A gap only matters where there is demand. A store that does not ship to a country nobody orders from has no problem. A store that cannot serve a region with steady traffic has an expensive one. Build one table with a row per region.

Export your orders. Pull the last twelve months and count them by country, and by region for your largest countries. This demand map is biased on purpose: it only contains people who could finish an order, so the regions missing from it are the suspects.
List your zones in their saved order. Write down each zone, its regions and postcode limits, and every method inside it, including methods switched off or carrying a condition from the table above.
Pull sessions by region. A region with real sessions and no orders at all is the strongest signal you have.
Mark each region as served by a zone with a method that works for a normal cart, served only by a conditional method, or falling to Rest of the world.

The output you want is not this:

“We have seven shipping zones configured.”

It is this:

“These regions produced sessions last quarter and no orders, and each falls through to a zone with no available method. Here is the address that reproduces it.”

The second names the regions and the cause and comes with a reproduction. That is a bug report. The first is an inventory.

A blank record table with columns Region, Sessions, Orders, Matched zone and Method offered, and four empty rows. One row is outlined in red with the note Sessions, no orders: test this first. — Illustration of a blank sheet. Nothing on it is a measured result.

Testing An Uncovered Region On Purpose

Mapping gives you suspects. A test gives you proof.

Use a staging copy that carries the live zone settings. A test on a stripped-down site with different zones tells you nothing, and a copy keeps abandoned carts and test customers out of the store’s real data.

Pick one address per suspect region, in a real format for that region. An invalid postcode produces a validation error that looks like a zone gap and is not.
Add a product that needs shipping to the cart, enter the address, and write down exactly what the shipping section shows.
Repeat with a second cart at a different value, to catch a Free Shipping threshold.
Repeat with a product from a different shipping class. Classes group products so a method such as Flat Rate can charge them differently, so a class is a variable worth varying.
Repeat on a cart with only a virtual product, which should not ask for shipping at all.
If you use a shipping extension, repeat with a heavy or bulky product.
Record each combination: region, cart, zone matched, methods offered.

WooCommerce has a switch that helps. Under the Shipping options settings there is a debug mode which, in the setting’s own words, shows matching shipping zones and bypasses the shipping rate cache. Rates are cached, so a retest can show yesterday’s answer without it. Turn it off afterwards. A walkthrough published on 20 October 2026 notes that the matched-zone notice appears on the classic Cart page and not in the Cart or Checkout blocks, so its absence is not a failed test.

Six to eight combinations per suspect region takes an afternoon and leaves you exact addresses and carts that reproduce each failure. That list makes a fix verifiable.

A checkout walk you can safely repeat is worth building once, and building a WooCommerce checkout probe safe to run daily covers how. That post is candid about its own limit: the probe will not catch a shipping method failing for one country, which is the gap here. Why an uptime ping cannot do this job is covered in an uptime check cannot see this. If you look after stores you did not build, detecting WooCommerce from the outside tells you which ones to test first.

Illustration. The example zones, regions and amounts are made up, and nothing in the video is a measured result.

Fixing It Without Promising Delivery You Cannot Make

The fix is not always “add a shipping method”. Sometimes the right answer is that you do not ship there, and the job is to say so sooner.

Situation	Reasonable fix
You do ship there and the region was simply missing	Add the region to a zone, or create one with a method and a rate
A broad zone above is intercepting a narrower one	Reorder the zones so the narrower one is matched first
You ship there only above a value, on purpose	Keep the threshold, and make sure the customer is told about it somewhere other than an empty section
You do not ship there at all	Leave the empty zone in place on purpose, and consider a notice that says so before the customer fills the form
The method exists but is switched off	Switch it on, then repeat the exact test that failed

The fourth row is the one stores resist and customers appreciate. An explicit “we do not currently deliver to this region” beats a message that sounds like a typo, and a deliberate zone is something you can find later.

Whatever you change, re-run the exact address and cart that failed. “The zone was updated” is not the same as “this address now sees a method and can complete an order”.

What Changed Recently

WordPress 7.1.3 shipped on 6 October 2026 and 7.2 Beta 1 followed on 20 October. Neither announcement mentions shipping. WooCommerce 11.2.1, released on 9 October 2026, lists two fixes: how classic checkout sends order review and coupon requests, and acceptance of older four-digit Argentine postcodes in the Checkout block. The postcode fix is about validation, not zone matching, so nothing above depends on a recent change.

What This Does Not Solve

This finds regions that cannot check out. It does not find most other ways a checkout quietly stops working.

It is a configuration check, not monitoring. It is true on the day you run it. A plugin update or an edit by someone else can reopen a gap next week.
It cannot see demand that never arrived. A region with no sessions because the store was never marketed there shows nothing. No traffic is not the same as no market.
Tax and address validation are separate. A region can have a working method and still fail on a tax setting or an address field rule. Different symptom, different check.
It says nothing about payment. A customer who sees a method and then cannot pay has hit a different wall, covered in payment gateway monitoring.
It does not catch orders that start and then fail. Those are visible, and worth watching separately, which is the subject of WooCommerce failed orders.
Caching can make a result lie. A cached page that serves one customer’s cart state to another can hide what real customers get. That failure has its own article: one URL, two customers.

Two Outside Views

A video that turns the same idea into six checks. Cobalt Branch Labs’ “WooCommerce Shipping Methods Missing at Checkout? Check These 6 Things“, published 20 October 2026, runs about five minutes. Its order is: reproduce the failure with the exact address and cart, check which zone matches including zone order and postcode rules, confirm the method is enabled inside the matched zone, check the Free Shipping requirement, check that the cart holds products that need shipping, and retest on staging after every change. Its staging example shows the first-match point: with a broad domestic zone above a local one, the same address matched the broad zone first, and the expected local method went missing until the zones were reordered. The description is upfront that the settings panels are illustrative and the outcomes were checked through WP-CLI and cart calculations, not recorded storefront sessions. It is a small channel, so treat it as a checklist.

A thread from people living with it. In an r/woocommerce thread titled “WooCommerce delivery methods/rates not appearing, even on new checkout shortcode page”, the author reports that the zones and methods are all set up and the checkout still shows no delivery rates:

WooCommerce shipping zones and delivery methods are set up, products are physical/not virtual, and shipping is enabled. The checkout is built with Elementor/JetWooBuilder. The order review shows product, total and payment, but no Standard/Express delivery methods or delivery rates appear.
u/SoloUncharted, r/woocommerce, 9 July 2026

That is a useful counterweight. The author says the zones and methods are set up and suspects a page-builder checkout is overriding WooCommerce’s own, so a clean zone check does not end the hunt. It is why the video above puts themes and checkout customisations last. The replies suggest looking for a checkout template in the Elementor theme builder, and checking the zone, caches and other plugins. The author answered with thanks only, so the thread does not confirm a fix.

Sources And Further Reading

Setting up Shipping Zones, WooCommerce documentation.
Free Shipping, WooCommerce documentation.
Product Shipping Classes, WooCommerce documentation.
cart-shipping.php, the WooCommerce template that holds the two “no shipping options” messages, read on the main branch on 22 October 2026.
WooCommerce plugin page, WordPress.org, version 11.2.1 and its changelog.
WordPress 7.1.3 Maintenance and Security Release, WordPress.org News, 6 October 2026.
WordPress 7.2 Beta 1 is Ready for Download and Testing, WordPress.org News, 20 October 2026.
WooCommerce Shipping Methods Missing at Checkout? Check These 6 Things, Cobalt Branch Labs, YouTube, 20 October 2026.
WooCommerce delivery methods/rates not appearing, even on new checkout shortcode page, r/woocommerce, 9 July 2026.

The Point

A payment failure announces itself. A shipping zone gap is the opposite: the customer reads one sentence, assumes it was their typo, and goes.

So the question is not how many zones you have. It is simpler and less comfortable: which regions send you visitors and no orders, and has anyone ever entered an address from one of them and read what the checkout said?

October 22, 2026

Author: Aditya Sharma

What the Memory Limit Error Actually Means

WordPress Memory Limit vs PHP Memory Limit

Check Your Current Memory Limit First

Method 1: Raise WP_MEMORY_LIMIT in wp-config.php

Method 2: Change memory_limit in php.ini or .user.ini

Method 3: Use .htaccess on Apache

Method 4: Ask Your Host to Raise It

When a Higher Limit Does Not Fix It

How Much Memory Do You Actually Need

Safe Order of Operations

Two Outside Views

A Careful Version You Can Do By Hand

The Point

Sources And Further Reading

What The WP Doctor Playbook Is

Step 1: Gateway And Environment Probe

Step 2: Reproduce And Health Baseline

Step 3: Collect Evidence And Match Signature

Step 4: Safety Snapshot And Apply Fix

Step 5: Verify And Report

What The Playbook Does Not Do

A Careful Version You Can Do By Hand

Two Outside Views

Where Protuno Fits

The Point

Sources And Further Reading

The Screen That Started This Check

What Crawl Depth Actually Counts

Why Depth Zero Is The Homepage, Not The Logo

How Google Treats A Page Three Clicks Deep

Where Depth Quietly Grows: Menus, Pagination, Tags

Measuring Crawl Depth On Your Own Site

Three Fixes That Do Not Require A Redesign

What Shallow Crawl Depth Does Not Solve

A Careful Version You Can Do By Hand

Two Outside Views

The Point

Sources And Further Reading

Two Doors Spam Walks Through

What An Exposure Audit Looks At

The Playbook, Step By Step

Step 1: Read Exposure Signals

Step 2: Spam Exposure Report

How To Read A Rating

What “Worth A Look” Means

What The Settings And The Public Page Say

What The Playbook Does Not Do

A Careful Version You Can Do By Hand

Two Outside Views

Where Protuno Fits

The Point

Sources And Further Reading

Three Digits, Three Audiences

How WordPress Decides It Can Write

What The Handbook Recommends

777 In Plain Terms

Four Causes, One Message

Find The Cause In Order

The Outside View Is A Different Check

What Correct Permissions Do Not Solve

Two Outside Views

The Point

Sources And Further Reading

Minor Releases Install Themselves, Major Ones Usually Wait For You

What “Tested Up To” Actually Means

The Playbook, Step By Step

Set The Target First

Step 1: Inventory And Compatibility Lookup

Step 2: Readiness Report

How To Read A Rating

What The Settings And The Public Page Say

What The Playbook Does Not Do

A Careful Version You Can Do By Hand

Two Outside Views

Where Protuno Fits

The Point

Sources And Further Reading

The Five Decisions, Not One

Core Minor Releases: On