Google has been keeping notes on your website since the day it found it. Which pages it crawled, which ones it decided to skip, which URL it thinks is the real version when two look alike, and every search where your site showed up and nobody clicked. All of that sits in a free tool most WordPress owners set up once, glance at, and never open again.
That’s a shame, because it’s the only place Google tells you what it actually did with your site. Analytics covers what happened after somebody arrived; Search Console tells you why most people never arrived at all — the impressions you got with no clicks, the pages sitting in a queue that Google never got around to crawling, the duplicates it quietly collapsed into one.
The last badly-hacked WordPress site we cleaned up had a couple hundred spam URLs in its Page indexing report that nobody at the company had ever created. The owner found out because traffic fell off a cliff; Search Console had been listing the junk for weeks. This guide walks through setting the thing up properly on WordPress — verification and sitemap submission — and then reading the three reporting screens that are actually worth your time.
What Search Console Is, and What It Definitely Isn’t
Search Console is Google’s side of the conversation. It reports on crawling, indexing, and how your pages perform in search results — impressions, clicks, average position, structured data problems, mobile issues, manual actions and security warnings. It’s free, and it’s tied to a property you have to prove you own.
It isn’t analytics. Google Analytics starts measuring once a visitor lands on your page. Search Console covers everything before that: whether Google can reach the page, whether it decided to index it, and how often it showed the page to someone. The two overlap on almost nothing, which is why serious sites run both. Google’s term for the thing you’re monitoring is a property, and its documentation says you can have up to 1,000 of them in one account — so add every client site, every staging domain, every subdomain that matters.
Verification: Pick the Method That Survives a Theme Update
Before you see any data you have to prove ownership. Search Console offers several methods, and the one you pick determines how fragile your verification is.
Domain property vs. URL-prefix property
This choice comes first and trips up nearly everyone. A URL-prefix property includes only URLs with the specified prefix, protocol included — so https://example.com/ and http://example.com/ are two different properties with two different sets of data. The hostname counts too, so https://www.example.com/ is a third one again. A Domain property is domain-level: Google’s docs describe it as including all subdomains (m, www, and so on) and multiple protocols.
If you’ve ever wondered why your Search Console numbers look suspiciously small, this is usually why. You verified https://www.yoursite.com/ years ago, later moved to the non-www form, and have been reading a property that has been near-empty ever since. A Domain property fixes it in one move — but it comes with a catch. Google states plainly that the domain name provider method is the required route for a Domain property, apart from sites hosted on a Google product such as Blogger or Google Sites, which verify without it. For everyone else it means DNS access. For a self-hosted WordPress install, that means no DNS, no Domain property.
The methods that actually work on WordPress
Search Console’s documented options are HTML file upload, an HTML tag, a Google Analytics tracking code, Google Tag Manager, a Google Sites or Blogger account, and the domain name provider (DNS) route. Google explicitly calls out hosted platforms too, noting that if you use a website hosting platform like WordPress, Wix, or SquareSpace, you might not be able to use some of the listed methods — or your platform might offer a plugin or setting that handles it for you.
On a self-hosted WordPress install, three are practical:
- DNS record — a TXT or CNAME entry at your domain provider. It’s the route to a Domain property, and the only method no theme or plugin change can break. If you have DNS access, use this.
- HTML meta tag — Google gives you a
<meta>tag for the homepage’s<head>. Most SEO plugins have a field for it (Yoast puts one under its webmaster-tools settings), which is safer than editingheader.php. - HTML file upload — drop a file at a specific URL in your web root. It works, but it’s the first thing to vanish during a migration or a host change.
If you’d rather not depend on an SEO plugin, a few lines in a small site-specific plugin will do it. Don’t put this in your theme’s functions.php — a theme switch leaves it behind with the old theme, and you’ll unverify yourself without noticing:
add_action( 'wp_head', function () {
echo '<meta name="google-site-verification" content="YOUR_TOKEN_HERE" />' . "\n";
} );Verification isn’t permanent
The token also has to stay put. Search Console’s documentation says verification lasts as long as it can confirm the presence and validity of your verification token, that it checks periodically, and that if the issue isn’t fixed your permissions on that property expire after a grace period — for the DNS route it’s blunt, telling you not to remove the record even after verification succeeds. Which is why Google recommends adding a second method, and gives the exact scenario we’ve watched play out: you verified using a Google Analytics tracking code, and someone changes a template that omits the tag.
Search Console is also how Google tells you your site has been hacked or hit with a manual action. If nobody has verified the property, that warning goes nowhere. On a compromised site the Page indexing report is often the first hard evidence — a pile of URLs in the index that nobody on your team ever published.
Your Sitemap Is the Handshake
Once you’re verified, submit a sitemap. This is how you hand Google an explicit list of the URLs you care about instead of hoping it finds them all by following links.
Which sitemap URL do you submit?
WordPress has generated an XML sitemap automatically since version 5.5 (August 2020) at /wp-sitemap.xml. No plugin required. It’s a sitemap index pointing at smaller sub-sitemaps, each holding a filterable maximum of 2,000 URLs by default — the wp_sitemaps_max_urls filter sets that number.
If you run an SEO plugin, though, that’s probably not the file you want. Yoast ships its own at /sitemap_index.xml and disables the core one so you aren’t serving two competing maps; Rank Math, SEOPress and AIOSEO each do something similar. Open both URLs in a browser before you submit anything — submitting a sitemap your SEO plugin has switched off is a common way to sit waiting for data that never appears.
Submitting is a hint, not a command
Google’s own wording on this is refreshingly direct: submitting a sitemap is merely a hint, and it doesn’t guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site. A sitemap improves discovery. It doesn’t buy indexing.
Two other things worth knowing. All formats limit a single sitemap to 50MB uncompressed or 50,000 URLs — WordPress’s 2,000-URL split keeps the core sitemap well under that, so the limit mainly matters if you generate sitemaps yourself or raise your SEO plugin’s per-file URL count. And Search Console isn’t the only way to submit; you can add a line anywhere in your robots.txt pointing at the file, in the form Sitemap: https://example.com/my_sitemap.xml, and Google picks it up the next time it crawls that file. Core WordPress already adds a Sitemap: reference to its virtual robots.txt for you, and an SEO plugin that takes over sitemap duty swaps its own URL into that line.
The Page Indexing Report, Translated Into English
This is the report people find intimidating, mostly because the status names read like error codes when several of them aren’t errors at all. Google’s guidance is that if your site has fewer than 500 pages, you probably don’t need this report — a few site: searches will tell you what you need. That threshold is about routine monitoring, though. Open it regardless of size after any suspected compromise, since injected spam URLs surface here before they surface anywhere else. Either way, here’s what the statuses you’ll actually hit are saying.
Crawled – currently not indexed
Google’s definition: the page was crawled but not indexed, it may or may not be indexed in the future, and there’s no need to resubmit the URL for crawling. Translated: Googlebot read your page and wasn’t impressed enough to keep it. Resubmitting won’t help. Thin content, a page that duplicates something else on your site, or a page with nothing linking to it are the usual causes, and the fix is editorial rather than technical.
Discovered – currently not indexed
Different problem entirely. Google found the URL but hasn’t crawled it yet, and per the docs, typically Google wanted to crawl the URL but this was expected to overload the site, so it rescheduled the crawl. That’s why the last-crawl date is empty. On WordPress this often points at a slow server rather than bad content — a cheap shared host, a bloated autoloaded options table, no page caching. Speed the site up and these tend to clear on their own.
Duplicate without user-selected canonical
Google’s wording: the page is a duplicate of another page but doesn’t indicate a preferred canonical, so Google has chosen the other page as the canonical and won’t serve this one. That’s not an error, it’s Google working without instructions from you. Core WordPress prints a self-referencing canonical tag only on singular views — posts, pages, attachments and custom post type entries, since rel_canonical() returns early unless is_singular() — so archives, taxonomy pages and paginated archives are where this shows up. Inspect the URL to see which page Google picked instead.
Excluded by noindex tag, and Soft 404
The first is usually intentional and you can leave it alone — assuming you meant it. The second is worth chasing. A soft 404 means the page returns what Google thinks is a not-found message but doesn’t return a 404 HTTP response code, and Google recommends returning a real 404 for genuinely missing pages. WordPress sites generate these when a plugin renders a friendly empty-results page at HTTP 200, or when a redirect plugin sends every dead URL to the homepage instead of letting it 404 honestly.
Crawled, not indexed = a content or linking problem, improve the page or link to it. Discovered, not indexed = a speed or crawl-capacity problem, fix the server. Duplicate without canonical = a signals problem, decide which version you want indexed. Soft 404 = a status-code problem, return a real 404. Excluded by noindex tag = usually intentional, just confirm you meant it. Five very different jobs, and matching the fix to the status saves you weeks.
The Performance Report Is Where the Money Is
If you only ever open one Search Console screen, make it this one. It shows how your site performs in Google Search results, and it defaults to the past three months.
Four metrics, and only one of them is a vanity number
Google defines them precisely. Clicks is the number of times a user clicked your site from Google Search results. Impressions is how many times your site appeared in Search results. CTR is the click count divided by the impression count. Average position is the average position of the topmost result from your site — aggregated across your whole site in the chart, but specific to the URL or grouping in each table row.
Impressions is the vanity number. It climbs when Google decides to show you more often, which is not the same thing as you getting better, and a chart that only ever goes up is easy to mistake for progress.
You can group the table by Queries, Pages, Countries, Devices, Search appearance, or Dates. That’s the whole trick, and hardly anyone uses it.
The report is a to-do list disguised as a dashboard
Switch to the Pages tab, sort by impressions, and look for rows with lots of impressions and a terrible CTR. Those are pages Google already shows to people who then decide not to click — you’re not fighting for rankings there, you’re fighting for the headline and the two lines of text underneath it. Rewriting a title tag and meta description on a page like that is about the cheapest traffic you’ll ever buy.
Then switch to the Queries tab and look for anything with an average position in the 8-to-20 range: searches where you’re at the bottom of page one, or on page two and close enough to move. A page ranking eleventh for a term with real volume is usually a better use of an afternoon than a brand-new article on a topic you’ve never ranked for.
One honest caveat from Google’s own docs: even if a query shows in your list, you might not see your site when you run that search yourself, because results are specific to the time, place, device, and recent history of whoever is searching. Don’t panic-audit a page because you couldn’t find it in your own browser.
Once Search Console has shown you fifty pages with weak click-through, somebody has to rewrite fifty titles and descriptions. amplifi.meta uses Claude to bulk-generate SEO titles, meta descriptions and keyphrases across a whole WordPress site, so the fix takes an afternoon instead of a month. It’s MIT licensed and ships inside the combined amplifi.plugins suite.
View on GitHubURL Inspection: The Most Useful Button in the Tool
Paste any URL from your property into the bar at the top of Search Console and you get Google’s file on that specific page. This is where you go when a single post won’t show up and you need to know why.
Indexed data is not a live test
This distinction matters more than it sounds. Google is explicit that the default view is not a live test — the results are from the most recently indexed version of the page, not the live version on the web, and your page may have changed since Google last saw it. If you just fixed something, hit Test Live URL or you’ll be reading history and concluding your fix didn’t work. Worth internalizing too: URL is on Google means the URL is eligible to appear in Search results, not that your page will actually show up there.
Two canonical fields, and they can disagree
Expand the Page indexing section and you’ll find User-declared canonical (what your page said) alongside Google-selected canonical (what Google decided). When those two disagree, you’ve found your problem: Google isn’t honoring your canonical tag, which usually means the pages aren’t similar enough for the declaration to make sense, or two plugins are emitting conflicting canonicals. Google’s docs note there’s no guarantee it’ll pick the canonical you declared, so treat it as a strong suggestion rather than an instruction.
Request Indexing, and what it won’t do
There’s a Request Indexing button, and it’s genuinely useful after you fix something. Just don’t expect miracles. You must be an owner or full user of the property to use it, there’s a daily limit on inspection requests per property, and Google says outright that there’s a quota for submitting individual URLs and that requesting a recrawl multiple times for the same URL won’t get it crawled any faster.
Set your expectations from Google’s own timeline: crawling can take anywhere from a few days to a few weeks, and requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all. For a handful of URLs, use the button. For a large batch, the documentation points you back at your sitemap.
Frequently Asked Questions
Set it up once, then give it twenty minutes a month. The Performance report alone will hand you a list of pages that are one better headline away from real traffic — and if that list runs to fifty rows, amplifi.meta will rewrite them all in an afternoon.
Built by amplifi.studio — see also Google Can’t Index What It Can’t Find: A WordPress XML Sitemap Guide.