A technical SEO audit checklist for service business websites

A technical SEO audit checklist for service business websites: crawling, indexation, redirects, canonicals, sitemaps, schema and Core Web Vitals.

Published

Sep 29, 2026

Reading time

10 min read

A technical SEO audit is not every warning a tool can produce. It answers one question: can Google find, crawl and index the pages that bring in calls and leads? This is the checklist I have used since 2018, in order, with links to Google’s own docs.

1. Crawl the site

Start with a full crawl in a desktop crawler such as Screaming Frog. It meets the site the way a search engine’s crawler does: by following links from page to page.

That matters because, according to Google’s link best practices, Google uses links to find new pages to crawl, and it can generally only crawl a link that is an <a> element with an href attribute. A service page that can only be reached through a form, a script-driven button or a site search may never be found.

• Broken internal links. Google doesn’t index URLs that return a 4xx status code, and URLs that are already indexed and start returning one are removed from the index (HTTP status codes and Google’s crawlers). A broken link to a service page is a dead end for visitors too.
• Broken external links. Directory listings, associations and review sites move their pages. Update or remove the links.
• Redirect chains. By default, Google’s crawlers follow up to 10 redirect hops (same page: HTTP status codes and Google’s crawlers). Chains build up after every redesign. Point internal links straight at the final URL and keep each redirect to one hop where you can.
• Redirect types. With a permanent redirect (301 or 308), Google uses the redirect as a signal that the target should be canonical. With a temporary redirect, it doesn’t (Redirects and Google Search). Service pages that have moved for good should use permanent redirects.
• Orphaned pages. Google’s advice is that every page you care about should have a link from at least one other page on your site (link best practices). A crawler only finds linked pages, so compare the crawl with your XML sitemap and with Search Console. A URL that appears there but not in the crawl has no internal links.
• Soft 404s. A page that returns a 200 status but shows an error or an empty page is reported in Search Console as a soft 404 (HTTP status codes). Removed services should return a real 404 or redirect to the closest replacement.
• Server errors. 5xx and 429 errors make Google’s crawlers temporarily slow down (same page: HTTP status codes and Google’s crawlers). If the crawl shows them, talk to the host before anything else.

2. Check what Google has indexed

A crawl shows what the site offers. Search Console shows what Google did with it. You need both.

• Page indexing report. It shows how many URLs Google has indexed and the reasons others weren’t (Page indexing report). Don’t chase 100%: Google says not to expect every URL on a site to be indexed, only the canonical pages. Look at the reasons that affect service and location pages first.
• Canonicals. Google describes a rel="canonical" link as a strong signal, not a command, and a redirect as a strong signal too (How to specify a canonical URL). For each important page, open the URL Inspection tool and compare the user-declared canonical with the Google-selected canonical. If they differ, look for near-duplicate pages, internal links that point at another version, or mixed signals.
• Mixed canonical signals. Google asks you not to name different canonical URLs for the same page with different techniques, for example one URL in the sitemap and another in the rel="canonical" tag. It also says not to use robots.txt for canonicalization (same page: How to specify a canonical URL).
• Duplicate titles. Google asks that every page has a title in the <title> element and warns against repeated or boilerplate title text, including titles that vary by only a single piece of information (Influencing your title links). On service sites the usual cause is a location template where only the city name changes.
• Duplicate meta descriptions. Identical or similar descriptions on every page aren’t helpful when individual pages appear in search results (Control your snippets). Write one for each service and location page.
• Thin and near-duplicate pages. Google’s automated ranking systems are designed to prioritize helpful, reliable information created to benefit people (Creating helpful content). Its spam policies list “pages targeted at specific regions or cities that funnel users to one page” as an example of doorway abuse. If a location page would read the same with another city’s name, give it real local substance or merge it into a stronger page.

3. Review the XML sitemap and robots.txt

These two files are small, so they get skipped. They are also where a single wrong line can hide a whole section of the site.

• The sitemap lists the pages you want in search. Google’s advice is to include the URLs you want to see in its search results, as fully-qualified, absolute URLs (Build and submit a sitemap). In practice: canonical, indexable pages only, not redirects, 404s or noindex pages.
• Size. A single sitemap is limited to 50MB uncompressed or 50,000 URLs (same page: Build and submit a sitemap). Most service sites are far below that; larger sites split their sitemaps.
• Dates. Google uses <lastmod> only if it is consistently and verifiably accurate, and it ignores <priority> and <changefreq> (same page: Build and submit a sitemap). Set <lastmod> to the date the page content changed, not the date the file was generated.
• Submission. Submit the sitemap in the Search Console Sitemaps report, or add a Sitemap: line to robots.txt. Google calls submitting a sitemap “merely a hint”, so it is not a promise that the URLs will be crawled (same page: Build and submit a sitemap).
• robots.txt does not remove pages. It tells crawlers which URLs they can access, mainly to avoid overloading a site. It is not a mechanism for keeping a page out of Google, and a disallowed URL can still be indexed if other sites link to it (Introduction to robots.txt).
• noindex needs to be crawlable. For noindex to work, the page must not be blocked by robots.txt. Otherwise the crawler never sees the rule (Block indexing with noindex). Thank-you pages and staging copies are the usual candidates.

A simple robots.txt for a small service site often looks like this:

User-agent: *
Allow: /
 
Sitemap: https://www.example.com/sitemap.xml

4. Look at site architecture and internal links

On a service business site, the service pages and the location pages carry the leads. The architecture question is simple: can a visitor, and a crawler, reach each of them in a few clicks from the home page, through links that say what the page is about?

• Every service has its own page, linked from the main navigation or a services page.
• Every location page is linked from a locations page and links to the services offered there.
• Anchor text describes the target. Google calls good anchor text “descriptive, reasonably concise, and relevant to the page that it’s on and to the page it links to”, and gives “Click here” as an example of text that is too generic (link best practices).
• Related pages link to each other. A service page should link to the proof behind it, its locations and the questions people ask about it.
• Mobile parity. Google uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking. It asks that the mobile site has the same content, the same structured data, and equivalent titles and meta descriptions as the desktop site (Mobile-first indexing best practices). Check that the mobile menu and layout don’t drop links or content.

5. Check structured data for the business, services and locations

Structured data is a standardized format for providing information about a page, and Google uses it to understand the content of the page. Google recommends JSON-LD where the site’s setup allows it (Introduction to structured data).

• The business. Google’s local business documentation asks you to use the most specific LocalBusiness subtype possible. For service businesses that could be Dentist, Attorney or RoofingContractor.
• Each location. Google says to define each business location as a LocalBusiness type. name and address are required; recommended properties include telephone, url (the URL of that specific location), geo and openingHoursSpecification (local business documentation). The natural home for each location’s markup is its own location page.
• Markup matches the page. Structured data must be a true representation of the page content, and you shouldn’t mark up content that is not visible to readers (General structured data guidelines). If the page doesn’t show opening hours, the markup shouldn’t claim them.
• Review stars. In the LocalBusiness documentation, aggregateRating is recommended only for sites that capture reviews about other local businesses. Adding star-rating markup for your own business’s reviews falls outside that recommendation.
• Services. Describe services in the markup only as far as the page itself describes them.
• Test and monitor. Google suggests checking markup with the Rich Results Test during development and the rich result status reports after launch (Introduction to structured data). Valid markup makes a page eligible for search features; it does not mean they will appear (General structured data guidelines).

6. Measure Core Web Vitals

Core Web Vitals measure loading, responsiveness and visual stability. These are Google’s targets for a good experience (Understanding Core Web Vitals):

• Start with field data. The Search Console Core Web Vitals report is based on real-world usage data, groups pages that have a similar user experience, and reports mobile and desktop separately.
• Low-traffic pages. URL groups without enough data don’t appear in that report. Test those templates directly with PageSpeed Insights or Lighthouse, which the same help page points to for live tests.
• Test the templates that carry leads: home, service, location and contact pages.
• Keep it in proportion. Google says that Core Web Vitals are used by its ranking systems, and also that “Google Search always seeks to show the most relevant content, even if the page experience is sub-par” (Understanding page experience). Fix what slows real visitors down first. Don’t trade useful content for a perfect score.

7. Check hreflang, if the site has language versions

Skip this section if the site is in one language. If it has, for example, English and Spanish versions of its service pages, hreflang tells Google which is which (Tell Google about localized versions of your page).

• Each version lists itself and all the other versions (same page: Tell Google about localized versions of your page).
• Links are reciprocal. If two pages don’t both point to each other, Google ignores the tags (same page: Tell Google about localized versions of your page).
• A fallback is set with x-default, if there is a page for visitors whose language isn’t listed.
• One method is used consistently: HTML link tags, HTTP headers or the sitemap. Google treats the three as equivalent (same page: Tell Google about localized versions of your page).

8. Turn the findings into a 90-day plan

An audit only helps if it changes what the team does next. I sort findings by business impact first, then by effort, and group them into three stages.

Then write the handoff so developers can act on it without a meeting. Each ticket gets:

• The problem in one sentence, and why it matters to the business.
• Example URLs, with the full list attached as an export.
• What “fixed” looks like, stated as the expected behavior.
• How to check it: for example, a live test in the URL Inspection tool, which Google describes as a way to check a URL for indexing issues, structured data and more.
• A priority and an owner.

After each release, re-crawl, watch the Page indexing report, and report what changed in plain English. If you request indexing for a fixed page, Google notes that indexing can take up to a week or two (URL Inspection tool).

The checklist on one page

• Crawl: broken links, redirect chains and types, orphaned pages, soft 404s, server errors
• Indexing: Page indexing report, user-declared vs Google-selected canonicals, duplicate titles and descriptions, thin location pages
• Sitemap: canonical URLs only, accurate <lastmod>, submitted in Search Console
• robots.txt: nothing important blocked, no noindex pages blocked
• Architecture: every service and location page linked, descriptive anchor text, mobile parity
• Structured data: specific LocalBusiness type, one per location, matches the visible page, tested
• Core Web Vitals: field data first, lead templates tested
• hreflang: self-referencing, reciprocal, one method
• Plan: three stages over 90 days, tickets with URLs, expected behavior and a way to verify

Want this run on your site?

If you would rather have the audit done for you, or you already have an audit and need it turned into a plan your team can act on, see how I run technical SEO audits.