Google Search Console for WordPress: Site Kit, Sitemaps and the Fixes WordPress Needs

Why a WordPress site needs Search Console

WordPress runs blogs, stores and company sites that live on Google traffic, and Search Console shows that traffic from Google's side: which posts earn clicks, which pages Google skips and whether anything is broken. It costs nothing. For WordPress, Google even recommends a dedicated plugin. What no plugin can do is make WordPress tidy. Search Console sees every URL your theme and plugins expose, from posts and pages to tag, category and author archives and attachments. That is why WordPress sites often show large not-indexed counts in the Page indexing report even when nothing is wrong with the posts that matter.

Connecting WordPress: pick the route that survives a redesign

There are three ways in: Site Kit, an SEO plugin's verification field, or a meta tag or DNS record added by hand ^[1]. Site Kit is the simplest for most owners, and DNS is the most durable. Whichever you pick, make sure a company account owns the property. The choice matters more later than on day one, because a site verified only through a tag in the theme loses access the next time someone switches themes, while a DNS record or a plugin field keeps working through redesigns, host moves and new editors.

Site Kit by Google

Site Kit is Google's own plugin, and Google's help calls it the only plugin that Google officially sponsors. It became available to all WordPress sites on October 31, 2019, it is free and open source, and it has more than five million active installations ^[2]. Install it from Plugins, then Add New, search for Site Kit by Google, activate it and connect a Google account. No code editing is required. During setup Site Kit verifies the site in Search Console and links it, so you may never see Google's verification screen at all.

Two details trip people up. Site Kit requires WordPress 5.2 or higher and PHP 7.4 or higher, the site must be publicly reachable, and the plugin has to talk to Google through the REST API. Security plugins that block the REST API are a common reason setup fails, so check Tools, then Site Health, before blaming Google. The second detail is ownership. The connected Google account owns the data the dashboard shows, so the installer should be someone who will still manage the site in a year. And every WordPress admin must connect their own Google account. On a team of five, that means five sign-ins.

A plugin field, a theme tag or DNS

Many SEO plugins have a field for Google's verification meta tag: copy the tag from Search Console, paste it in and save. The plugin prints it in the head, so theme changes no longer remove it. Pasting the tag into your theme's header file by hand also works, but a theme update can overwrite it, and once the code is gone you lose access after a grace period. A child theme or a plugin field is safer. For a Domain property, add a TXT record at your domain provider instead. It survives every theme, plugin and host change, though it can take two or three days to be served.

WordPress.com sites verify through Jetpack, under Traffic, where you paste Google's code into the Google box; the same screen verifies Bing, Pinterest, Yandex and Facebook. Auto-verify applies only to the Business and Commerce plans, so Free, Personal and Premium sites must upgrade to get it. For DNS on WordPress.com, the guide says to ignore Google's offer to verify through WordPress.com and choose another provider option.

Domain or URL-prefix property

Choose a Domain property if you can edit DNS, because it covers http, https, www and subdomains together. Choose a URL-prefix property with the exact https address if you verify through a plugin or Site Kit. Getting this wrong is costly. Google calls mixing up http and https probably the most common reason for missing traffic. A typical case is a site that moved to https with a plugin years ago while its property was created for http, so the old property shows almost nothing and the owner thinks the blog lost its traffic. Our setup guide covers each method step by step.

What Site Kit shows, and where it stops

Site Kit opens a dashboard with key metrics from Search Console already in place: traffic sources, popular pages, the queries people used and how many people saw the site in search. It also adds stats to the admin bar, which Yoast describes as a mini-report with impressions, clicks and traffic over time, so editors see performance while they edit. Key Metrics shows each figure with a trend against the previous period. Fewer metrics, read monthly, beat a crowded dashboard. A small blog might pick top search queries, top pages by clicks and new visitors from search, and read them on the first Monday of each month. Data can take a few days to appear. An empty dashboard on day one is normal.

The limits matter as much as the features. As Yoast puts it, "Site Kit is not an SEO plugin like Yoast SEO". It shows data; it does not change titles, sitemaps or schema, so most sites run both. For filters, regex, indexing reasons, URL Inspection, exports and the generative AI report, you still open Search Console itself. Site Kit is a window, not the whole house. Most WordPress.org reviewers are happy with it, which suggests most sites run it without trouble while a minority hit connection or REST API problems, and its support forum showed 46 of 59 issues resolved in the last two months.

Sitemaps and robots.txt: what WordPress publishes on its own

Since version 5.5, WordPress core exposes a sitemap index at /wp-sitemap.xml ^[3]. It covers public post types, taxonomies, author archives and the homepage, it is generated on the fly, and the robots.txt that WordPress serves points to it. A single core sitemap holds a filterable maximum of 2,000 entries, while Google allows 50,000 URLs per sitemap, so core splits files earlier than Google requires. A blog with 5,000 posts gets three post sitemaps. That is fine for Google. Core sitemaps list only the URL, without lastmod.

Many SEO plugins switch the core sitemap off and publish their own. Submit only the sitemap that is actually live, because two competing sitemaps confuse audits more than they confuse Google. Open Sitemaps in Search Console, enter the address, click Submit and check the status a day later. On self-hosted WordPress the core address is /wp-sitemap.xml; on WordPress.com it is typically your domain name followed by /sitemap.xml.

The setting that hides a whole site

WordPress has a setting that discourages search engines. When it is on, sitemaps are disabled and the site signals noindex. Staging copies often have it on, and so do live sites launched from staging, so check it first when a new site shows no indexed pages after two weeks. Treat robots.txt with the same suspicion. WordPress serves it dynamically, so there is usually no file to edit; plugins or filters change it, and Search Console's robots.txt report shows what Google actually fetched. Keep staging out of Google with a login, not robots.txt, which does not stop indexing from links.

Reading the Page indexing report on a WordPress site

Expect four statuses to dominate: Alternate page with proper canonical tag, Page with redirect, Excluded by noindex tag and Crawled, currently not indexed. Most come from archives and attachments, not from your posts, and Google says a page marked duplicate or alternate "is usually a good thing" ^[4]. Start from the posts and pages that should rank and treat the rest as housekeeping. Our Page indexing errors guide explains every status in depth.

Archives, attachments and pagination

Tag archives multiply fastest. A blog with 300 posts and 600 tags creates 600 thin tag pages, most of which Google will crawl and skip, so many sites noindex tags or keep only the useful ones. As a rule of thumb, a tag holding fewer than five posts rarely deserves its own indexed page. Author archives duplicate the main blog page on a single-author blog, and you may prefer to noindex them there. Attachment pages create a URL per image with almost no content; many SEO plugins redirect them to the file or parent post, after which Page with redirect entries appear. Those are fine.

Empty categories and tags show as soft 404, because the page returns success but has no content, so delete or noindex them. Internal search URLs such as ?s= create endless variations and belong behind noindex. Pagination is the exception. Google needs a crawl path from known pages, and paginated archives such as /page/2/ provide one for older posts, so do not noindex them if they are the only path to older content.

Problems that plugins create

SEO and membership plugins can noindex a whole post type with one checkbox. If posts appear under Excluded by noindex tag, check plugin settings first, then request indexing for the key posts. After installing or updating such a plugin, inspect one post and one page the same day, because Search Console will only show the damage weeks later. Redirect plugins cause the other common mess. Stacked redirects, chains and loops appear as Redirect error, so point every old URL straight to its final destination.

Speed, schema and WooCommerce

The Core Web Vitals report uses real visitor data, and on WordPress, heavy themes, page builders and long plugin lists usually explain poor LCP and INP. Google's suggested best practice is under 500KB for a page and its resources. Because the report groups similar URLs, one heavy template drags hundreds of pages down at once. Fix templates, not single pages. The field data covers 28 days, so a caching plugin or image optimizer shows its full effect about four weeks later. Judge it then, not after one test.

SEO plugins also add schema automatically, and the rich result reports under Enhancements show valid and invalid items. Google advises that marked-up content should be visible on the page, so plugins that mark up hidden content create errors. WooCommerce stores add product URLs, filters and cart pages. Search Console's Shopping reports appear only for sites Google identifies as online merchants, and Yoast notes that advanced ecommerce tracking has to be set up in GA4 directly or through other methods.

Finding the posts worth updating

For a blog, the Performance report is a to-do list. Open Queries and sort by impressions. Queries with high impressions and positions between 8 and 20 point to the posts closest to page one, and improving those usually beats writing new ones, because Google already connects them to the topic. Filter one post's URL, find its queries in that range and add a section that answers each one directly. Recheck after four weeks. Our Performance report guide walks through the filters.

Two more views find the rest. Compare the last three months with the previous period and sort pages by click difference; posts that keep losing clicks are decaying and need fresh facts, dates and structure. For weak click-through, select CTR, open Pages and sort ascending. High impressions with low CTR usually mean other results look more compelling. Rewrite the title in your SEO plugin, keep the URL and annotate the date on the chart.

AI Overviews and internal links

Informational posts are exactly what AI Overviews summarize. Search Console counts AI Overview clicks in Web data and reports AI impressions in the generative AI report, so compare the two for your top posts. You can exclude a site from AI Overviews and AI Mode in Settings, but Google says a site must be included to be eligible, and for most blogs excluding gives up visibility without a clear gain. Measure before deciding. Then use the Links report: take the posts with the most page-two impressions and link to them from your strongest posts. One contextual link often beats a sitewide widget.

Security, theme changes and moves

WordPress sites are common targets. The Security issues report flags hacked content, malware and social engineering, and new issues trigger an email. After a theme change, inspect the home page, one post, one category and one page with live tests, confirm that verification tags survived and no noindex appeared, then watch Core Web Vitals for 28 days. Hosting moves can change server responses, DNS and HTTPS, so watch Crawl Stats and the Page indexing report for server errors. A domain change needs 301 redirects from every old URL, kept at least 180 days, plus the Change of Address tool, which requires owning both properties with the same Google account.

A thirty-minute monthly routine, and the classic mistakes

Thirty minutes a month covers most blogs, and the routine is short enough to keep:

• Check Site Kit's dashboard for traffic trends.
• Open the Page indexing report for new errors.
• Review the top ten queries and the ten posts with the most impressions on page two.
• Check Core Web Vitals after any plugin or theme change.

Write down total clicks, indexed pages and the count of posts at positions 8 to 20 each month, and the trend tells a seasonal dip from a real problem. The classic mistakes are just as predictable. Owners leave search engine visibility discouraged after launch, verify with a tag a theme update removes, submit both a core and a plugin sitemap, noindex posts through a plugin setting, and ignore Search Console because Site Kit already shows numbers. Each one is easy to avoid.

The bottom line

For WordPress, Site Kit makes Search Console easy to connect and easy to glance at, while Search Console itself remains the place to fix the indexing, archive and speed problems that WordPress creates by default. Connect with Site Kit or DNS under a company account, submit the sitemap that is actually live, prune thin archives, and spend your effort on the posts already closest to page one. Then keep the monthly routine going, so a plugin update or a theme change never costs you a season of traffic before you notice.