How to Use Google Search Console Coverage Report

How to Use Google Search Console Coverage Report: Complete Guide to Finding and Fixing Indexing Issues

Google Search Console is a foundational, free platform provided by Google to help website owners, marketers, and SEO professionals monitor, maintain, and troubleshoot their site presence in Google Search results. Unlike analytics tools that focus on user behavior after arriving at a website, Search Console pulls back the curtain on how the search engine itself interacts with web infrastructure. It provides direct insight into how digital content is processed, evaluated, and ranked.

At the absolute core of search engine optimization lies a fundamental reality: website content cannot rank if it cannot be found. This makes indexing arguably the most critical pillar of technical SEO. If search engine spiders cannot successfully parse pages and save them to the vast database known as the Google Index, those pages are effectively invisible to users worldwide. No amount of keyword research, high-quality copywriting, or backlink building can compensate for a foundational indexing error.

To manage this complex pipeline, Google historically provided the Coverage Report, which has evolved into the comprehensive Page Indexing report in modern versions of Google Search Console. This specific reporting suite acts as a diagnostic health check for your website. It serves to identify precisely which sections of a site are successfully live in search results and which ones are facing systemic technical barriers.

Monitoring your page indexing status on a regular basis provides an array of performance benefits. It prevents catastrophic drops in organic traffic, highlights code-level vulnerabilities, uncovers broken internal links, and ensures that critical marketing assets are actively working to generate leads and revenue. By maintaining a clean indexing profile, you guarantee that your technical infrastructure fully supports your broader organic search goals.

This comprehensive guide is designed to transform complex technical documentation into actionable strategies. Readers will learn the precise mechanics of how Google processes website URLs, how to interpret every status trend and indexing category, how to resolve both common and advanced errors, and how to use built-in validation workflows to prove to Google that your issues are permanently fixed.

What Is the Google Search Console Coverage Report?

The Google Search Console Coverage Report, currently labeled as the Page Indexing report, is a dedicated diagnostic command center within the platform. Its primary purpose is to provide complete visibility into the indexing status of every URL that Google has discovered or attempted to crawl on your web property. Instead of forcing webmasters to guess whether their site changes are being recognized, this report delivers clear data on the operational health of the site.

To appreciate the value of this report, it is necessary to understand the distinct sequence that defines the search ecosystem: crawling and indexing. Crawling is the discovery phase where automated software bots, known as spiders or crawlers, scour the internet to find web pages. They accomplish this by reading sitemaps and following hyperlinks from one page to another. Indexing is the storage and organization phase. Once a bot crawls a page, the search engine processes the text, code, visual elements, and overall structure, adding valid pages to its search index to be retrieved during user queries.

Discovery does not guarantee a crawl, and a crawl does not automatically result in an indexation. Google uses discovered pages as raw material, filtering them through a massive algorithmic evaluation pipeline to determine value, structural integrity, and canonical authority. Pages that contain server errors, duplicate content layout structures, or restrictive directives are filtered out during this processing phase.

When critical technical errors break this pipeline, pages drop out of search results, causing a direct contraction in keyword footprints and organic search traffic. Conversely, when non-essential, duplicate, or thin pages fill the index unnecessarily, they dilute the overall authority of the domain and waste limited engineering resources.

Understanding how URLs are distributed requires analyzing three distinct states:

• Crawled Pages: The search engine bot successfully downloaded and evaluated the code and content assets of the URL.

• Indexed Pages: The URL successfully passed all technical and quality thresholds and is now live in the search database, eligible to rank for relevant search terms.

• Non-Indexed Pages: The URL was either explicitly blocked by technical directives, omitted due to duplicate configurations, or rejected because of critical rendering and performance errors.

How to Access the Coverage Report in Google Search Console

Accessing your indexing performance data requires navigating through the primary Google Search Console dashboard. The layout organizes complex database outputs into clean, modular sections that can be segmented for deep analysis.

First, open your preferred web browser and log in to the official Google Search Console portal using the administrative credentials associated with your web properties. Once inside the main dashboard, locate the property selector dropdown menu in the upper left-hand corner of the user interface. Select the specific domain or URL-prefix property that you intend to audit and analyze.

Next, turn your attention to the primary navigation sidebar located on the left side of the screen. Scroll down through the functional groupings until you locate the section labeled Indexing. Under this header, click directly on the option titled Pages.

This action opens the primary Page Indexing details panel. This panel serves as the modern incarnation of the classic Coverage Report, consolidating high-level tracking graphs with granular error logs.

Understanding the Coverage Report Overview

The primary view of the indexing interface presents a macro-level look at your website’s technical health. This overview is built upon a dual-axis chart that tracks historical trends alongside specific status classifications. At the top of this dashboard, the system separates your URLs into two high-level buckets: indexed pages and non-indexed pages. Historically, and within specific technical subsets, these are broken down into four foundational conditions.

Error

This classification represents the most urgent bucket in the reporting suite. When a URL is marked with an error status, it means a severe issue prevented the search engine from indexing the page. These URLs are completely excluded from search results, meaning they cannot appear for any search query, regardless of relevance or authority. Immediate developer or SEO intervention is required to resolve these items.

Valid with Warnings

URLs marked as valid with warnings are actively indexed and can appear in search results, but they possess underlying technical discrepancies that require attention. The most common scenario involves a page that is actively indexed but simultaneously blocked by a directive within the robots.txt file. This signals a conflict in instructions that could lead to unpredictable ranking behavior over time.

Valid

The valid status is the ideal outcome for your target content assets. It indicates that the URLs have been successfully crawled, processed, and added to the index without any structural or technical roadblocks. These pages are fully eligible to display in search results, accumulate keyword rankings, and drive organic traffic to your business.

Excluded

An excluded designation indicates that Google discovered the URLs but intentionally chose not to index them. It is critical to recognize that an exclusion is not inherently an error. In many instances, exclusions represent technical SEO configurations working exactly as designed. For example, pages utilizing noindex tags, pagination URLs, or canonical variations should be excluded to protect the organic authority of primary pages.

Monitoring status trends over an extended timeline is far more valuable than analyzing a single day of data. A healthy website typically displays a steady, stable line for indexed URLs that grows gradually as new content is published.

Sudden, vertical spikes in non-indexed or error counts often signal a catastrophic technical deployment failure, such as an accidental site-wide noindex tag, a misconfigured staging environment, or a broken database connection causing mass server failures. Conversely, a sharp drop-off in indexed URLs requires immediate investigation to determine why previously healthy content is suddenly being dropped from the index.

How Google Classifies URLs in the Coverage Report

The classification of any given URL within the indexing report is the direct output of a sequential technical workflow. Google processing follows a structured timeline, and any friction encountered along this pathway determines the final status label assigned within Search Console.

Phase	Operational Process	Technical Significance
1. Discovery	Google finds the URL via sitemaps, internal link structures, or inbound external backlinks.	The URL enters the queue; crawl priority is calculated based on site authority.
2. Crawling	Search bots request the URL, download the HTML source code, and parse assets.	Evaluates server response codes and reads initial header directives.
3. Processing	The rendering engine executes JavaScript, builds the DOM, and analyzes layout.	Extracts links, checks canonical tags, and evaluates content uniqueness.
4. Indexation	The final rendered page is cataloged into the search index or explicitly excluded.	The page becomes searchable, or it is assigned an exclusion/error category.

This entire workflow is heavily influenced by three technical levers: crawl budget, sitemap signals, and internal linking structures.

Crawl budget refers to the finite number of URLs that search engine bots can and want to crawl on a website within a specific timeframe. If a site is bloated with thousands of broken, duplicate, or unorganized URLs, the crawl budget is exhausted on low-value pages. This can cause critical landing pages to remain stuck in the discovery phase without ever moving to processing or indexation.

XML sitemaps serve as your explicit declaration of intent. By submitting a sitemap, you tell Google exactly which URLs represent primary, high-quality content.

Internal linking acts as a secondary verification mechanism. When primary pages receive strong, consistent internal links from across the site architecture, it signals heavy contextual importance. This prompts Google to prioritize those paths through the discovery, crawling, and indexation pipeline.

Common Coverage Errors and How to Fix Them

When the indexing dashboard surfaces explicit errors, systematic troubleshooting is required to restore visibility to those URLs. Below are the most frequent coverage errors encountered across enterprise web properties, along with their root causes and concrete technical fixes.

Submitted URL Not Found (404)

This error occurs when a URL explicitly listed in your XML sitemap returns a 404 HTTP status code. This means the server cannot find the requested location, signaling that you are actively asking Google to index a broken or non-existent page.

• Causes: The most common cause is deleting a product, page, or post without removing its reference from the underlying sitemap configuration. It can also stem from altering a URL slug without deploying a corresponding redirect or accidentally introducing a typo when manually compiling a sitemap file.

• Fixes: Begin by auditing your sitemap file to remove the broken URL if the page was deleted intentionally. If the content has moved to a new destination, implement a permanent 301 redirect from the old URL to the active page. Finally, if the deletion was accidental, restore the page code and content to return a healthy 200 OK status code.

Server Error (5xx)

A server error indicates that when the search engine spider attempted to access the web page, your hosting infrastructure failed to resolve the request. This means the crawler could not even load the code to evaluate the content.

• Causes: These errors are typically caused by temporary web hosting downtime, server resource exhaustion during traffic spikes, or database timeouts where the application fails to fetch page elements quickly enough. Misconfigured server configuration files (such as .htaccess rules) or conflicting plugin scripts can also trigger 500 Internal Server errors.

• Fixes: Review your internal server error logs at the time of the recorded crawl to identify specific script failures or database bottlenecks. Ensure your hosting infrastructure scale matches your traffic requirements, and optimize server-side caching mechanisms. If errors occur during heavy batch processes, reschedule background operations to run during low-traffic windows.

Redirect Error

A redirect error surfaces when Googlebot tries to follow a redirect chain between URLs but is blocked by a breakdown in the redirection logic.

• Causes: This issue is frequently triggered by redirect loops, where URL A redirects to URL B, which then points directly back to URL A. It is also caused by excessive redirect chains that exceed the maximum number of hops a crawler will tolerate before abandoning the attempt. Bad syntax in routing tables or broken target destination URLs can also trigger this status.

• Fixes: Map out the exact path of the redirection using an HTTP header checker. Break any loops by adjusting the rules to point directly to a final, active destination page that returns a 200 OK status code. Clean up multi-step chains by updating links to bypass intermediate steps, ensuring a clean, single-hop transition from the origin URL to the destination URL.

Blocked by robots.txt

This error emerges when a URL that was explicitly submitted for indexation via a sitemap or manual request is blocked by a disallow rule within your site-wide robots.txt configuration file.

• Causes: The primary cause is conflicting instructions. The sitemap tells Google the page is highly important and should be indexed, while the robots.txt directive tells the crawler it is forbidden from accessing or analyzing that exact same URL path.

• Fixes: Locate your robots.txt file at the root directory of your domain. Audit the disallow rules to find the line restricting access to the affected URL string. If the page is meant to be indexed, remove or modify the disallow rule to open the path for search engine crawlers. If the page should truly be blocked, remove its URL from the XML sitemap entirely.

Submitted URL Marked ‘Noindex’

This error indicates that a URL submitted to Google via a sitemap or manual request contains a meta noindex directive within its HTML header or HTTP response.

• Causes: This occurs when a developer or content manager leaves a staging or development configuration active after launching a page. It can also happen when a content management system checkbox accidentally applies a site-wide or page-specific noindex tag to active marketing landing pages.

• Fixes: Inspect the source code of the affected page or analyze its HTTP response headers. Locate the meta tag containing name=”robots” content=”noindex”. Remove the noindex directive from the page code, ensure it returns a healthy 200 OK status, and refresh your content management system caching layer to push the clean code live.

Soft 404 Errors

A soft 404 error is an algorithmic classification rather than a literal server code response. It occurs when a page returns a successful 200 OK status code to the user’s browser, but Google algorithms determine the page behaves exactly like a broken or missing asset.

• Causes: The most frequent driver is thin content, where a page is completely blank, contains only a navigation menu with zero body text, or features a generic “Product Out of Stock” message. It can also trigger if an application automatically renders an empty search results page or fails to load main content blocks due to JavaScript rendering drops.

• Fixes: Evaluate the page content. If the page represents a valid URL, expand its substance by adding unique text, descriptions, and structural elements. If the page is genuinely empty or represents a deleted asset, adjust your server configuration to return a true 404 or 410 status code. Alternatively, implement a permanent 301 redirect to a highly relevant category or parent page.

Understanding Excluded URLs in Coverage Reports

The Excluded section of the indexing suite is typically the largest data block on a website. It represents pages that Google discovered but deliberately kept out of its index. While many exclusions reflect correct technical setup, unexpected URLs in this bucket can pinpoint hidden crawl issues or content quality drops.

Alternate Page with Canonical Tag

This status means the URL is an exact or near-duplicate variation of another page that your site has correctly identified as the authoritative version via a rel=”canonical” link attribute. Examples include tracking URLs with UTM parameters or specific device variations.

This exclusion indicates your canonical tags are working exactly as designed. Google recognizes the relationship and routes all ranking authority directly to the primary target URL, leaving the secondary parameter variation out of the index to prevent duplication issues. No corrective action is required.

Duplicate Without User-Selected Canonical

This condition occurs when Google discovers a page that matches another page on your site almost perfectly, but your source code fails to provide an explicit rel=”canonical” tag to declare which version is the primary master copy.

Because no instruction was provided, Google algorithms make an educated guess, choose a canonical version themselves, and exclude this specific URL variation. To fix this, review the affected URL and manually implement an explicit canonical tag that points directly to your preferred primary URL. This removes the ambiguity and stabilizes your indexing architecture.

Crawled – Currently Not Indexed

This label indicates that Google successfully crawled the URL and examined its underlying code, but ultimately decided not to add it to the search index. The page sits in a holding pattern.

This is often a quality issue rather than a structural or coding breakdown. Google does not believe the content offers enough unique value, depth, or utility to justify inclusion in its public index. To resolve this, audit the page for content depth. Eliminate duplicate paragraphs, add authoritative insights, improve formatting, and ensure the page provides real value to searchers.

Discovered – Currently Not Indexed

This status means Google found the URL and placed it in its processing queue, but has not yet crawled or rendered the page. The search engine knows the link exists but has not downloaded its HTML code.

The root cause usually maps back to crawl budget limitations or severe server performance issues. If the server responds too slowly, Google throttles crawl speeds, leaving discovered URLs waiting indefinitely. To resolve this, focus on optimizing your crawl budget. Speed up server response times, trim down unnecessary redirect paths, clean up massive internal links to junk pages, and ensure your core internal linking structure highlights these pending pages.

Page with Redirect

This category lists URLs that automatically forward users and search engine bots to a different destination.

This is standard behavior for active redirections. Because the URL acts as a bridge rather than a final destination, Google excludes the source URL and focuses its indexing resources on the target landing page. Review this list simply to verify that no primary content URLs are accidentally caught in a redirect loop or chain. If the redirection is intended, this exclusion requires no fix.

Blocked Due to Other 4xx Issue

This classification indicates that the URL returned a 4xx level client error status code when crawled, excluding standard 404 errors. This includes states like 403 Forbidden or 401 Unauthorized responses.

This means your server infrastructure explicitly blocked the Googlebot scraper from accessing the page content. Check your hosting configurations, firewall rules, and password-protection directories to ensure you are not accidentally blocking search spiders from reaching active, public-facing parts of your website.

How to Use the URL Inspection Tool Alongside Coverage Reports

The Page Indexing report provides an aggregate look at your site health, but the URL Inspection Tool allows you to run deep diagnostics on individual pages. This feature is located at the top of the Search Console interface as a prominent search bar.

To inspect a page, copy the full URL string, paste it into the inspection bar, and hit enter. The system queries the live Google Index database to return a real-time summary of that specific page’s status. It shows whether the URL is currently eligible to appear in search results, along with its discovered sitemaps, last crawl timestamp, crawling user agent, and declared versus Google-selected canonical tags.

When troubleshooting, the Test Live URL feature in the upper right corner is highly useful. This bypasses cached data to run a live test on the page’s code. It checks the live server response, evaluates JavaScript rendering execution, and flags any blocking resources or schema markup errors in real time.

This creates a highly efficient diagnostic workflow for resolving technical SEO issues. When an error is uncovered within the aggregate Page Indexing report, pasting that URL directly into the inspection bar immediately pinpoints the operational failure. By assessing the live crawl logs and canonical conflicts, developers can isolate the root cause, deploy a localized technical fix, verify the resolution using the live rendering test, and request immediate recrawling via the “Request Indexing” interface.

How to Validate Fixes in Google Search Console

Once you deploy technical fixes to resolve indexing errors on your server or within your content management system, you must officially notify Google to re-evaluate the affected URLs. This formal process is handled via the validation workflow built into each error detail screen.

Start by clicking into a specific error or warning type within the Page Indexing report dashboard. This opens an isolated view showing the historical trend graph for that specific issue, along with a granular sample list of affected URLs. At the top of this detailed view, locate and click the button labeled Validate Fix.

Once you initiate validation, the system changes the status label to Started. Google then runs a preliminary check on a subset of the affected URLs. If those initial checks look clean, the status shifts to Looking Good.

Over the following days and weeks, Google systematically adds the remaining URLs to its recrawling queue. If the search bots confirm the issue is completely resolved across all sample URLs, the item updates to Passed. The error is then cleared from your active issues log, and the affected URLs move into the Valid or Excluded category as intended.

However, if search bots encounter the exact same error condition during their recrawl, the process halts, and the status updates to Failed. When a validation fails, analyze the specific URLs flagged during the recrawl. Check your caching configurations, server firewalls, or code templates to ensure your fixes were applied globally rather than just on a handful of pages.

Coverage Report SEO Best Practices

Maintaining a clean page indexing dashboard requires a proactive technical strategy. Rather than waiting for errors to accumulate and disrupt your organic traffic, build these core technical SEO habits into your regular site maintenance routine.

• Keep XML Sitemaps Clean: Your XML sitemap should serve as a pristine directory of your primary, canonical, public-facing URLs. Never allow broken URLs, redirect loops, or pages with noindex tags into your sitemap files. Keep your sitemaps fully synchronized with your active site architecture so search engine bots can always find your highest-value assets.

• Improve Internal Linking: Search engines use your internal link architecture to calculate context, topical authority, and crawl priority. Ensure your primary landing pages are well-supported by descriptive internal links embedded within body text across your site. Avoid creating orphan pages—which are pages that exist on the server but have zero internal links pointing to them. These are incredibly difficult for search engines to discover and maintain in the index.

• Monitor Crawl Errors Regularly: Do not treat your Search Console account as a reactive tool to visit only after a traffic drop occurs. Build a habit of auditing your indexing reports at least once a week for small to mid-sized sites, and daily for massive enterprise or e-commerce properties. Catching an error early prevents a minor code glitch from ballooning into a site-wide ranking drop.

• Fix Broken Pages Quickly: A high volume of unresolved errors degrades the overall technical health score of your domain. Set up automated alerts to catch internal links pointing to 404 errors or server bottlenecks. Fix broken pages immediately through content restoration or permanent 301 redirects to maintain a smooth path for both users and search crawlers.

• Avoid Thin Content: Google reserves its index space for pages that offer real value. Avoid publishing hundreds of near-empty, auto-generated tags, or duplicate thin pages. If a page does not contain substantial, helpful information, either flesh it out with high-quality content, consolidate it into an existing parent page, or use a noindex tag to keep it out of the search index entirely.

• Use Canonical Tags Correctly: Ensure every single page on your website features an explicit, fully qualified self-referential canonical tag by default. When you intentionally deploy duplicate variations for tracking, sorting, or filtering purposes, ensure those alternate URLs point their canonical tags directly back to the primary master page. This eliminates indexing ambiguity and protects your link equity.

• Audit robots.txt Regularly: Treat your robots.txt file as a powerful tool that requires strict accuracy. Review your directive blocks after every major site redesign or code deployment. Make sure you aren’t accidentally blocking critical assets like primary CSS styles, critical layout JavaScript modules, or entire content subfolders that need to be parsed to rank properly.

Coverage Report Mistakes to Avoid

When teams begin monitoring technical SEO metrics through Search Console, it is easy to misinterpret raw data. Avoiding these common mistakes will save time and prevent unnecessary development work.

First, do not panic over an increasing count of excluded pages. A large excluded bucket is often a sign of a well-optimized technical setup, showing that your canonical tags, noindex directives, and parameter rules are successfully guiding Googlebot away from low-value, duplicate pages. Focus your energy on real errors rather than trying to force every single URL on your server into the indexed category.

Second, never ignore crawl anomalies or minor spikes in server errors. A sudden jump in 5xx codes often points to underlying database lag or hosting resource limits during specific hours. Addressing these server drops early keeps your crawl budget optimized and keeps your site running smoothly.

Third, avoid manually submitting every single new URL through the URL Inspection Tool. While requesting an manual index is great for urgent page updates or time-sensitive news, relying on it for standard content publication means your underlying discovery system is broken. Instead, focus on building a natural internal link structure and a clean XML sitemap automation that allows Google to find your content organically.

Finally, clean out your outdated, static sitemap URLs. Leaving dead links or old migration paths inside your sitemaps forces Googlebot to repeatedly crawl broken pages, wasting your crawl budget and slowing down the discovery of your newest content assets.

Final Thoughts

The Google Search Console Page Indexing report serves as the absolute foundation for technical SEO monitoring. By translating complex server communications and database statuses into clear charts and error logs, it gives website owners a direct window into how Google processes their site infrastructure.

Managing indexation requires looking past individual raw numbers and understanding the overall trend lines. Remember that a high volume of excluded URLs is often completely healthy, representing canonical structures and parameter controls working exactly as designed. Your primary goal is to keep true errors at zero, streamline your crawl paths, and ensure that your highest-value content is fully indexed and eligible to perform in search results.

Technical optimization is an ongoing process rather than a one-time project. By combining the macro-level views of your coverage reports with the granular data in the URL Inspection Tool and keeping clean sitemap configurations, you can build a resilient search presence. Regular audits protect your organic rankings, optimize your crawl budget, and ensure your site’s technical foundation fully supports your digital growth.

Quick Reference Summary

Error Classification	Common Root Cause	Primary Resolution Action
Submitted URL Not Found (404)	Page deleted but left inside XML sitemap	Remove URL from sitemap or implement a 301 redirect
Server Error (5xx)	Hosting downtime or database timeout issues	Optimize server resources and audit error logs
Redirect Error	Active redirect loops or excessive chains	Point origin URL directly to the final 200 OK destination
Blocked by robots.txt	Disallow rules conflicting with sitemap submissions	Modify robots.txt directives to open the crawl path
Submitted URL Marked ‘Noindex’	Active noindex tags left in production code	Remove the meta noindex attribute from the HTML header
Soft 404 Error	Thin content pages or empty search layouts	Add unique content value or return a true 404 code

Google Search Console Page Indexing FAQ

Why does Google Search Console say “Discovered – currently not indexed” for my new pages?

The “Discovered – currently not indexed” status means that Google knows your URLs exist but has not yet queued them for a crawl. This usually happens for one of two reasons: either your website has hit its temporary crawl budget limit, or the server was experiencing high load when Google attempted to schedule the crawl. To speed up indexation, ensure your internal linking structure passes authority to these new pages, keep your XML sitemaps clean, and double-check that your server response times are optimized.

How do I fix “Crawled – currently not indexed” errors in Google Search Console?

When a URL is labeled “Crawled – currently not indexed,” it means Google successfully downloaded and evaluated the page but actively chose not to include it in the search index. This is typically a quality signal rather than a technical coding error. To fix this, you must improve the content value of the page. Audit the URL for thin text, eliminate any duplicate paragraphs shared with other pages on your site, add unique data or helpful imagery, and ensure the page satisfies a distinct user search intent.

How long does Google Search Console validation take after fixing an indexing error?

Google Search Console validation is not instantaneous and typically takes anywhere from a few days to several weeks. When you click the “Validate Fix” button, the status updates to “Started” while Google runs an initial check on a small sample of your URLs. If successful, the status changes to “Looking Good” as Google gradually recrawls the remaining affected pages. The timeframe depends entirely on how large your website is, how much crawl budget Google assigns to your domain, and the priority of the pages being re-evaluated.

What is the difference between a hard 404 error and a soft 404 error in GSC?

A hard 404 error occurs when your web server explicitly returns a correct 404 “Not Found” HTTP status code, telling search bots that the page is permanently gone. A soft 404 error occurs when a page returns a successful 200 “OK” status code to the user’s browser, but Google’s algorithms look at the page and determine it behaves like a broken asset anyway. This happens if a page is completely blank, contains thin or low-quality text, or displays a generic “out of stock” message without the proper backend technical status codes.

Why are my indexed pages dropping in the Page Indexing report?

A sharp drop in your indexed pages usually points to a significant technical site change or server deployment issue. Common culprits include accidentally pushing a development environment or staging setup live with a site-wide “noindex” tag, introducing blocking rules inside your robots.txt file, or severe database connection dropouts that cause mass 5xx server errors during a Google crawl. Run your primary URLs through the live URL Inspection Tool to see exactly what instructions the search engine bot is currently receiving.