Google Search Console Setup: Domain Verification, Sitemap Submission & Indexing, Step by Step
If a page isn’t indexed, nothing else you do to it matters — not the schema, not the internal links, not the copy. Before any of that work pays off, Google has to be able to (1) prove you own the property, (2) find your URLs, and (3) crawl them cleanly. This guide walks through all four stages of a proper GSC setup: domain verification, sitemap submission, an explicit indexing request via URL Inspection, and the verification pass that confirms nothing is silently broken.
We’ll use yourdomain.com as the placeholder throughout this guide — swap in your own domain wherever you see it, and you can follow every step exactly as written.
1. Verify Domain Ownership in Google Search Console
GSC gives you two verification paths depending on whether you want to verify the whole domain (all subdomains and protocols — www, non-www, http, https, and any subdomain like blog.yourdomain.com) or just a single URL prefix (e.g., only https://www.yourdomain.com/). For almost every site, the Domain property is the right choice — it consolidates all traffic and indexing data in one place instead of splitting it across four variants.
Option A — DNS TXT Record (recommended for Domain properties)
This is the only verification method available for a Domain property, and it’s the most durable — it survives site migrations, CMS changes, and hosting switches since it lives at the DNS level, not on the site itself.
- In GSC, click Add Property → select Domain → enter yourdomain.com (no https://, no www).
- Google gives you a TXT record value like google-site-verification=abc123XYZ…
- Log into your DNS provider (Cloudflare, GoDaddy, Namecheap, Route 53, etc.) and add a new TXT record:
- Host/Name: @ (root domain)
- Type: TXT
- Value: the string Google gave you
- TTL: default is fine (3600s or “Auto”)
- Save the record, return to GSC, and click Verify.
DNS propagation can take anywhere from a few minutes to 48 hours depending on your provider and TTL, though most modern DNS hosts (Cloudflare especially) propagate within minutes. If verification fails immediately, wait 15–30 minutes and retry before troubleshooting further — this is almost always a propagation delay, not a misconfiguration.
Common failure points:
- Extra characters copied along with the TXT value (leading/trailing quotes or spaces)
- Adding the record to a subdomain zone instead of the root
- A DNS provider that silently strips or truncates long TXT values (rare, but happens on some budget registrars)
Option B — HTML Tag / File Upload (URL-prefix properties only)
If you only need to verify a specific URL prefix rather than the whole domain, GSC offers faster methods:
- HTML tag: paste a <meta name=”google-site-verification” content=”…”> tag into the <head> of your homepage, before the first <body> tag.
- HTML file upload: download a Google-provided file (e.g., google1234abcd.html) and upload it to your site’s root directory so it’s reachable at yourdomain.com/google1234abcd.html.
- Google Analytics / Tag Manager: if you already have GA4 or GTM installed with edit access on the account, GSC can verify through that connection with no extra steps.
The trade-off: these methods verify only that specific URL prefix, not the whole domain, and HTML-tag verification breaks if a theme/template change wipes the <head> snippet. DNS TXT doesn’t have this fragility.
2. Submit and Update the XML Sitemap
Once ownership is verified, tell Google exactly which URLs you want crawled.
- Confirm your sitemap is live and returns a 200 status — check yourdomain.com/sitemap.xml (or sitemap_index.xml if your CMS uses a sitemap index that references multiple child sitemaps, which is standard for WordPress/Yoast/RankMath and most large sites).
- In GSC, go to Sitemaps in the left sidebar.
- Under “Add a new sitemap,” enter just the path relative to the domain — e.g., sitemap_index.xml, not the full URL.
- Click Submit.
What to check before submitting
- No 404s or redirects inside the sitemap. Every URL listed should return a clean 200. A sitemap full of redirected or dead URLs signals low quality to Google and wastes crawl budget.
- No noindexed pages in the sitemap. Listing a page in the sitemap while it carries a noindex tag sends Google contradictory signals — this shows up later in GSC as “Submitted URL marked ‘noindex.'”
- Sitemap reflects current site structure. If you’ve recently restructured URLs, merged categories, or migrated a subdomain, make sure the sitemap was regenerated, not cached from before the change.
- Lastmod dates are accurate, if your CMS sets them. Google uses <lastmod> as one (weak) signal for recrawl prioritization — stale or incorrect dates across every URL reduce its usefulness.
After submission, GSC will show a status of “Success” alongside the number of discovered URLs versus the number of URLs actually indexed from that sitemap — this gap (discovered vs. indexed) is one of the first things worth watching over the following weeks.
3. Request Indexing via URL Inspection
Sitemap submission tells Google what exists; it doesn’t force an immediate crawl. For a specific, time-sensitive page — a new post, a fixed page, a page that’s been live for a while but never got indexed — use the URL Inspection tool to request a direct crawl.
- In GSC, paste the full URL into the URL Inspection search bar at the top.
- Wait for GSC to report the current status: “URL is on Google” or “URL is not on Google.”
- If it hasn’t been indexed (or you’ve made meaningful changes since the last crawl), click Request Indexing.
- GSC runs a live test of the page (similar to a mini crawl) before queuing it. This step often surfaces problems immediately — blocked resources, a noindex tag, or a server error — before you even submit.
Realistic expectations: Request Indexing puts the URL into a priority queue; it isn’t instant and isn’t guaranteed. Google typically crawls within a few hours to a few days for most sites, faster for established domains with good crawl history, slower for new domains or ones with a history of thin/low-value content. There’s also a daily quota on manual index requests per property, so this tool is best reserved for pages that genuinely need priority treatment — not run reflexively on every published post.
4. Verify: Crawl Errors, Mobile Usability, Canonical Conflicts
This is the step people skip, and it’s the one that actually confirms the work paid off. Submitting a sitemap and requesting indexing doesn’t mean the page is healthy — GSC needs to report a clean bill of health across three reports.
Coverage / Page Indexing report
Go to Pages (formerly “Coverage”) under the Indexing section and check for:
- Crawled – currently not indexed: Google visited but chose not to index — usually a content quality or duplication signal, not a technical error.
- Discovered – currently not indexed: Google knows the URL exists but hasn’t crawled it yet — often a crawl budget or internal-linking issue.
- Server errors (5xx): hosting/uptime problem at crawl time.
- Redirect errors: redirect chains or loops that stall the crawler.
- Duplicate without user-selected canonical: Google found near-identical content and picked a canonical on its own — worth reviewing against your intended canonical.
Zero errors here is the target. Warnings (like “Indexed, though blocked by robots.txt”) deserve a look even if they’re not hard errors.
Mobile Usability
Under Experience → Mobile Usability, confirm zero issues. Common flags include text too small to read, clickable elements too close together, and content wider than the screen. Since Google indexes mobile-first, a mobile usability problem is effectively an indexing problem, not a cosmetic one.
Canonical conflicts
Canonical issues won’t always throw a hard error — they show up as Google choosing a different canonical than the one you specified. Check this directly in URL Inspection: it reports both “User-declared canonical” and “Google-selected canonical.” If these don’t match, the likely causes are:
- Near-duplicate content across multiple URLs (parameterized URLs, filtered/faceted pages, HTTP vs HTTPS or www vs non-www inconsistency)
- A self-referencing canonical tag that’s missing or malformed
- Internal links pointing inconsistently to different URL variants of the same page
Documenting the confirmation
Once all three checks come back clean, capture it — a screenshot of the URL Inspection panel showing “URL is on Google,” paired with the Pages report showing zero errors and the Mobile Usability report showing zero issues, is the standard proof-of-work artifact for a GSC setup task, especially useful for client reporting or internal QA logs.
5. Where WordPress Plugins Fit (and Where They Don’t)
If the site runs on WordPress, an SEO plugin — RankMath, Yoast SEO, or All in One SEO — can take over part of this workflow, but not all of it. It’s worth knowing exactly where the line is so you don’t assume a plugin has handled something it hasn’t.
What a plugin can do
- HTML tag verification. All three plugins have a dedicated field (usually under a “Webmaster Tools” or “Verification” settings tab) where you paste the Google verification meta tag or just the content string. The plugin injects it into <head> automatically — no manual template editing, and it survives most theme switches since it’s stored in plugin settings, not the theme itself.
- Sitemap generation and upkeep. RankMath, Yoast, and AIOSEO all auto-generate and maintain the XML sitemap, keeping it current as content is published, updated, or unpublished. You still submit the sitemap URL in GSC once manually — the plugin’s job is keeping the file itself accurate afterward.
- Canonical tag management. These plugins auto-set a canonical URL per post/page, which helps prevent the canonical-conflict issue covered in Step 4 before it starts.
What a plugin can’t do
- DNS TXT verification. This happens at the DNS provider level, entirely outside WordPress. No plugin can touch it — if you want the more durable Domain-property verification, you’re still logging into Cloudflare/GoDaddy/etc. directly.
- Request Indexing. This only exists inside the GSC dashboard via URL Inspection. Some plugins offer an “Instant Indexing” module built on Google’s Indexing API (RankMath included), which pings Google automatically on publish — but that API was designed for a narrow set of content types (job postings, livestream events) and Google has publicly said it isn’t reliable for general indexing requests. It doesn’t replace a manual URL Inspection check.
- The verification checks themselves. Crawl errors, mobile usability issues, and canonical conflicts are read from GSC’s own reports, not fixed by a plugin. A plugin can reduce the odds of some of these issues occurring (good canonical defaults, clean sitemaps) but confirming the actual state still requires checking GSC directly.
Practical split
Use the plugin for HTML-tag verification and ongoing sitemap maintenance if that’s the faster path for the team — but favor DNS TXT for the Domain property when durability matters, and always run indexing requests and the four verification checks manually in GSC. No plugin substitutes for that last step.
Quick Reference Checklist
☐ Domain property added and verified via DNS TXT record
☐ TXT record confirmed live via dig TXT yourdomain.com or a DNS checker before clicking Verify
☐ Sitemap live, returns 200, no noindexed or redirected URLs inside it
☐ Sitemap submitted in GSC and status shows “Success”
☐ Target URL(s) run through URL Inspection
☐ Request Indexing triggered for priority page(s)
☐ Pages report shows zero crawl/indexing errors
☐ Mobile Usability report shows zero issues
☐ User-declared canonical matches Google-selected canonical
☐ Screenshot(s) captured as confirmation record
Notes on Timing
None of this is instant. DNS propagation, sitemap processing, and crawl scheduling all run on Google’s own timeline, not yours:
| Step | Typical Turnaround |
| DNS TXT propagation | Minutes to 48 hours |
| Sitemap first processing | Minutes to a few hours |
| Sitemap full crawl of new URLs | Days to a few weeks, depending on domain authority |
| Manual Request Indexing | Hours to a few days |
| Mobile Usability report refresh | Rolling, updates as pages are recrawled |
If a newly verified domain shows no data at all in reports, that’s normal for the first 24–48 hours — GSC needs at least one crawl cycle before Performance and Coverage data start populating.
