Technical SEO Checklist for Service Websites

Technical SEO for a service website comes down to four questions: can Google reach your pages, can it render them, can it index the right version of each one, and does the page load well enough that the visitor stays.

This checklist works through all four in that order, with the configuration details that break most often on WordPress and similar builds.

It assumes a site of roughly 20 to 200 pages, run by a business rather than an engineering team.

How Google Actually Processes a Page

Nearly every technical SEO problem is easier to diagnose once you know the sequence. Google’s JavaScript SEO documentation describes three distinct phases:

1. Crawling. Googlebot fetches the URL, checks robots.txt first, and extracts links from the raw HTML.
2. Rendering. “All pages with a 200 HTTP status code are sent to the rendering queue, no matter whether JavaScript is present on the page.” The page waits for resources, then executes.
3. Indexing. Google processes the rendered HTML, and extracts links again.

Three consequences follow, and they explain most of this checklist. Anything blocked at the crawl stage never reaches rendering. Anything that only exists after JavaScript runs depends on the rendering queue. And “Google can only see content that’s visible in the rendered HTML”, so the test that matters is what the rendered output contains, not what your source file says.

Crawlability: Getting Googlebot to the Right Pages

Understand what robots.txt is for. It controls crawler access, not indexing. Google states plainly that robots.txt “is not a mechanism for keeping a web page out of Google”, and that “a page that’s disallowed in robots.txt can still be indexed if linked to from other sites”. Such a URL can appear in results without a description. To keep a page out of search, use noindex, password protection, or remove it.

Do not block CSS and JavaScript. Rendering needs them. Blocking /wp-includes/ or a theme assets directory is a habit left over from a decade ago and can leave Google rendering a broken page.

Keep the XML sitemap clean. It should list only canonical, indexable URLs that return 200. Redirected, blocked, noindex or 404 URLs in a sitemap send mixed signals. Most SEO plugins get this right by default and then drift after a redesign.

Treat internal links as the real crawl path. A sitemap helps discovery, but Google follows links. Any page reachable only from a sitemap is weakly supported at best.

Close the crawl traps. Filter parameters, sort orders, session IDs, print views and infinite calendars generate unlimited URLs. Google’s crawl budget guidance notes that long redirect chains “have a negative effect on crawling”, and that soft 404s “continue to be crawled, and waste your budget”.

Indexability: Making Sure the Right Version Ranks

Never combine noindex with a robots.txt block. It is the most common self-inflicted indexing bug. If the URL is blocked from crawling, Google cannot fetch the page to see the noindex tag, so the tag never takes effect. Allow crawling, serve noindex, and only add a robots.txt rule later if you want to save crawl budget once the page has dropped out.

Resolve every URL to one canonical version. Test http and https, www and non-www, trailing slash and none, uppercase and lowercase, and common parameter combinations. Google’s canonicalization guidance treats redirects as the strongest signal, rel="canonical" as a strong one and sitemap inclusion as weak, and Google makes the final choice itself.

Use the right redirect method. Google’s redirect documentation ranks server-side redirects as the most reliable, meta refresh second, and JavaScript redirects “as a last resort”. A permanent server-side redirect signals that the target should be canonical; a temporary one does not.

Keep redirects far longer than feels necessary. After a URL change, Google advises keeping redirects “for as long as possible, generally at least 1 year”, which is the time it needs to transfer signals to the new URLs. Deleting redirects six weeks after a migration is a familiar way to lose rankings twice.

Return honest status codes. Google treats 410 identically to 404, so use whichever is easier; what matters is that a missing page returns an error rather than a 200 with “sorry, not found” in the body. That pattern produces the soft 404 report in Search Console. Persistent 500 errors cause Google to reduce crawl rate and eventually drop URLs.

Rendering: The JavaScript Problems That Hide Your Content

Service sites built on page builders, headless setups or heavily scripted themes hit the same handful of issues.

Links must be real links. “Google can only discover your links if they are <a> HTML elements with an href attribute.” A <div> with a click handler, a button that calls a router, or a fragment-based route is not a link. Google recommends the History API for routing rather than URL fragments.

Put titles and meta descriptions in the static HTML where you can. JavaScript can set them, but static HTML is more reliable.

Check lazy loading actually loads. Content that only appears after a scroll event or a user interaction may never be rendered. Images and text below the fold need to be present in the rendered output.

Handle missing pages in single-page apps. A route with no content should redirect to a real 404 or inject a noindex tag, otherwise Google records a soft 404.

Verify with the tools, not by eye. The URL Inspection tool in Search Console and the Rich Results Test both show the rendered HTML that Google actually sees. Compare that against your page. This one habit finds more real problems than any crawler report.

Confirm mobile parity. Since 5 July 2024 Google crawls and indexes with Googlebot Smartphone only. Content trimmed, tabbed away or hidden on mobile is content Google may not use.

Speed and Stability: The Three Numbers That Matter

Core Web Vitals measure loading, interactivity and visual stability, assessed at the 75th percentile of page loads:

• Largest Contentful Paint: 2.5 seconds or less.
• Interaction to Next Paint: 200 milliseconds or less. It replaced First Input Delay as a stable metric in 2024.
• Cumulative Layout Shift: 0.1 or less.

Use the field data in PageSpeed Insights, which comes from real Chrome users, rather than the lab score. Lab scores fluctuate and tempt you into optimising the wrong thing.

On service websites the causes are predictable: an oversized hero image, render-blocking scripts from chat widgets and tracking tags, web fonts loading late, images without width and height attributes, and cookie or promo banners injected after paint. Fixing the hero image and the largest render-blocking script usually moves the number more than anything else.

The fastest way to make progress is to stop guessing which element is slow. PageSpeed Insights names the LCP element for the URL you test, and it is almost always one of three things on a service site: the hero image, a background image set in CSS, or a heading blocked by a late-loading web font.

Once you know which, the fix is usually mechanical. Serve the hero as a correctly sized modern format, preload it rather than lazy-loading it, and never lazy-load anything above the fold.

Give every image explicit width and height attributes so the layout stops shifting. Defer chat widgets, heatmaps and secondary tracking until after the page has painted, since these are frequently the largest render-blocking scripts on an otherwise simple site.

Google is clear that page experience has “no single signal”, and lists serving over HTTPS, displaying content well on mobile, and avoiding intrusive interstitials alongside Core Web Vitals. Relevance still comes first: Google says it “always seeks to show the most relevant content, even if the page experience is sub-par.”

What to Fix First

Work in the order the systems run, because a fix downstream is wasted while something upstream is broken:

1. Crawl blocks. A robots.txt rule or a stray noindex on a revenue page outranks every other item here.
2. Duplicate and canonical problems. These split signals across the whole site.
3. Rendering failures. Content Google cannot see cannot rank.
4. Redirect and status code errors. Cheap to fix, and they compound after every migration.
5. Core Web Vitals. Real, but rarely the reason a service site is invisible.

Recheck items 1 and 4 after every redesign, plugin update and CMS migration, because that is when they break. The rest holds steady for months at a time.

This checklist covers the technical layer only. For the wider view, including service page content, local signals and the enquiry path, run a full site audit alongside it.

If you want this done properly on your site, see how the technical SEO service works at UmarRanks, or, if you are mid-migration, the audits and migrations page. Already know what is broken? Send me the details.

Frequently Asked Questions