We did a server-wide audit today and found 7 production WordPress sites with search indexing silently disabled. The sites looked completely normal to visitors. Google couldn't see any of them.
Here's the setting, why it gets left on, and how to audit a whole cPanel server at once.
The Setting
In WordPress: Settings → Reading → "Discourage search engines from indexing this site"
When checked, WordPress does two things:
- Adds
<meta name="robots" content="noindex,follow"> to every page
- Sets the
blog_public option to 0 in the wp_options table
When unchecked, blog_public = 1.
That's it. One row in one table. No other indicators anywhere on the site.
How It Gets Left On
The lifecycle is almost always the same:
- Developer builds the site in WordPress. They check "Discourage search engines" so Google doesn't index the half-built site.
- Site launches. Developer forgets to uncheck it, or hands off to a client who doesn't know the setting exists.
- Site runs for months or years with
noindex on every page. Traffic never comes. Owner assumes "SEO takes time."
There's no visual indicator on the front end. The site looks exactly the same with or without the setting. The only way to catch it is to check the setting directly or look at the rendered HTML.
How to Audit Across a cPanel Server
If you manage multiple WordPress sites, checking them one at a time through the admin panel doesn't scale. The faster approach reads directly from each site's database.
Every WordPress installation has a wp-config.php with DB credentials, and a {prefix}options table with the blog_public row.
Quick Python approach using paramiko (SSH from a management machine):
import paramiko, re
def parse_wpconfig(content):
def extract(key):
m = re.search(r"define\s*\(\s*['\"]" + key + r"['\"]\s*,\s*['\"]([^'\"]*)['\"]", content)
return m.group(1) if m else None
m2 = re.search(r"\$table_prefix\s*=\s*['\"]([^\"']+)['\"]", content)
return {
'dbname': extract('DB_NAME'), 'dbuser': extract('DB_USER'),
'dbpass': extract('DB_PASSWORD'),
'prefix': m2.group(1) if m2 else 'wp_',
}
For each wp-config.php found under /home/*/public_html/:
- Parse
DB_NAME, DB_USER, DB_PASSWORD, table_prefix
- Run:
SELECT option_value FROM {prefix}options WHERE option_name='blog_public'
- Collect all sites where the result is
0
To fix in bulk: UPDATE {prefix}options SET option_value='1' WHERE option_name='blog_public'
What We Found
Scanning 194 wp-config.php files across the server (most were Duplicator installer stubs or sandbox installs — ~95 real sites):
- 77 sites:
blog_public=1 — indexed correctly
- 18 sites:
blog_public=0 — search disabled
Of the 18 disabled:
- 7 were production sites with real businesses depending on them. None of those owners knew.
- The remaining 11 were development/staging installations where it belongs.
The production sites ranged from a few months live to over a year. At least two had active SEO work being done on them — content, backlinks, the works — with noindex blocking all of it at the head tag level.
The Fix
One SQL update per site:
UPDATE wp_options SET option_value = '1' WHERE option_name = 'blog_public';
Or via WP-CLI if you have it: wp option update blog_public 1
After updating, verify by fetching the page source and confirming there's no <meta name="robots" content="noindex"> in the <head>.
What to Watch For
- Any WordPress site that went through a staging/development phase before launch should be checked
- Sites migrated between servers (Duplicator, All-in-One Migration) often carry the setting over from the old install
- The WordPress admin dashboard shows the setting, but it's buried in Settings → Reading and easy to miss if you're not looking for it
- Google Search Console will also show a "noindex" warning under Coverage, but only if the site has been submitted
The only reason we found all seven is that we audit this across every site we host. If you've ever wondered why your own site never seems to appear in search, that check takes about a minute and we're happy to run it — it's part of how we handle hosting and search visibility.
