The Seven Checks in Plain English

Every indexing problem on a contractor website tends to trace back to one of these seven areas. Some are quick to check yourself. Others need a developer. Working through all seven before assuming the worst saves a lot of back-and-forth with whoever manages your site.

Check 1: What Does Search Console Say About This Page?

Google Search Console is a free tool from Google that shows you how Google sees your website. The URL Inspection tool inside it is specifically designed to tell you what happened the last time Google crawled a particular page address. To find a page’s status, open Search Console, select your property, click URL Inspection in the left menu, and paste the exact page address you’re asking about.

The status you see reflects an earlier crawl, not a live reading. If the page shows as “Crawled, currently not indexed,” that means Google found the page, read it, and decided not to add it to the search index. The decision could relate to content similarity, canonical signals, or something else entirely. Google doesn’t always publish its reasoning.

“Discovered, currently not indexed” means something different: Google knows the URL exists but hasn’t actually visited and read the page yet. That’s a crawl priority issue, not a quality decision.

If you haven’t set up Search Console yet, that’s a gap worth closing. It’s free, it gives you data directly from Google, and it takes a few minutes to verify your site. Look up “Google Search Console setup” and follow the official instructions. Without it, you’re flying without instruments.

Check 2: What Actually Happens When Someone Loads This Page?

This one sounds obvious but gets missed more than you’d expect. Open a private or incognito browser window, paste the exact page URL, and hit Enter. If the page loads normally, that’s a good start. If you land somewhere else, see an error, or get prompted for a login, that’s important information.

A 404 (page not found) means the page doesn’t exist at that URL. Google won’t index a URL that returns 404. A redirect means the URL you checked sends traffic to a different address, so Google follows the redirect and treats that destination as the real page. A server error (5xx) means something went wrong on the hosting side.

One important note: just because you can see a page in your regular browser doesn’t confirm it’s returning a healthy 200 status code. Your browser may be showing a cached version of a page that’s actually broken or redirecting. If you suspect this, ask your web developer to check the actual HTTP response for that URL using their server tools or a browser developer console.

Check 3: Is There a Directive Blocking the Page?

There are two main ways a page gets blocked from search engines, and they work differently enough that it’s worth understanding both.

A noindex directive tells search engines not to include the page in their index. It can appear in the HTML of the page itself, in the form of a meta robots tag: <meta name="robots" content="noindex">. It can also appear as an HTTP response header called X-Robots-Tag, which you won’t see when you view the page source. Both have the same effect.

A robots.txt block is different. Robots.txt is a file at the root of your domain that tells crawlers which pages they’re allowed to visit. If a page is blocked in robots.txt, Googlebot can’t read the page’s HTML at all. That means if the page has a noindex meta tag inside the HTML, Google can’t see it, which leads to a specific situation: the page can still appear in Google’s index without much information, because Google knows the URL exists from external links but never read the page’s own content or instructions.

To check for noindex, view the page source (right-click, View Page Source), then search for “noindex.” To check robots.txt, visit yourdomain.com/robots.txt and look for Disallow rules covering your page’s path. And remember: viewing the page HTML does not rule out an X-Robots-Tag header. If you’re not sure, ask your developer to verify both.

Check 4: What Does the Canonical Tag Point To?

A canonical tag is a signal that tells search engines which URL is the preferred, main version of a piece of content. If your Austin plumbing page has a canonical tag pointing to your Dallas plumbing page, Google reads that as: “This Austin page is a copy of the Dallas page. Use the Dallas page.” The Austin page may not get indexed independently as a result.

To find the canonical tag, view the page source and search for rel="canonical". The href value in that tag is where the canonical points. If it matches the current page’s URL, it’s pointing to itself, which is standard. If it points to a completely different URL, you need to know whether that’s intentional.

A missing canonical tag on its own is not a confirmed problem. Plenty of pages without canonical tags get indexed without issue. A canonical pointing unexpectedly to a different page is the situation worth investigating. Also worth knowing: canonical tags are preferences, not rules. Google weighs them against other signals and can override them if the canonical choice doesn’t match what other evidence suggests.

Check 5: Can Google Actually Find This Page From Within Your Site?

Before Google can crawl a page, it usually needs to discover it first. Discovery most commonly happens through links: another page on your site links to this one, Google follows that link, and finds the page. If no page on your site links to a particular service area page, Google has to rely on your sitemap or external links to find it.

Look at your navigation, your main service pages, and any hub pages you have for coverage areas. Is there a link to this specific page from a relevant place? A link from your “Roofing Services” page to your “Roofing in Dallas” page is natural and helpful. A footer crammed with 40 city links is harder for Google to treat as meaningful.

One or two well-placed links from contextually related pages is enough to establish a clear path. This isn’t about link quantity. It’s about whether Google can follow a logical trail from your home page or main service pages to the specific city page in question.

Check 6: Is This Page in Your Sitemap?

A sitemap is a file that lists your pages and tells Google they exist. It’s primarily a discovery aid. If a page is in your sitemap, Google is more likely to notice it sooner. If it’s not, Google can still find and index it through internal links or external references.

For most contractor websites with a few hundred pages or fewer, a sitemap is helpful but not essential. Missing from the sitemap is a low-priority concern compared to a noindex directive, a robots block, an inaccessible page, or an unexpected canonical. Start with those before worrying about the sitemap.

If you use an SEO plugin on WordPress, it usually generates your sitemap automatically. Check the plugin settings to see what’s being included and excluded. SEO plugins also have settings that can accidentally exclude specific post types or page templates from the sitemap.

Check 7: Does This Page Have Anything Genuinely Useful to Offer?

This is the check that doesn’t have a technical fix, and it’s often the one that explains why pages pass all the other checks but still don’t get indexed.

Google has stated publicly that thin content, particularly pages where the only difference from one to another is a swapped city name, can affect both individual page indexing and how the whole site’s content is perceived. If you have 30 city pages that are word-for-word identical except for “Austin” being replaced with “San Antonio,” Google may only index some of them and treat the rest as near-duplicates.

What makes a service area page genuinely useful? Real information that applies to that location. Work you’ve actually done there. Specific areas, neighborhoods, or nearby towns you cover. Types of construction or architecture common in that area that affect your process. Customer questions that come up specifically in that market. Service availability details like whether you regularly travel there or are actively looking for jobs in that area.

This does not mean writing 2,000 words per city page. A short, honest paragraph with specific local detail is better than a long page of manufactured local content. And never recommend inventing reviews, addresses, or job histories that don’t exist. Real is better than padded, always.

How to Use Google’s URL Inspection Tool

The URL Inspection tool is one of the most useful free tools available to anyone managing a contractor website, and it’s underused because most business owners don’t know it exists. Here’s how to use it without getting lost in the interface.

First, you need to have Search Console set up for your domain. If you don’t, start there. Go to search.google.com/search-console and follow the setup instructions. You’ll need to verify that you own the domain, which usually means adding a small file or DNS record. Your web developer can handle this if you’re not comfortable doing it yourself.

Once you’re in Search Console with your site verified, look for “URL Inspection” in the left sidebar. Click it, then paste the full URL of the page you’re asking about into the search bar at the top of the screen and press Enter. Google will show you what it knows about that specific URL.

The result includes the URL’s indexing status, the last time Google crawled it, what Google selected as the canonical URL, and whether the page was able to be fetched. If the page has issues, the report lists them. You’ll see categories like “Page indexing,” “Availability,” and “Enhancements.” The Page indexing section is where the indexing status and reasons live.

The tool also has a “Test Live URL” option. This runs a fresh crawl test against the current live version of the page, rather than showing you cached data from the last crawl. This is useful when you’ve made a recent change and want to see if the current version would be indexable. Keep in mind that testing the live URL and requesting indexing are different things. Testing does not guarantee or trigger a full recrawl.

One thing to watch: the status in Search Console reflects a specific crawl date. If you’ve made changes to the page since that last crawl, the Search Console result may not reflect the current state of the page. That’s why the comparison between Search Console data and your current manual checks matters. If they conflict, the date of the Search Console crawl is a key piece of information.

Official documentation for the URL Inspection tool is available at support.google.com/webmasters/answer/9012289. If something in the interface doesn’t make sense, that’s the right place to start for clarification.

What Those Search Console Status Labels Actually Mean

Acting on a misread status wastes time, so here’s what each one actually says:

URL is on Google: Indexed and eligible for search results. Being indexed doesn’t mean it ranks. Traffic issues on an indexed page are a ranking question, not an indexing problem.

Crawled, currently not indexed: Google visited and read the page, then decided not to add it to the index. Common contributing factors include content too similar to other pages, thin content, and unexpected canonical signals. The status alone doesn’t tell you which applies.

Discovered, currently not indexed: Google knows the URL exists but hasn’t crawled it yet. A queue and scheduling issue, not a content issue. Better internal linking and a sitemap entry help. On a typical contractor-sized site, this usually resolves without intervention within a few weeks.

Blocked by noindex: Google is following a noindex directive. Confirm whether this is intentional before changing anything.

Blocked by robots.txt: Googlebot can’t access the page at all. Because the HTML is unreadable, any noindex tag inside the page is also unreadable, which can create odd situations where the page appears in the index without much detail.

Alternate page with proper canonical / Google selected different canonical / Duplicate: Google is treating this URL as a variation of another page. Check which URL Google selected as the canonical and whether that matches your intentions.

Not found (404) / Server error (5xx): The page isn’t accessible. Both prevent indexing. The fix is making the page load correctly at its intended URL.

Three Different Problems: Indexing, Rankings, and Google Maps

These three often get confused, but they require completely different approaches.

Indexing is whether Google has your page in its database at all. No index entry, no search appearance. This checklist addresses the indexing side.

Rankings are where an indexed page appears in results for specific searches. A page can be indexed and still not appear on the first ten pages for any relevant query. That’s a ranking problem, driven by content quality, local authority, and relevance signals.

Google Maps and Google Business Profile are a separate system. Your map listing is managed through Google Business Profile, not your website. Address problems, suspended listings, and missing information are fixed inside Google Business Profile. A website audit doesn’t affect your Business Profile, and fixing your Business Profile doesn’t affect your site’s indexing. If a customer says they can’t find you on Google, clarify which Google they mean before you start looking.

WordPress Checks: What You Can See and What Needs a Developer

WordPress has a few specific places where indexing settings can get accidentally switched on during development and never turned off.

The privacy setting: Go to Settings, then Reading. Look for “Discourage search engines from indexing this site.” If that box is checked, WordPress adds a site-wide noindex. Uncheck it and save if the site is live.

SEO plugin settings: Yoast, All in One SEO, Rank Math, and similar plugins have their own noindex controls at both the page level and the post-type level. Check the individual page settings in the editor and check whether the plugin is set to noindex city pages or whatever custom post type your service area pages use.

Response headers: The X-Robots-Tag header enforces noindex at the server level, which means it’s invisible when you view page source. If your manual checks don’t explain what Search Console is reporting, ask your developer to check the response headers using browser developer tools. Sites using caching plugins or a CDN sometimes have header issues that aren’t obvious from the page HTML.

Cache: Clear the site cache after any indexing-related change. Caching plugins serve older versions of pages. An old noindex may still appear in the source until the cache is purged.

What Makes a Service-Area Page Worth Indexing?

This is worth reading even if all your technical checks come back clean. The most common situation for contractor websites is that the technical side is fine, but the page content is so similar to other city pages that Google treats the whole batch as near-duplicates and skips most of them.

The standard template approach (copy the Austin page, replace “Austin” with “San Antonio,” publish) creates pages that look different to a human but look nearly identical to a search engine comparing the text. Google has said directly that thin, low-quality content may not be indexed, and having many similar pages can affect how the whole site is perceived.

What actually distinguishes a city page: real work performed in that area (briefly and honestly stated), the specific neighborhoods and towns covered, and any local specifics that affect the work, such as common materials, climate conditions, HOA situations, or construction patterns. None of this needs to be fabricated. Real local detail, even brief, is more useful than a longer page full of generic service claims with a city name swapped in.

If you have city pages with no genuine local detail, you have a few honest options: consolidate weaker pages into a broader coverage area page, leave them and accept that not all will index, or prioritize the cities where you most want business and improve those pages first.

For help planning city page content, the Free Local SEO Content Planner walks through how to approach this without spending weeks on it.

Internal Linking, Canonical Tags, and Sitemaps

These three topics get treated as separate issues, but they’re all really part of the same question: how does Google navigate your site and understand which pages matter?

Internal Linking

Internal links are the paths Google follows from one page to another within your site. A new service area page that nothing links to is an orphan. Google may discover it through your sitemap, but without links from related pages, it has weaker context signals and may be crawled less frequently.

The natural place to link to a city page is from your main service pages. If you have a central “Roofing Services” page, it should logically link to your city-specific roofing pages. If you have a “Service Areas” overview page that lists the locations you cover, each location should link to its specific page. These aren’t just crawlability signals; they’re also useful for visitors trying to confirm you serve their area.

What doesn’t help: dropping 60 city links in the footer of every page. This creates a situation where hundreds of pages on your site are all linking to all the city pages with identical anchor text, which doesn’t give Google much useful signal about the relationship between the pages. Contextual links from relevant pages are more meaningful than a footer full of geographic links.

Canonical Tags

The canonical tag situation is simpler than it gets made out to be most of the time. For service area pages, the main thing to verify is that the canonical is either a self-reference (pointing to the same URL) or absent, rather than pointing to a different city page. If every city page canonicals back to your main service page, you’ve told Google that none of the individual city pages are independent content, and none of them will be indexed independently.

Most SEO plugins handle canonical tags automatically, defaulting to a self-canonical on each page. The most common accidental problem is a canonical getting set to the wrong page during a batch copy-and-paste when building out multiple city pages. It’s worth spot-checking a few city pages if you built them by duplicating existing pages.

According to Google’s consolidation guidance, canonical signals can be indicated through tags, HTTP headers, sitemaps, or redirects, with redirects being the strongest signal. For service area pages you intend to index independently, self-canonicals or no canonical tag are the right approach.

Sitemaps

A sitemap is a signal to Google about which pages exist and which you consider important. It’s useful for discovery, especially for newer pages or pages with few internal links. Per Google’s sitemap documentation, sitemaps are most beneficial for larger sites, new sites without external links, and sites with rich media content. For most contractor sites, a sitemap is a helpful but not critical piece of the puzzle.

If you’re using an SEO plugin, check that your service area pages (or the custom post type they use) aren’t accidentally excluded from the sitemap. Some plugins exclude specific post types by default, and if your city pages were built with a page builder template or custom post type, they may not be included in the sitemap automatically.

Including a page in the sitemap does not guarantee it will be indexed. Sitemaps are a suggestion, not a command. Google can and does ignore pages listed in sitemaps if it determines they don’t meet indexing criteria. Think of the sitemap as making sure Google knows about your pages, not as forcing Google to include them.

Using SE Ranking’s Website Audit to Check Multiple Pages

For a single problem page, the free tools (Search Console, view-page-source, robots.txt check) are usually enough to identify the issue. When several service area pages aren’t indexing, manual page-by-page checks get tedious and make it easy to miss patterns.

SE Ranking’s website audit crawls your site the way a search engine does: follows links, reads HTML, checks response codes, finds noindex tags, identifies canonical issues, and flags missing internal links, all at once across every page it finds. The report is organized by issue type and severity, so you can see quickly if the same technical problem is hitting a batch of city pages.

To run an audit: create a project for your domain, select the website audit tool, run the crawl (defaults work for most contractor sites), then filter the issues report by category. Look specifically for noindex, robots.txt blocks, redirect chains, duplicate content, and canonical issues. The report lists the affected URLs for each issue type, which is what makes it faster than checking pages one at a time.

The audit identifies technical states that are known to affect indexing. It doesn’t explain why Google made a specific indexing decision, and you still need to evaluate whether each flagged item is a real problem or an intentional setting. SE Ranking’s documentation at help.seranking.com has current instructions for each tool feature.

After a Fix: What to Actually Verify

Making a change to a page’s settings or content is step one. Confirming the change worked is step two, and it often gets skipped.

After removing a noindex directive: check the page source to confirm the tag is gone. If you’re on WordPress, clear the site cache after saving the change, then reload the page and check the source again. A cached version of the page may still have the old directive until the cache is cleared.

After fixing a canonical: reload the page source and verify the canonical tag now points where you intended. If you made the change through an SEO plugin, confirm the plugin saved the setting for that specific page rather than applying a global override.

After fixing a 404 or restoring a page: open the URL in an incognito window and confirm the page loads. Then use Search Console’s URL Inspection tool to run a live test and confirm the page is accessible.

After any fix, you can use the “Request Indexing” option in Search Console’s URL Inspection tool to signal that you’d like Google to recrawl the page. This puts the URL in a priority queue but does not guarantee immediate indexing. It typically takes a few days to a few weeks for a page to move through the crawl queue and for the new status to appear in Search Console.

Note that this doesn’t mean submitting repeatedly. A single request after a confirmed fix is reasonable. Repeated submissions for the same page don’t accelerate the process.

Already Getting Traffic but Not Enough Leads?

Indexing is the first step. Once pages are in Google, the next question is whether the people who land on them actually contact you. A well-indexed service page that doesn’t have a clear call to action, a prominent phone number, or an easy way to request a quote is leaving potential jobs on the table.

If you’re getting visitors but not enough calls or form submissions, that’s a conversion problem rather than an SEO one. The Contractor Lead Page Kit is a $397 one-time WordPress installation that adds a mobile-first lead page designed specifically to turn website visitors into quote requests. It includes a call-to-action layout, an estimate request form, a service area section, and basic color matching to your brand. That’s outside the scope of this indexing guide, but it’s the natural next step once the indexing side is sorted.

For other free resources related to contractor websites and local marketing, the Free Contractor Tools page has a collection of tools worth browsing when you have a few minutes.