Start with one URL and one question
A newly published service page can open normally for you while its Search Console record still shows that it has been discovered but not indexed. The useful question is what you can verify about that exact address. Avoid rewriting the page simply because it is absent from a search you performed.
Create an investigation record before changing anything. Include the inspected URL, inspection time, publication date, current Google status and the person responsible for the next action. Keep the final URL after any redirect beside the original address. This prevents a team from fixing one version while monitoring another.
Collect evidence in separate columns
Use a small table with these columns: observation, evidence, interpretation, action and next check. A successful browser visit is evidence of access from your connection; it is not proof of what Google received. Record an HTTP result separately from a Search Console inspection result.
Google recommends checking crawl availability, robots rules and discovery signals when important pages are not being crawled. It also distinguishes crawling from indexing. Use that distinction to avoid turning every delay into a content-quality diagnosis. If you can access server logs, preserve the relevant period for your technical team instead of drawing conclusions from a single successful request.
Choose the smallest justified change
If the page is absent from your public navigation and relevant articles, identify an existing page where a link would genuinely help readers. If you reproduce a redirect to the wrong destination, correct that route. If the checks reveal no actionable fault, record that outcome and keep observing rather than changing the title every day.
Keep an owner and a verification step for each change. For an internal link, verification means opening the source page and following the link to the intended content. For a server problem, ask for a dated record of the fix and a repeat access check. Neither outcome alone proves indexing.
Worked example: a new agency service page
This example is illustrative, not a customer result. An agency publishes /services/website-migration/ on Monday. On Thursday, the team finds that its services hub still links to an old draft address. The new page loads, but the public route to it is wrong.
The team records both addresses, updates the hub link and checks the destination on mobile and desktop. Its change log says ‘navigation corrected’, not ‘Google indexing fixed’. The next inspection is recorded separately. If the status remains unchanged, the team has preserved evidence instead of losing it through repeated unrelated edits.
Set a follow-up without promising a deadline
Google states that recrawling can take days or weeks and that a request does not guarantee inclusion. Repeated requests for the same URL do not accelerate crawling. For several pages, maintain an accurate sitemap rather than treating each submission as a successful index event.
Choose an internal review date and describe it as your team's checkpoint. Record whether the next inspection changed, whether a new access issue appeared and which evidence supports the next action. A review deadline is not a Google indexing deadline.
Turn the findings into checkable tasks
Use your website audit to collect page-level observations and assign concrete follow-up work. Keep Google inspection evidence alongside that work: a public HTML audit cannot establish that Google has indexed a page. The goal is a clear record of what changed and what remains unconfirmed.