Google Search Console (GSC) is one of the most useful first-party tools for diagnosing how Google discovers, crawls, indexes, and reports on your website. It can show whether a URL is known to Google, which canonical Google selected, whether a page is indexed, how sitemaps are processed, and whether Googlebot encountered fetch or rendering problems.
Search Console does not explain every ranking decision, and an exclusion status is not automatically an error. The practical goal is to understand whether important URLs are accessible, indexable, canonicalized correctly, internally linked, included in appropriate sitemaps, and technically reliable.
This guide covers property verification, XML sitemaps, URL Inspection, Page Indexing statuses, Core Web Vitals reporting, structured-data diagnostics, crawl stats, and a measured workflow for troubleshooting important URLs without treating indexing requests as a guarantee.
This guide was checked against current Google Search Console Help and Google Search Central documentation for property types, ownership verification, sitemaps, URL Inspection, Page Indexing, Crawl Stats, HTTPS, Core Web Vitals and Performance reporting.
Last verified: September 26, 2026. Search Console report names, verification options, data freshness and indexing states can change; confirm the current interface before following screenshots or old tutorials.
1. Domain Property vs URL-Prefix Property
Before creating your property, selecting the right verification method determines whether your data survives theme redesigns, server migrations, and protocol upgrades:
| Property Type | Verification Method | Coverage Scope | Resilience to CMS/Theme Changes |
|---|---|---|---|
| Domain Property | DNS TXT Record | All subdomains, www, non-www, http & https | High when DNS remains under your control |
| URL Prefix | HTML File Upload | The selected URL prefix and URLs beneath it | Medium (requires root directory access) |
| URL Prefix | HTML Meta Tag | The selected URL prefix and URLs beneath it | Variable (can be lost if the verification tag is removed) |
| URL Prefix | Google Analytics | The selected URL prefix and URLs beneath it | Variable (depends on the Analytics tag and permissions remaining valid) |
| URL Prefix | Google Tag Manager | The selected URL prefix and URLs beneath it | Variable (depends on the tag/container remaining correctly installed) |
Use a Domain property when you want one property to cover all subdomains and protocols. Use a URL-prefix property when you need a narrower scope, such as one protocol, host or subdirectory, or when DNS verification is not practical.
For a Domain property, the practical requirement is control of the domain's DNS so you can add the verification record. For URL-prefix properties, Google also supports verification methods such as an HTML file, HTML meta tag, Google Analytics and Google Tag Manager when the required access and permissions are available. Search Console ownership verification itself does not require buying a premium domain, DNS or hosting plan.
2. Step-by-Step Google Search Console Setup & Verification
Step 1: Add Domain Property and Verify via DNS TXT Record
Blogger note: Google-hosted properties such as Blogger can sometimes verify automatically when you use the same Google account that manages the site. For ordinary Domain properties, DNS verification is required. Google notes an exception for some Google-hosted products such as Blogger or Google Sites, where ownership can be verified automatically when the same Google account manages the site.
Log in to Google Search Console and select Domain in the property selector. Enter your naked root domain (e.g., digitalbhatti.com). Copy the TXT verification value generated by Google, open the DNS zone for your domain, and add the TXT record using the host/name format required by your DNS provider. Keep the record in place after verification so ownership can continue to be confirmed. For a step-by-step walkthrough on DNS routing, review our guide on DNS configuration best practices for CNAME and A records.
URL-prefix property methods: Google currently supports several ownership methods for URL-prefix properties, including HTML file upload, HTML meta tag, Google Analytics and Google Tag Manager, in addition to DNS verification. Choose a method you can keep in place; removing the verification token/file can cause ownership verification to be lost.
Step 2: Submit Clean XML Sitemaps
Once ownership is verified, tell Google where to find the sitemap URLs that represent your intended indexable inventory under Indexing > Sitemaps. In Search Console, “submitting” a sitemap means telling Google where the sitemap file lives on your site; the file itself is not uploaded to Google. Sitemaps can help Google discover and revisit URLs, but submission does not guarantee crawling or indexing. A submitted sitemap marked as successfully processed means Google could read it; it does not mean every listed URL is indexed. Keep sitemap entries aligned with your preferred canonical URLs and avoid including redirects, error pages, or intentionally noindexed URLs. For Blogger, use the sitemap URLs Blogger actually generates for your site and submit only sitemap URLs you have verified in the live site. For crawl directives, use the robots.txt SEO Guide rather than creating a second competing robots/sitemap workflow.
Step 3: Review Structured-Data Reports When Available
Search Console can surface structured-data and rich-result reports for supported feature types detected on your site. Use these reports to find invalid markup and implementation problems, but remember that valid structured data does not guarantee a rich result or a specific search appearance. For implementation guidance, continue with our Blogger JSON-LD Structured Data Guide.
Step 4: Review Core Web Vitals Field Data
The Core Web Vitals report groups real-user field data derived from the Chrome User Experience Report where enough data is available. Use it to identify URL groups that need further investigation, then reproduce representative pages with lab tools to diagnose the cause. Continue with our Core Web Vitals LCP, INP & CLS Optimization Guide.
3. Diagnosing and Fixing the Top 6 Critical Page Indexing Issues
The Page Indexing report groups URLs that are indexed and URLs that are not. Many exclusion reasons are intentional or informational rather than errors. Use the status as a starting point, then inspect representative important URLs before deciding whether a fix is needed.
Prioritize important canonical URLs that should be indexed but are unexpectedly excluded. Do not spend time “fixing” redirects, intentional noindex pages or alternate canonicals that are working as designed.
1. "Discovered – currently not indexed"
Google knows about the URL but has not crawled it yet. Possible contributors include weak internal discovery, a very large or rapidly changing URL inventory, limited crawl demand, host-capacity constraints, or low-value URL patterns. Strengthen internal links to important pages, keep sitemaps clean, remove unnecessary crawl spaces, and confirm the server is consistently reachable. Do not assume this status is caused by a single concept such as “site authority.”
2. "Crawled – currently not indexed"
Google crawled the page but has not currently included it in the index. Possible reasons can include duplication, weak differentiation, temporary processing decisions, canonicalization, or content that does not add enough independent value relative to other URLs. Compare the inspected URL with competing pages on your own site and review its intent, canonical signals, internal links, and uniqueness.
3. "Page with redirect" & Redirect Chains
This status means Google encountered a redirect rather than indexable content at that URL. Redirects are normal when URLs move, but internal links should generally point directly to the final preferred destination to avoid unnecessary hops and simplify crawling. Review chains, loops, and destination relevance rather than treating every redirect as a crawl-budget problem.
4. "Alternate page with proper canonical tag"
This usually indicates that Google recognizes the URL as an alternate version and is indexing another canonical URL instead. If that is intentional, no fix may be required. Confirm that your internal links, sitemap entries, redirects, and canonical tags consistently support the preferred HTTPS URL.
5. "Excluded by ‘noindex’ tag"
Google detected a noindex directive in the page HTML or an HTTP response header. If the page is supposed to be searchable, inspect the rendered <head>, CMS visibility settings, theme logic, and any robots-header rules that may inject noindex. Remove the directive only when the URL genuinely belongs in the searchable index.
noindex meta tag or X-Robots-Tag. If robots.txt blocks the URL, Google may not see the noindex directive. Use the robots.txt guide for crawl-control decisions and the appropriate indexing/removal mechanism for removal decisions.
6. "Server error (5xx)" & Host Availability Problems
A 5xx response means the server failed to provide a normal page response when Googlebot requested the URL. Intermittent failures can slow crawling and delay processing of affected pages; persistent failures can make important content unavailable to both users and crawlers. Check application logs, upstream services, reverse proxies, database health, resource exhaustion, and timeouts. For server-latency context, continue with our TTFB and Server Response Time Guide.
4. Practical Indexing Troubleshooting Flow
When an important URL is not indexed, troubleshoot the prerequisites in order instead of repeatedly clicking Request indexing:
Can Google crawl the URL?
↓
Does it return a normal 200 response?
↓
Is indexing allowed (no noindex)?
↓
Is the preferred canonical consistent?
↓
Is the URL internally linked and in the correct sitemap?
↓
Is it substantially distinct from competing/duplicate URLs?
↓
Test Live URL
↓
Request indexing after a meaningful fix if useful
↓
Monitor Page Indexing / Performance over time| Check | What to Confirm | Typical Next Action |
|---|---|---|
| Crawl access | robots.txt does not unintentionally block the important URL/resources | Fix only the rule that is actually preventing intended crawling |
| HTTP response | Preferred URL returns the intended response rather than 404/soft-404/5xx/redirect loop | Repair routing/server/application behavior |
| Indexing directive | No unintended meta robots or X-Robots-Tag noindex | Remove unintended noindex; keep intentional exclusions |
| Canonical | Canonical, redirects, sitemap and internal links support the same preferred URL | Resolve conflicting duplicate/canonical signals |
| Discovery | Important URL has contextual internal links and is present in the appropriate sitemap | Improve internal discovery rather than relying on manual submission |
| Distinct value | Page is not merely a near-duplicate of another stronger URL | Differentiate, consolidate or canonicalize based on actual intent |
5. URL Inspection: What to Check
URL Inspection is the best page-level diagnostic when an important URL has an indexing or canonicalization question.
- Indexing state: whether the inspected URL is indexed.
- Last crawl: when Google last crawled the indexed version.
- User-declared canonical: the canonical you specified.
- Google-selected canonical: the URL Google chose as representative.
- Sitemap/referrer context: where available.
- Robots/indexing directives: whether crawling/indexing signals block the page.
Live Test vs Indexed Data
The indexed view describes Google's stored/indexed understanding of the URL. Test Live URL checks the page's current fetchability and rendering conditions. A successful live test does not itself mean the page is indexed.
| View | What It Represents | What It Does Not Prove |
|---|---|---|
| Indexed data | Google's stored/indexed information for the URL, including canonical and crawl details where available. | That the current live page still behaves identically. |
| Live test | A current fetch/render/indexability check. | That the URL is indexed, will be indexed, or will rank. |
Practical inspection workflow
Use URL Inspection after a meaningful update, migration, canonical change or indexing problem.
- Inspect the canonical URL: Review the indexed status, last crawl information, user-declared canonical, Google-selected canonical, and referring sitemap information when available.
- Run Test Live URL: Confirm that Google can currently fetch the page and detect whether robots directives or fetch problems block indexing.
- Request indexing only when useful: After a meaningful fix or substantive update, you can request indexing. This is a recrawl request, not a guaranteed priority queue or indexing guarantee. Google also limits how many manual indexing requests you can submit, so use the feature for important URLs after meaningful changes rather than routine edits.
- Use Crawl Stats for host-level diagnosis: Review host availability, response patterns, file types, and Googlebot request trends when you suspect server or crawl-capacity problems.
6. Performance Report: Queries, Pages, CTR and Position
The Performance report shows how your site appears in Google Search. Common dimensions include:
- Queries.
- Pages.
- Countries.
- Devices.
- Search appearance.
Common metrics include clicks, impressions, CTR and average position. Use the report to identify pages already receiving impressions before publishing unnecessary new content.
That is one reason Search Console totals can differ from Google Analytics or server logs.
7. Search Console vs Google Analytics
| Tool | Primary Question |
|---|---|
| Search Console | How did the site appear and perform in Google Search, and what does Google report about crawling/indexing? |
| Google Analytics | What did users do after visiting the site, based on analytics collection? |
Do not expect the two systems to match exactly. They measure different events and apply different processing, privacy and time-zone rules.
Search Console counts search impressions/clicks tied to Google Search results, while Analytics measures site/app activity after tracking code or other analytics collection runs. Differences are expected and should not be treated as a data-quality failure by default.
8. Crawl Stats: Use It for Host-Level Diagnostics
The Crawl Stats report shows Google's crawling history, including request volume, response codes, file types, response time and host availability signals.
Google positions Crawl Stats for advanced users and makes it available for root-level properties. For small sites, detailed crawl-capacity tuning is usually less important than fixing discoverability, indexing, server errors and sitemap/canonical issues.
Use Crawl Stats when you suspect:
- Server availability problems.
- Large changes in crawl activity.
- Unexpected response-code patterns.
- Host capacity or crawl-path issues.
For deeper request-level evidence, continue with the Server Log Analysis for SEO.
9. HTTPS Report
The HTTPS report summarizes how Google sees indexed HTTP versus HTTPS URLs and can surface reasons why an HTTPS counterpart is not indexed. Availability can depend on property type and sufficient HTTPS data; treat it as a diagnostic report, not as proof that every HTTPS URL is indexable.
Use it to identify:
- HTTP URLs that still appear in the index.
- Certificate or HTTPS availability problems.
- Canonical inconsistencies between HTTP and HTTPS versions.
10. Build a Technical SEO Follow-Up Path
- Canonical issues: Canonical URLs & Indexing Guide.
- Crawl rules: robots.txt SEO Guide.
- Faceted URL bloat: Faceted Navigation SEO.
- Crawl evidence: Server Log Analysis for SEO.
- Field performance: Core Web Vitals Guide.
Summary: Google Search Console Action Checklist
- Choose a Domain Property when broad DNS-based verification fits your setup; use URL-prefix properties when you need a narrower scope.
- Submit clean sitemaps that contain preferred, indexable URLs.
- For an indexing problem, check crawl access, HTTP status, noindex, canonical consistency, internal links and sitemap inclusion before repeatedly requesting indexing.
- Use URL Inspection to compare Google-selected canonicals, crawl status and live fetchability for important pages.
- Treat Page Indexing exclusions as diagnostic states, not automatic errors.
- Fix persistent 5xx responses and host-availability problems.
- Review structured-data reports when supported, without assuming valid markup guarantees rich results.
- Use Core Web Vitals field reports to find affected URL groups, then diagnose representative pages in the lab.
- Strengthen internal links and clean up unnecessary URL variants instead of repeatedly requesting indexing.
- Monitor sitemaps, crawl stats, and Search Console trends after significant site changes.
Resolve the Technical Signal Search Console Exposes
Search Console identifies symptoms. Use canonical, robots, crawl, internal-link and performance evidence to fix the underlying technical cause.
Open Canonical URLs & Indexing Guide →Frequently Asked Questions
Why does Search Console show different numbers from Google Analytics?
They measure different things. Search Console reports Google Search visibility and clicks, while Google Analytics measures on-site behavior through analytics collection. Privacy filtering, processing, JavaScript availability, time zones and data lag can all create differences.
How fresh is Search Console Performance data?
Normal Performance data can lag by about 2–3 days, although newer preliminary data can sometimes appear sooner. Low-volume queries may also be omitted for privacy.
Should I use site: searches to track indexing every day?
No. A site: search can provide a rough sample, but it is not a complete indexing inventory. Use URL Inspection and the Page Indexing report for important diagnostic decisions.
Do I need paid hosting or a premium domain plan to verify Search Console?
No. Search Console verification requires control over an accepted verification method. A Domain property normally uses DNS verification, while URL-prefix properties support additional methods. Your DNS or hosting provider may expose those controls differently, but Search Console itself does not require a paid upgrade.
Should I block a noindexed page in robots.txt?
Not when you need Google to see the page-level noindex directive. Google must be able to crawl the URL to reliably read a meta robots or X-Robots-Tag noindex rule. Use robots.txt for crawl control, not as a substitute for an indexing-removal directive.
Does submitting a sitemap guarantee indexing?
No. A sitemap helps Google discover and revisit URLs, but Google still decides whether and when to crawl and index each page.
Does Request Indexing force Google to index a page?
No. It asks Google to recrawl the URL, but it does not guarantee crawl timing, indexing, or rankings.
Is "Crawled – currently not indexed" always a content-quality penalty?
No. The status can have several causes, including duplication, canonicalization, temporary processing decisions, or insufficient independent value. Inspect the URL and compare it with related pages before drawing a conclusion.
Should every Page Indexing exclusion be fixed?
No. Redirects, alternate canonical URLs, intentionally noindexed pages, and other exclusions may be correct. Focus on important URLs that are unexpectedly excluded.
What should I check when Google selects a different canonical?
Compare the page's canonical tag with redirects, internal links, sitemap URLs, duplicate versions, protocol/host consistency, and the content similarity between competing URLs.
Can 5xx errors affect crawling?
Yes. Repeated server failures can make pages unavailable and may slow crawling or processing. Diagnose application, database, proxy, resource, and timeout problems rather than assuming the issue is purely SEO-related.
Do valid structured-data reports guarantee rich results?
No. Valid structured data can make a page eligible for supported search features, but Google decides whether a rich result is shown.
Should I request indexing after every small edit?
Usually not. Use indexing requests after meaningful fixes or substantial updates to important URLs. Normal internal linking, sitemaps, and crawling should handle routine changes.
Abdul Shakoor
Founder of Digital Bhatti, focused on web hosting and infrastructure, WordPress performance, Linux VPS environments, web servers and technical SEO.