TL;DR
A page can look correct to your staff and still be difficult for Google to discover or read. Test four separate gates: a discoverable link, public access, meaningful rendered content and indexing status. The first failed gate tells your web team where to investigate.
Gate one: can the page be found?
Choose an important service page and a location page. Starting at the homepage, find the normal links a visitor would follow. Do not use a staff bookmark as proof that the website exposes the route.
Google generally discovers crawlable links through anchor elements with an href that resolves to a URL. A decorative button controlled only by a script may need implementation review. Google’s link guidance explains the technical distinction.
Record the page that links to your target and the link’s visible wording. “View our downtown office” gives the reviewer more useful evidence than “the menu works.” If the page is orphaned, add an appropriate link from a relevant page; avoid inserting it into every paragraph across the site.
Gate two: is public access working?
Open the exact URL in a signed-out browser. Record the final address after any redirect. Check for a login prompt, challenge screen, error or unexpected destination. Then ask the web team to inspect the response status, robots instructions and hosting rules that apply to legitimate crawlers.
A successful staff session is not enough: your browser may have a login cookie or an allowlisted network. Conversely, an intentional private portal should remain private. Ask for a narrow diagnosis of the public page rather than a blanket removal of security controls.
Gate three: is the important content present?
Identify three facts the page must communicate: the service or location, the practical explanation and the next step. Confirm those are available as readable text, not solely in a hero image, video or interaction that has not run.
JavaScript is not automatically a problem. Google processes crawling, rendering and indexing separately, and its documentation explains both JavaScript support and rendering limitations. An empty initial page therefore needs a rendered-content check, not an assumption that all script-based sites fail. Google’s JavaScript SEO guide describes that process.
Gate four: what does indexing evidence say?
Ask the person with Search Console access to inspect the same URL. Capture the indexed report’s state, Google-selected canonical and any access issue. This report describes Google’s indexed information; it is not a live check. Use the live test separately to investigate current access. Google’s selected canonical is available only in the indexed data, and the live test cannot predict it. Google’s URL Inspection guidance explains that distinction.
Compare the inspected URL with the address you actually want discovered. A duplicate version pointing to another canonical calls for a different fix from a page blocked by noindex.
Passing the first three gates does not guarantee inclusion. It removes identifiable obstacles so the team can investigate the remaining explanation with better evidence.
Send a useful issue report
For a location page missing from search, include the exact URL, referring page, signed-out result, three missing or present facts, inspection date and screenshots of relevant diagnostics. “Publish more blogs” is not a diagnosis for that location page.
After a fix, repeat the failed gate and test the full path again. Keep the before-and-after record with the ticket. A changed robots setting means little if the link still routes visitors to a preview domain.
Frequently asked questions
Does a sitemap replace navigation?
A sitemap can help Google discover URLs, but it does not guarantee crawling or indexing. Visitors still need useful links. Review both when a page is difficult to find. Google’s sitemap overview explains the discovery limit.
Should private appointment records become crawlable?
No. This audit concerns public business information. Private systems need their own access controls and appropriate technical oversight.