When a website or page does not appear in Google, first identify which stage has failed. Discovery, crawling, rendering, indexing and ranking are different processes. A controlled diagnosis is safer than repeatedly requesting indexing or changing several technical controls at once.
CHECK 1
Confirm whether the issue is indexing, ranking or the wrong search test
Search for the exact URL in Google Search Console before relying on a normal Google search. A page may be indexed but not rank for the query you tested. It may also appear under a different canonical URL, or Google may know about the URL without selecting it for indexing.
Record the exact affected URLs, when they were published, whether they were previously indexed and whether the issue affects one page, one template or the complete website. This scope determines whether you should inspect page-level signals, a template rule or a site-wide access problem.
CHECK 2
Verify that Google can access a working, indexable page
Google documents three minimum technical requirements: Googlebot must not be blocked, the URL must return a successful HTTP response, and the page must contain indexable content. Meeting those requirements makes indexing possible, not guaranteed.
- The preferred URL returns HTTP 200.
- The page is publicly accessible without login.
- Robots.txt does not block required crawling.
- No robots meta tag or HTTP header applies
noindex. - Important text is present in the rendered page.
- CSS and JavaScript required for rendering are accessible.
- The URL does not redirect through a broken or looping chain.
Use Google’s current technical requirements as the baseline. Do not use robots.txt as a substitute for a noindex directive because blocking crawling can prevent Google from seeing the directive.
CHECK 3
Read the URL Inspection result before choosing a fix
Inspect the preferred URL in Search Console. Compare the user-declared canonical with Google’s selected canonical, review the last crawl, inspect the fetched page and test the live URL. Then check the Page Indexing report for patterns affecting similar URLs.
A live test confirms current access but does not prove that the page will be indexed. The indexed result can reflect an earlier crawl. After a validated fix, request indexing once and allow time for recrawling instead of submitting the same URL repeatedly.
- URL is known to Google.
- Crawl is allowed.
- Page fetch succeeds.
- Rendered content matches the customer-facing page.
- Canonical points to the intended URL.
- No manual action or security issue applies.
CHECK 4
Check whether another URL is being treated as the primary version
Duplicate or closely overlapping URLs can cause Google to choose a different canonical. Review HTTP and HTTPS, www and non-www, trailing slash variants, URL parameters, print views, tag archives and location pages with substantially similar content.
Use one crawlable preferred URL, self-referencing canonical markup where appropriate, consistent internal links and direct redirects from retired duplicates. Canonical markup is a signal, not a command. Contradictory redirects, sitemap entries and internal links can weaken it.
Do not canonicalize a useful service page to the homepage merely because the service page is temporarily weak. Improve or consolidate the page based on customer intent, then use a permanent redirect when a separate URL no longer deserves to exist.
CHECK 5
Give important pages a clear path from the website structure
An XML sitemap helps discovery, but it does not guarantee indexing or ranking. Important pages should also receive descriptive internal links from navigation, service hubs, relevant guides and contextual sections. Orphaned pages can be technically valid yet difficult for search systems and people to discover.
Keep the sitemap limited to preferred indexable URLs that return HTTP 200. Remove redirected, duplicate, noindex and error URLs. Submit the sitemap in Search Console and investigate a sudden difference between submitted and indexed page groups.
For local service websites, connect each priority service page to relevant proof, service-area information, related questions and the appropriate conversion path. Internal links should explain the relationship instead of repeating an exact keyword everywhere.
CHECK 6
Make the indexed version useful enough to keep
A technically accessible URL can still remain unindexed when it adds little distinct value. Compare the page with overlapping service or location pages. Confirm that it answers a separate customer need and contains real business facts, process, proof, coverage and next-step information.
JavaScript-generated content can be indexed, but rendering adds complexity and failure points. Important headings, service details, links and calls to action should be present reliably in the rendered HTML. Test the mobile result because Google uses mobile-first indexing.
Changing only a city name does not create a useful local page. Consolidate overlapping areas unless each page can provide distinct operating information and genuine local evidence.
CHECK 7
Retest the complete path and monitor the page group
- Deploy one controlled fixRecord the old state, changed files and intended outcome.
- Test the live URLVerify response, directives, canonical, rendering and internal links.
- Update discoveryUse the preferred URL in internal links and the XML sitemap.
- Request indexing onceUse URL Inspection for a priority page after the fix is live.
- Monitor the templateReview index coverage, impressions and crawl behavior over a useful period.
Google notes that crawling and indexing take time and cannot be guaranteed. Keep a dated record so normal processing delays are not mistaken for a new technical failure.
COMMON QUESTIONS
Questions local businesses ask
How long does Google take to index a page?
There is no guaranteed timeline. Discovery, crawl demand, site quality, internal links, server behavior and page value can all affect processing. Verify the technical path, request indexing once for a priority URL and monitor Search Console.
Does submitting a sitemap guarantee indexing?
No. A sitemap helps Google discover preferred URLs. Each page must still be crawlable, indexable and useful enough for Google to select it.
Should I request indexing every day?
No. Repeated requests do not replace fixing the underlying issue. Submit after a meaningful validated change, then allow time for recrawling.
NEXT PRACTICAL STEP
Diagnose the failed stage before changing the page.
Use this sequence to document the evidence, or request a technical website review when the problem affects several templates or business-critical pages.