A WordPress site can lose its traffic, its speed or its security without showing a single error. Pages load, forms send, the admin responds. Nothing raises an alarm, and that is exactly the problem: nobody goes looking for a failure they cannot see.
The mistakes in this list share that trait. None of them takes the site down, and all of them cost a lot after a few months: pages dropping out of Google, an abandoned PHP version, a backup that will not restore on the day you need it. In October 2026, more than a third of WordPress sites were running a PHP version that no longer receives security fixes.
For each mistake, you will find how to spot it with tools you already have (Site Health, Search Console, WP-CLI) and how to fix it. Then a real story: a major British retailer that changed its web addresses and paid for it for three months.
How we ranked them
We found no study that ranks these mistakes by frequency, and we will not invent one. Our order follows a simple rule: the size of the possible loss, multiplied by how long it can go unnoticed.
The first three can wipe out your Google traffic or the whole site while everything seems to work. The next three open the door to an intrusion or block updates. The three after that erode quality and speed. The last one is the habit that would have caught several of the others.
1. “Discourage search engines” left checked: invisible to Google
Why it hurts
Under Settings, then Reading, a checkbox reads “Discourage search engines from indexing this site”. It often gets ticked during development or on a working copy, then a migration or a database copy carries it to production. The site works perfectly for every human visitor.
Since WordPress 5.3, this checkbox no longer touches robots.txt: it adds a noindex, nofollow tag to every page and, since core sitemaps arrived in 5.5, also disables the built-in XML sitemap. Google then drops pages as it recrawls them. Its documentation warns that a recrawl can take months for less important pages, hence a gradual decline that often gets blamed on something else.
In 2024, a site owner asked Google’s podcast why their site disappeared right after moving their WordPress site to self-hosting (probably from WordPress.com, according to Search Engine Journal). John Mueller replied that his guess was that the new site was somehow blocking search engines, and advised starting with Search Console.
How to spot it
Since WordPress 6.9, Site Health flags the checkbox with “Search engines are discouraged from indexing this site.”, but only as a recommended improvement, not as a critical issue. In Search Console, the Page indexing report shows the reason “URL marked ‘noindex'”, and URL Inspection tells you whether indexing is allowed. On the command line, wp option get blog_public returns 0 when the box is checked.
How to fix it
Uncheck the box, or run wp option update blog_public 1. In Search Console, test the live URL, request indexing for key pages and resubmit the sitemap. For your working copies, use password protection, which Google itself recommends, rather than this checkbox, which always ends up traveling.
2. Permalinks changed without redirects: every link points to an error
Why it hurts
A new WordPress install still defaults to a “Day and name” URL structure. Many owners later switch to “Post name”, which is easier to read, or reorganize their categories. Every old URL, the one Google knows and other sites link to, then returns a 404 error.
WordPress only rescues some cases. When you edit a single post’s slug, it redirects the old address. On a 404 error, it also tries to guess the intended post from the start of its slug. But that guess can land on the wrong post, and it covers neither category base changes nor pages moved in the hierarchy.
How to spot it
In Search Console, the Page indexing report shows a spike in “Not found (404)” after the change. Site Health shows the current permalink structure in its Info tab, but not its history. The safest check is to test the old URLs, taken from an old sitemap or an analytics export, with curl -I.
How to fix it
Before any change, export every indexed or linked URL. Afterwards, add a permanent 301 redirect from each old URL to its exact equivalent, not to the home page. Google asks you to keep those redirects for at least a year, to prefer 301 or 308 codes, and warns that temporary redirects do not send the same signal. The Redirection plugin, installed on more than two million sites, handles these mappings without touching the server.
3. Backups that were never restored: false insurance
Why it hurts
A backup that exists is not a backup that works. It may contain only the database, or only the files, while WordPress documentation reminds you that you need both. It may sit on the same server as the site, or in the same data center. Above all, it may never have been tested.
WordPress’s official backup page does not mention restore tests. The US cybersecurity agency, CISA, makes it a rule: check that your team can restore data quickly, fully and partially. Our comparison of WordPress backup plugins tells what it costs to forget, through the fire at a data center in Strasbourg.
How to spot it
No tool will do it for you: Site Health does not test backups. Only a restore drill proves a backup is good. Restore it to a working copy, time the operation, check the content and log in.
How to fix it
Apply the 3-2-1 rule: three copies, on two different types of storage, one of them off-site. With WP-CLI, wp db export backs up the database, wp db import restores it, and wp search-replace adapts URLs to the test copy, serialized data included. Write down the restore time: it is the length of your next outage.
4. An outdated PHP version: the hole nobody sees
Why it hurts
PHP is the language WordPress runs on, and each version is only maintained for a few years. PHP 8.1 has received no security fixes since December 31, 2025, and PHP 8.2 will stop receiving them on December 31, 2026. On that date, if nothing changes, about six in ten WordPress sites will be running an abandoned version.
WordPress recommends PHP 8.3 or newer, and version 7.0 raised the minimum to PHP 7.4: sites on PHP 7.2 or 7.3 stay stuck on WordPress 6.9. The speed gain from an upgrade is real but modest. The main argument is security.
How to spot it
Site Health compares your version with WordPress’s recommendations. Watch out for a trap: on October 1, 2026, the service it queries still considered PHP 8.1 secure, and therefore only showed it as a recommended improvement. Trust the dates published by php.net.
Another trap: wp cli info shows the PHP version used by the command line, which is not necessarily the web server’s. For the latter, check the Server section of Site Health’s Info tab, or your hosting panel.
How to fix it
Clone the site to a working copy, switch it to PHP 8.3, 8.4 or 8.5, update plugins and theme first, turn on the error log, then walk through key flows: checkout, forms, login. Do not rely on the old PHP Compatibility Checker plugin, which is no longer maintained and only checks up to PHP 8.0. Our guide to PHP versions for WordPress details the process.
5. Too many plugins, and abandoned ones
Why it hurts
These are two separate problems. Too many plugins weigh on speed, multiply conflicts and inflate the options loaded on every page. Abandonment is a security risk. According to Patchstack, 91% of new WordPress-related vulnerabilities discovered in 2025 were in plugins, and almost half had no fix when they were made public, and an abandoned plugin will never get one.
More worrying, WordPress shows no warning when an installed plugin has been closed on WordPress.org. It appears in the list like any up-to-date plugin.
How to spot them
Site Health flags plugins waiting for updates, inactive plugins, which it calls tempting targets for attackers, inactive themes, and autoloaded options once they exceed a certain size. For closed plugins, WP-CLI does better than the interface:
wp plugin list --fields=name,status,version,wporg_status,wporg_last_updatedA closed status means the plugin was removed from the directory. An empty status means a plugin that was never listed there, such as a premium extension, which this command cannot judge.
How to fix it
Delete inactive plugins and unused themes, keeping one default theme as a fallback. Replace closed plugins, remove those that overlap, and check after each uninstall that no orphaned options remain. Query Monitor helps measure what each plugin costs in queries.
6. An “admin” account and weak passwords
Why it hurts
WordPress’s official documentation is blunt: do not use the username “admin”. It is the first one tried by bots that test passwords in bulk, along with “webmaster”. Combined with a weak or reused password, it turns a mass attack into a successful intrusion.
How to spot it
Site Health checks neither usernames nor password strength. WP-CLI lists administrators with wp user list --role=administrator --fields=ID,user_login,user_email. Also look for forgotten administrator accounts belonging to former contractors or employees.
How to fix it
A username cannot be renamed in WordPress. Create a new administrator, log in with it, then delete the old one and reassign its content: wp user delete 123 --reassign=567. Without that reassignment, the old account’s posts are deleted along with it.
Renaming “admin” only removes one guess: real usernames often remain visible. What matters most is elsewhere, in unique passwords, a password manager and two-factor authentication for every administrator. Our 10 WordPress security hardening measures cover these protections.
7. No staging site: testing on your customers
Why it hurts
Updating a plugin, a theme, PHP or WordPress directly in production means testing on your visitors. WordPress has added safety nets: a recovery mode for fatal errors since version 5.2, and an automatic rollback of plugin auto-updates that trigger a fatal error since 6.6. But these nets only catch fatal errors, not a broken layout or a checkout that miscalculates.
How to spot it
No automatic test checks whether a staging site exists. Ask yourself three questions: is there a working copy, is it password protected, and does each copy declare its role? Since WordPress 5.5, the WP_ENVIRONMENT_TYPE constant lets you state whether a site is local, development, staging or production.
How to fix it
Many hosts offer one-click staging, and plugins such as WP Staging create one. Declare it with wp config set WP_ENVIRONMENT_TYPE staging --type=constant, protect it with an HTTP password, and never copy its indexing settings back to production, which is how mistake number one happens.
8. Editing the parent theme: changes wiped at the next update
Why it hurts
Editing the files of a purchased or downloaded theme directly, through the built-in editor, FTP or Git, leads to one of two dead ends. Either the next update overwrites the changes, or the owner stops updating the theme to protect them, and piles up vulnerabilities. WordPress’s file editor even displays a warning about it.
Block themes soften the problem. Changes made in the Site Editor are stored in the database and survive updates. Only file edits still require a child theme.
How to spot it
In Site Health’s Info tab, the Active Theme section shows whether it has a parent theme. A theme that has shown an available update for months is a warning sign. To find out whether files were modified, compare them with a fresh copy of the same version downloaded from WordPress.org.
How to fix it
Create a child theme, with a style.css file whose Template header names the parent’s folder. Move the changes into it, reinstall a clean parent, then update it. Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php to remove the file editors from the admin.
9. Heavy images: slowness that settles in
Why it hurts
A photo uploaded straight from the camera weighs several megabytes. Multiplied across pages and posts, it slows down rendering and weighs on Core Web Vitals, the speed metrics Google measures on real visitors. According to the 2025 Web Almanac, WordPress remains among the lowest-ranked CMSs on these metrics.
Yet WordPress does a lot on its own: very large images scaled down to 2,560 pixels, lazy loading, WebP and AVIF formats. Since version 7.1, compression and resizing even happen in the browser, but only in Chrome and browsers of the same family, and with no automatic WebP or AVIF conversion by default, apart from HEIC photos converted to JPEG.
How to spot them
Search Console’s Core Web Vitals report groups slow URLs based on real-user data. PageSpeed Insights flags images that should be compressed, converted or resized. Site Health does not judge image weight.
How to fix it
Resize before uploading, enable a modern format with the Modern Image Formats module from the WordPress performance team, and never lazy-load the main image at the top of the page. Our selection of WordPress speed optimization plugins complements these settings.
10. Ignoring Site Health: the dashboard nobody opens
Why it hurts
Since WordPress 5.2, Tools, then Site Health, runs a series of tests and sorts the results into critical issues, recommended improvements and passed tests. A check runs every week in the background. Its alerts cover several mistakes in this list (discouraged indexing, outdated PHP, inactive or outdated plugins) and other risky settings: errors displayed to visitors, and, since WordPress 7.0, open registration with a privileged default role.
What it does not see
Site Health checks neither backups, nor administrator usernames, nor two-factor authentication, nor closed plugins, nor modified parent themes, nor image weight, nor redirects, nor staging. It covers three or four of the ten mistakes in this list, which makes it a useful net but not an audit.
How to make it a habit
Open it once a month, deal with critical issues, and export the Info tab when you ask a contractor for help. On the command line, wp site-health commands do exist, but only in WP-CLI nightly builds or as a package you install: the current stable release, 2.12.0, does not include them.
The real case: Asda changes its URLs and loses three months
The story below does not involve a WordPress site. It is the large-scale version of a permalink change, and it shows what happens when redirects are missing, even at a company with the means to get it right.
A seemingly harmless move
Asda is one of the largest supermarket chains in the United Kingdom. Its online shop lived on a subdomain, groceries.asda.com. Just before the change, according to data from the SEO tool Sistrix, Asda had reached its best Google visibility in more than seven years.
On August 22, 2025, the retailer moved its shop to a directory on its main domain, www.asda.com/groceries/. The old URL organization, by aisles, categories and shelves, gave way to a cleaner, more readable structure. On paper, it was an improvement.
What went wrong
The new sub-categories did not match the old ones. Some category pages received an individual redirect to their equivalent and kept working. Others returned a 404 error. Sistrix cites an old shelf page that used to rank very well and was still returning a 404 when Sistrix checked.
One week after the change, Asda’s visibility had dropped by 12%, to the benefit of its competitors. Internet Archive captures also show that the shop’s old home page first returned a temporary redirect, before switching to a permanent one at the end of September. Google points out that a temporary redirect does not tell it the new URL should replace the old one.
Three months to recover
On November 18, 2025, about three months later, Asda’s visibility was back to its earlier level. Sistrix sees a pattern it has observed for years: it takes Google about three months to fully rediscover a new directory. In the meantime, according to the tool, the dip represented millions of potential clicks lost, an estimate from its model and not Asda’s own figures.
We found no statement from Asda about the operation. Our sources are Sistrix’s analysis and the Internet Archive captures, which calls for caution on the details.
What a WordPress site owner should take away
Before touching permalinks or categories, export every URL that gets traffic. Add one permanent redirect per old URL, to its true equivalent, and keep it for at least a year. Check “Not found (404)” pages in Search Console every day for the first weeks. And remember the order of magnitude: a major brand spent three months below its usual visibility; Google expects a few weeks for a small or medium site, provided every old URL is redirected.
Where to start
A first audit takes half an hour. Open Site Health and note the critical issues. In Search Console, look at the Page indexing report, especially pages marked noindex and pages not found. Then run three WP-CLI commands:
wp option get blog_public
wp plugin list --fields=name,status,version,wporg_status
wp user list --role=administrator --fields=ID,user_loginFinally, schedule a backup restore on a working copy. Our WordPress maintenance checklist turns these checks into a routine.
Summary table
| Mistake | What you lose | How to spot it | Site Health |
|---|---|---|---|
| Indexing discouraged | Google traffic | Search Console, blog_public |
Yes, since 6.9 |
| Permalinks without redirects | Rankings and backlinks | “Not found (404)” in Search Console | No |
| Untested backups | The whole site | Restore drill | No |
| Outdated PHP | Security fixes | php.net dates | Partly |
| Abandoned plugins | Security and speed | wporg_status in WP-CLI |
Partly |
| “admin” account | Control of the site | wp user list |
No |
| No staging | Sales, form submissions | WP_ENVIRONMENT_TYPE |
No |
| Edited parent theme | Theme updates | Comparison with a fresh copy | No |
| Heavy images | Speed | Core Web Vitals, PageSpeed Insights | No |
| Site Health ignored | Early warnings | One visit a month | Itself |
Frequently asked questions
Does “Discourage search engines” remove my site from Google immediately?
No. Google drops pages as it recrawls them, which, according to Google, can take months for less important pages. That is what makes the mistake so hard to link to its cause.
Can I rename the “admin” account?
Not directly: WordPress does not allow a username to be changed, either in the interface or with WP-CLI. You have to create a new administrator, reassign the content to it, then delete the old account.
Which PHP version should I use in 2026?
PHP 8.3 at least, as WordPress recommends, and PHP 8.4 or 8.5 if your plugins support them (the WordPress Hosting Team recommends them for new installs). PHP 8.2 stops receiving security fixes at the end of 2026.
Does WordPress redirect old URLs after a permalink change?
Only partly. It redirects the old slug of an individually edited post, and tries to guess the intended post on a 404 error. It handles neither global structure changes nor categories. Explicit redirects remain essential.
Is Site Health enough to monitor my site?
No. It catches outdated versions, inactive plugins and a few dangerous settings, but ignores backups, accounts, redirects and page weight. Complement it with Search Console and regular restores.
Do I need a child theme with a block theme?
Not for settings made in the Site Editor, which are saved in the database. Yes as soon as you edit files, add template files or add code.
Conclusion
These ten mistakes have one thing in common: they break nothing visible. They let the site keep working while it loses its rankings, its security or its ability to recover from an incident. Asda’s story shows it on a large scale: three months below its usual visibility, after a migration with incomplete redirects.
The tools to spot them are free and already there. You just have to open them: Site Health once a month, Search Console once a week, and a backup restore before you need one.
Sources
- WordPress.org (October 2026). Statistics
- WordPress.org (May 2026). Requirements
- Make WordPress Core, John Blackbourn (January 9, 2026). Dropping support for PHP 7.2 and 7.3
- PHP.net. Supported Versions
- WordPress, GitHub (7.1 branch). class-wp-site-health.php
- WordPress.org Documentation (July 2026). Site Health screen
- Make WordPress Core, Peter Wilson (September 2, 2019). Changes to prevent search engines indexing sites
- Google Search Central. Block Search indexing with noindex
- Google Search Console Help. Page indexing report
- Google Search Central (August 2026). Site moves with URL changes
- Google Search Central (April 2026). Redirects and Google Search
- Search Engine Journal, Roger Montti (April 20, 2024). Google On Diagnosing A Deindexed WordPress Site
- WordPress Developer Resources (June 2026). Backups
- CISA. Back Up Business Data
- Patchstack (February 25, 2026). State of WordPress Security in 2026
- Patchstack (October 18, 2024). Security implications of plugin closures
- WP-CLI. wp plugin list
- WordPress Developer Resources (February 2026). Brute Force Attacks
- WP-CLI. wp user delete
- WordPress Developer Resources. wp_get_environment_type()
- WordPress Developer Resources. Child Themes
- Make WordPress Core, Adam Silverstein (July 22, 2026). Client-side media processing in WordPress 7.1
- HTTP Archive (January 15, 2026). Web Almanac 2025, CMS
- Google Search Console Help. Core Web Vitals report
- GitHub, WP-CLI. site-health-command
- Sistrix, Steve Paine (September 3, 2025, updated January 6, 2026). Asda Domain Visibility in Complex Subdomain to Subdirectory Migration
- WordPress.org. Redirection
- Make WordPress Core (June 25, 2024). WordPress 6.6 Field Guide
- Google Search Central. Control what you share with Google
- WordPress Developer Resources (January 2026). Hardening WordPress
- Internet Archive (August to December 2025). Captures of groceries.asda.com
- Kinsta (December 2025). PHP benchmarks
- Make WordPress Hosting. WordPress 7.0 server compatibility
LaFactory designs, builds and maintains WordPress and WooCommerce sites, technical audits included, and develops its own plugins. Talk to us about your WordPress project.