Why Half Your Contractor Site's Pages Might Not Even Be Indexed
A pattern I keep running into when auditing contractor sites: the business has forty, fifty, sometimes eighty pages — service pages, location pages, project galleries — and Google has only bothered to index a fraction of them. Nobody notices, because the site still shows up for the owner's name and maybe one or two obvious searches. Meanwhile half the site is functionally invisible, and the reason is almost never content quality. It's crawl and indexation mechanics that nobody ever checked.
Here's how to actually find that out, and what usually causes it.
Start in Search Console, not by guessing
Pull up the Coverage report (now folded into the Pages report under Indexing). Most contractor site owners have never opened this. It'll show you, page by page, what's indexed, what's excluded, and — critically — why Google decided to exclude it.
The exclusion reasons tell you almost everything. "Crawled - currently not indexed" usually means Google visited the page and decided it wasn't worth keeping around, which is often a thin-content problem. "Discovered - currently not indexed" means Google knows the page exists but hasn't gotten around to crawling it, which is more often a crawl budget or internal linking problem. "Duplicate without user-selected canonical" means Google found near-identical pages and picked one for you, which on a contractor site usually points straight at templated location pages that are too similar to each other.
These three buckets require completely different fixes, and lumping them together as "the SEO isn't working" is how a lot of contractor sites stay stuck for years.
Crawl budget matters more than people assume for small sites
There's a persistent myth that crawl budget only matters for huge sites with millions of pages. For a fifty-page contractor site it's rarely the bottleneck on its own — but it interacts with a second problem that is common on these sites: low authority.
A brand-new or low-authority domain gets crawled less frequently and less deeply than an established one. Combine that with a site architecture where location pages are three or four clicks deep from the homepage, and some of those pages might get crawled once every few months, if that. By the time Google gets around to a page, the business might have already added new project photos or updated pricing, and none of it gets picked up for a long stretch.
The fix isn't complicated but it does require restructuring: pull important pages closer to the homepage, link to them from multiple places rather than one buried menu item, and keep the XML sitemap current so Google has an explicit list of what to prioritize rather than having to discover pages through crawling alone.
Faceted or filtered navigation quietly creates thousands of junk URLs
This one's specific to sites that let users filter service galleries — by project type, by location, by finish style, that sort of thing. Every combination of filters can generate a unique URL, and if those aren't handled carefully, a twenty-page site can accidentally expose two thousand crawlable URL variations to Google, almost all of them near-duplicates of each other.
I've seen this tank a contractor site's effective crawl budget entirely — Google spends its limited crawl allowance chasing filter combinations instead of getting to the actual service and location pages that matter. The fix is usually a combination of robots.txt disallow rules for filter parameters, canonical tags pointing filtered variations back to the base page, and in some cases just not making those filter combinations crawlable link targets in the first place.
Redirect chains pile up quietly over a few years
Contractor sites tend to get restructured periodically — a URL changes when a page gets renamed, a service gets rebranded, a site migrates to a new CMS. Each of these events, done without cleanup, tends to leave a redirect behind. Fine in isolation. The problem is when redirects start chaining: page A redirects to B, which now redirects to C, because nobody went back and updated the original link after the second change.
Every hop in a redirect chain adds crawl overhead and dilutes link equity slightly. Two or three hops usually isn't fatal. I've seen contractor sites with chains five or six redirects deep after several years of ad-hoc changes, and at that point Google sometimes just stops following the chain and treats the page as broken. Running a redirect audit — there are free tools for this, or a simple crawl comparing initial versus final URLs — and flattening every chain down to a single hop is a maintenance task that almost nobody does but that quietly recovers crawl efficiency.
Canonical tags get copy-pasted wrong more often than you'd expect
This is a specific and surprisingly common bug: a site gets built from a template, and the canonical tag on every page points to the homepage instead of to that specific page's own URL. It happens because a developer set a default canonical value site-wide and never overrode it per page.
The effect is brutal and invisible — Google is being explicitly told, on every single page, "don't index this, index the homepage instead." A site can have great content on fifty pages and still only show one URL in search results, and from the outside it just looks like the SEO isn't working, when really it's one misconfigured meta tag repeated sitewide.
Checking this takes about five minutes: view source on a handful of pages, search for rel="canonical", and confirm each one points to itself. It's worth doing on any contractor site that's underperforming for no obvious reason.
Sitemaps that lie to Google are worse than no sitemap at all
A sitemap that lists pages returning 404s, or that hasn't been regenerated since a site restructure, actively signals unreliability to Google's crawlers. If a sitemap is wrong often enough, Google starts trusting it less, which undercuts its entire purpose as a prioritization signal.
Sitemaps should be dynamically generated where possible, not hand-maintained, and they should be resubmitted through Search Console after any significant site change rather than left to be rediscovered eventually.
None of this shows up if you only look at the homepage
The thing that connects all of these issues is that they're invisible from a normal visit to the site. Everything looks fine in a browser. The homepage loads, the content reads well, the design is clean. The problems only show up in Search Console data, in a crawl tool, or in server logs — which is exactly why they tend to go unnoticed for years on concrete contractor sites that get built once and left alone.
This is usually the point where a proper technical audit earns its cost. A dedicated SEO process built around contractor sites tends to catch this category of problem specifically, because it starts from crawl and indexation data rather than assuming the site's visible content is the whole story.
What to actually check, if you're doing this yourself
Pull the Coverage report in Search Console and sort by exclusion reason before touching anything else. Check canonical tags on a sample of pages across different templates. Run a crawl and flag any redirect chain longer than one hop. If the site has filterable galleries, check whether filter URLs are being indexed as separate pages. And confirm the sitemap only lists live, 200-status URLs.
Most of this takes an afternoon. Most contractor sites have never had that afternoon spent on them.