Give a discovered but uncrawled service page a reliable discovery path

Separate being found from being fetched

A useful starting question is whether the service page is truly published and reachable, not whether it has received visitors. The discovered status describes an earlier point in Google's processing. It is different from a fetched page that Google subsequently did not index. Capture the exact URL so a typo, preview address, or old domain does not become your test case.

Source checks: Google Search Console: Page indexing report · Google Search Central: Crawlable link practices · Google Search Central: Build a sitemap

Walk the route as a first-time visitor

Start on the public homepage and reach the page through normal navigation. Count the steps and record each destination. Check that the final page works without signing in, choosing a location, or opening the editor. A public page with no relevant route from the main site deserves a navigation repair even before search outcomes are considered.

Check that navigation produces a real link

Ask the website editor to inspect the link element rather than judging its button styling. Navigation to a service should expose a usable destination URL in an anchor's href. A script-only click can work for a human while offering a less reliable discovery path. Add the link where readers already evaluate related services; avoid creating an unexplained footer full of phrases.

Check publication and discovery records

Use a short evidence sheet for the page and one known, working comparison page.

• Open each destination in a signed-out browser and record whether it serves real content.
• Find the service URL in the current published sitemap, using its preferred spelling.
• Test the exact internal link, including any trailing slash or changed path.
• Check whether host errors coincide with the page's first publication.
• Send the editor specific failing URLs instead of a request to index the whole site.

Do not manufacture an explanation from missing fields

An absent referring-page value is not a complete inventory of your internal links. Similarly, sitemap inclusion shows that a URL was supplied; it does not guarantee crawling or indexing. If the route and host work, give a new page time to be processed. Do not publish dozens of adjacent pages to solve a discovery problem with one important service.

Follow up using the changed route

Record when the link or publication issue was corrected. Confirm the destination immediately and recheck Google's crawl evidence later. If the status changes to crawled-but-unindexed, begin a different diagnosis focused on the returned page and its purpose. Keep the earlier route test so you can demonstrate which stage improved rather than treating every nonindexed status as the same failure.

Illustrative published page hidden behind a widget

An illustrative landscaper publishes /irrigation-repair but links it only inside a JavaScript service picker. The sitemap contains the URL, yet the services overview offers no direct route. The editor adds a descriptive anchor within the irrigation section and confirms a public successful response. The owner records the new route and later checks whether a crawl date appears; no ranking improvement is assumed.

The test row records homepage to services overview to /irrigation-repair, including the actual href at the middle step. The editor also opens /irrigation-repair directly. If that direct request fails, adding a link is not sufficient; the destination's publication problem needs its own repair.

Questions about this task