The Pages report in Search Console is the closest thing to a diagnostic readout that a clinic website has, and it is routinely misread. Every excluded URL is given a status, each status has a distinct meaning, and applying the wrong fix to the wrong status is how teams spend months producing no change. This article works through the statuses that a clinic site actually generates.
Not found and server errors
A 404 in the report is only a problem if the URL should exist. Clinic sites accumulate genuine 404s when treatment pages are renamed without redirects, and this is the most common cause of a sudden drop on a page that used to perform. If a URL is dead and had value, redirect it permanently to the closest genuine equivalent. If there is no equivalent, let it return 404 rather than redirecting everything to the homepage, which produces a soft 404 and helps nobody.
Server errors are more urgent. Repeated 5xx responses reduce crawl rate because the crawler backs off to avoid overloading the site. A clinic site that goes down for a few hours each week under a cheap hosting plan is training the crawler to visit less often, and that shows up as stale content in the index long after the hosting is fixed.
Discovered, currently not indexed
The URL is known and has not been fetched. On a small site this usually means the crawler does not consider the URL worth the request, which is a signal about perceived importance rather than a technical fault. It appears in volume when a site generates large numbers of near-identical URLs, for example a booking calendar that produces a URL per date, or filtered listings that multiply combinations.
The fix is to reduce the number of low-value URLs the site offers and to strengthen internal linking to the ones that matter. Adding the URL to a sitemap again does not solve it, because the URL was already discovered. That is what the status says.
Crawled, currently not indexed
The page was fetched and the system chose not to store it. This is a judgement about value, and on clinic sites it is nearly always one of three things: the page is a thin variant of another page, the page is a location or treatment stub with two hundred words of generic copy, or the page is a service page that repeats the site's boilerplate with one word changed.
A treatment page template with a fixed introduction, a fixed consultation section, a fixed FAQ and a variable name produces pages that are ninety per cent identical to each other. They are cheap to produce and they are the single most common cause of this status on clinic sites. Fewer, longer, genuinely differentiated pages outperform a large set of near-duplicates, every time.
The correct response is editorial. Either write the page properly, with the specifics that make it different from its siblings, or consolidate several stubs into one substantial page and redirect the rest into it.
Duplicate without user-selected canonical
The system found several URLs with substantially the same content and picked one. Your preferred URL lost. This happens when internal links point at a different variant, when the sitemap lists a different variant, or when the canonical tag itself is inconsistent across the set.
Google's documentation on consolidating duplicate URLs is clear that the canonical tag is one signal among several. If you want a particular URL selected, make every signal agree: the canonical tag, the internal links, the sitemap entry and any redirects should all point at the same address.
Excluded by noindex
If a page you want indexed carries a noindex directive, the cause is almost always a content
management system setting or a plugin that was configured during a rebuild and never reverted. Check
both the meta robots tag in the HTML and the X-Robots-Tag HTTP header, because the
header is invisible in the rendered page and is the reason this fault survives repeated inspection.
check both locations
curl -sI https://example.co.uk/treatments/page | grep -i x-robots-tag curl -s https://example.co.uk/treatments/page | grep -i 'name="robots"'
Blocked by robots.txt
A disallowed URL will not be fetched. If it is also linked from elsewhere it may still appear in results with no description, which looks worse than either alternative. Robots.txt is a crawl control, not an index control, and the two are confused constantly. Google's robots.txt introduction states the distinction directly.
Soft 404
The server returned 200 but the page looks empty or says nothing is here. On clinic sites this is produced by empty category archives, a search results page with no matches, and treatment pages that were emptied of content but left live. Either restore the content, return a genuine 404, or noindex the page deliberately. Leaving it in place tells the system your site contains pages that claim success while delivering nothing, which is a poor signal at scale.
Your own website
HIGH CONTROL- Every byte a crawler receives, and the speed it arrives at
- The entity claims: name, address, identifiers, sameAs, service list
- Canonical URLs, hreflang if used, and the internal link graph
- Whether the page answers the question it was built to answer
- How the answer is displayed once it leaves your server
- Whether a third party republishes an outdated version of your facts
- Crawl the whole site and compare the URL list against the sitemap
- Validate every JSON-LD block against the Rich Results Test
- Measure field data, not only lab scores, for Core Web Vitals
Alternate page with proper canonical tag
This one is not a problem. It means the system saw your canonical tag, agreed with it, and excluded the duplicate as intended. Teams frequently panic at the size of this number during a migration. If the canonical points where you meant it to, the status is a success message.
A working order of operations
- Filter the Pages report to non-indexed and sort by count. Fix the largest cause first.
- Separate the statuses that mean "we could not" from the ones that mean "we chose not to".
- Fix the mechanical ones first: server errors, robots blocks, accidental noindex, redirect chains.
- Then address duplication by consolidating rather than by adding canonical tags to thin pages.
- Then address thinness editorially, page by page, accepting that some pages should not exist.
- Re-inspect a sample after four weeks. Judge the fix on crawl status, not on rankings.
A large index is not the goal
Clinic sites do not benefit from a large index. They benefit from a small set of pages that each answer a question a patient actually asks, plus the location and treatment pages needed for local eligibility. A site with forty indexed pages that each earn impressions is a healthier asset than one with four hundred where sixty per cent are excluded. Removing pages is a legitimate and underused optimisation.