Start with the reported status
You've published an important service page, but Search Console reports Crawled, currently not indexed. Before paying for a rewrite or a technical repair, establish what the evidence supports.
Google's Page indexing report defines this as a page Google has crawled but hasn't indexed. Discovered, currently not indexed means Google knows the URL but hasn't crawled it yet. Google also explains that non-indexed pages don't always need attention. An exclusion alone doesn't establish a penalty, a crawl-budget problem or poor content.
A page selling a distinct, commercially important service deserves investigation. Let the evidence determine the remedy.
This also affects Google Search and AI eligibility. Google's technical requirements for AI supporting links require an indexed page that's eligible for a Search snippet, with no additional technical requirements. Eligibility doesn't guarantee selection. Once indexing and snippet eligibility are confirmed, you can separately investigate missing AI citations.
Confirm the current evidence for the exact URL
A report entry, an indexed inspection record and a live test describe different evidence. Google's URL Inspection documentation distinguishes information about the version Google holds from a test of whether the current URL might be indexable. A live result saying URL is available to Google doesn't establish indexing or predict Google's canonical selection.
- Copy the complete URL, including protocol, hostname, path and any parameters. Open the Search Console property containing that URL.
- Inspect the URL and save the exact indexed status, inspection capture time and last crawl date where available. Don't substitute the Page indexing report's refresh date for the URL's crawl date.
- Run a live test separately. Record its test time, result, crawl and indexing permissions, and any fetch problem shown.
- Check the current response, indexing directives and declared canonical in the deployed page or headers. Record Google's selected canonical only where the indexed inspection exposes it.
- Compare the crawl and test times with the latest relevant deployment. Note which version each observation can describe.
Mark fields unavailable when Search Console doesn't provide them. In particular, a missing selected canonical isn't proof that Google has selected the inspected URL. If crawled HTML or a rendered screenshot isn't available, record that limitation before drawing conclusions about what Google saw.
If current inspection shows a different exclusion, update the diagnosis. A duplicate status or unexpected canonical belongs in the guide to investigate Google's selected canonical. If available rendered evidence omits important service content, audit missing rendered service content.
A current technical problem can justify action even when the older crawl record can't establish whether it caused the original exclusion. Keep that uncertainty in the handoff.
Decide whether this page needs its own indexed result
Off Piste's prioritisation method starts with the service and the buyer. Name the offer, the audience and the decision this URL helps someone make. Then ask whether an indexed page already does that job adequately.
An independent commercial solar maintenance service might need a different page from residential panel installation. Its buyer, scope, maintenance arrangements and procurement questions may differ. A second page that changes only the suburb name while describing the same offer has a weaker case for independent ownership.
Use your service catalogue, customer questions and existing pages to decide which page owns the buyer's search job. Business importance sets the investigation's priority. Google still decides whether to index the URL.
Prioritise an important independent offer with no adequate indexed destination. Give lower urgency to a redundant variation while the content owner decides whether to retain it. If two pages genuinely serve equivalent purposes, consolidation needs an agreed retained destination and publishing-owner approval. Preserve a distinct service's destination while you investigate its exclusion.
Keep a dated evidence record
A useful record lets the next person reproduce the investigation. Keep observations, interpretations and pending evidence in separate fields so a plausible explanation doesn't become an accepted fact through repetition.
Use this checklist for each priority URL.
Page purpose and priority
- Full URL, intended service, buyer and search job.
- Business priority and the reason for investigating now.
- Publishing owner and any existing page that might serve the same purpose.
Dated observations
- Inspection capture time and timezone, indexed status and last crawl date.
- Live test result and test time, recorded separately.
- Current response, redirects, crawl permissions and indexing directives, with the checking method.
- Declared canonical and Google-selected canonical where available. Mark unavailable fields explicitly.
- Available crawled or tested HTML and rendered evidence, with links to captures and any limitations.
- Relevant internal links, sitemap presence and the indexed service peer chosen for comparison.
Interpretation and next decision
- Working hypothesis and the observations supporting it.
- Contradictory observations, missing evidence and the person who will collect it.
- Smallest proposed change, responsible owner and technical pass condition.
- Release time, next review date and the separate indexed outcome, marked pending until supported.
Google's sitemap guidance explains that sitemaps help discovery without guaranteeing crawling or indexing. It also describes how navigation and page links help Google find pages. Record both, but adding an already crawled URL to a sitemap doesn't establish a remedy for its exclusion.
Compare the page with an indexed service peer
Consider a hypothetical business with an indexed example.com/services/commercial-solar-maintenance page and an unindexed example.com/services/solar-system-servicing page. This Off Piste example uses invented observations, with no client records or claimed indexing outcome.
The maintenance page identifies facilities managers as its audience. It explains scheduled inspections, what the service includes, what needs a separate quote and how access to the premises is arranged. It includes relevant team credentials and an approved example of the work. A commercial solar overview links to it in a paragraph about ongoing maintenance.
The servicing page addresses “all solar customers” and repeats broad statements from the main solar page. Its scope leaves commercial and residential buyers guessing whether the service covers their systems. Its expertise claims are generic, and the only internal route is a footer link. In this example, both pages return normally and their available tested HTML contains the visible service text.
Compare the same dimensions on your own pages. Look at audience, service scope, evidence of expertise, useful decision detail, contextual internal routes and template output. Choose a service peer with a comparable buyer job so differences in page purpose don't distort the comparison.
Here, the comparison supports a hypothesis that the servicing page has an unclear independent purpose. The content owner should first determine whether it represents a separate service. If it does, the smallest useful improvement is accurate detail about that offer and a relevant route from the service overview. If it's equivalent to maintenance, consolidation may be more useful than another rewrite.
Peer differences generate hypotheses, rather than proving why a URL was excluded. Copying the indexed page's format offers no guarantee of inclusion.
Choose the next action the evidence supports
Choose an Off Piste investigation route whose evidence and pass condition you can name.
Monitor with an owner and checkpoint
Monitoring fits when the page has a justified role and the investigation hasn't established a useful change. The SEO or marketing owner retains the evidence record, notes what's unresolved and sets the next inspection checkpoint. The smallest justified action may be collecting fresh evidence rather than editing the page.
The monitoring pass condition is a documented review and an explicit decision to continue, change route or close on fresh evidence. The checkpoint schedules a review, with no promised indexing deadline.
Repair a reproduced technical defect
Repair fits when testing reproduces a concrete fault, such as an unintended indexing directive, an incorrect canonical declaration or missing rendered service content. Give the developer the affected URL, reproduction steps and expected output. Use the canonical or rendering specialist guide for that repair.
The smallest change should address the reproduced fault. Its technical pass condition is that the deployed page now returns the intended response, directives or rendered content under the relevant checks. Indexing remains a separate outcome. If the same confirmed defect affects a shared template, scope work to repair the affected website templates.
Improve a supported content or discovery gap
Improvement fits when the page has a distinct service role and the evidence identifies missing buyer detail, unsupported expertise claims or weak relevant internal routes. The service owner supplies accurate scope and proof, while the editor or SEO owner implements the bounded change.
The pass condition is that the identified information gap has been filled truthfully and the intended contextual route works. Avoid arbitrary word counts and repeated rewrites without a new hypothesis. A better page can still remain unindexed.
Consolidate an equivalent page
Consolidation fits when the publishing owner establishes that another page serves the same buyer and service purpose. Record the equivalence, retained destination and any useful material that must survive. Have the responsible editor and developer implement the agreed merge and appropriate URL handling, including relevant internal-link updates.
The pass condition is an accepted publishing decision with the intended retained page and URL behaviour verified. Keep redirects specific to equivalent pages. Consolidation resolves ownership, while indexing of the retained destination remains Google's decision.
Verify the change and keep the indexed outcome separate
A release can pass technical checks while the indexed outcome is still pending.
- Record the deployment time and check the exact live URL. Verify the expected response, directives, canonical declaration, content and internal links relevant to the change.
- Run a fresh live test and save the result with its timestamp. Record anything the test can't establish.
- After a justified change, request indexing proportionately through URL Inspection where appropriate. Google's recrawl guidance says a request doesn't guarantee inclusion and repeated requests won't accelerate crawling.
- At the recorded review, inspect the indexed evidence again. If the last crawl predates the release, leave the post-change indexed outcome pending. If newer evidence shows continued exclusion, reassess the hypothesis before commissioning another change.
Close the investigation only with fresh evidence supporting inclusion, an accepted and verified consolidation, or an explicitly documented monitoring decision. Record which outcome applies.
If several valuable service pages retain the same unresolved pattern, use their records to scope the unresolved indexing diagnosis. Include the affected URLs, current inspections, peer comparisons and unanswered questions so the next investigation has a defined starting point.
Record the chosen route, responsible person and next review, including any observation still needed to make the decision.