Technical SEO Checklist for Business Websites

A technical SEO checklist for a business website comes down to one question at each step: can Google find the page, crawl it, index it, and render it the way a visitor sees it? Everything else is refinement. The checklist below is ordered by what actually breaks real business sites, with the catastrophic failures first and the nice-to-haves last, so you can stop when the value runs out.

Most checklists on this topic run to 150 items and are written for SEO specialists auditing enterprise sites. If you own a 30-page service business site, you'll never work through that, and you shouldn't. Four or five things cause almost all the damage.

Tier 1: the failures that make everything else pointless

If any of these is wrong, nothing else on this page matters. Check these first, today.

• Your important pages are indexed. Search site:yourdomain.com in Google, then check the Page Indexing report in Search Console. If a page isn't listed, it cannot rank.
• No accidental noindex tags. This is the single most common catastrophic error on business sites. Staging sites are built with noindex, and it survives the launch.
• robots.txt isn't blocking anything important. Visit yourdomain.com/robots.txt and read it. A stray Disallow: / will remove you from search entirely.
• HTTPS works and HTTP redirects to it. Type the http version of your domain and confirm it lands on https.
• One version of your domain resolves. www and non-www, with and without trailing slash, should all end up in one place.
• The site loads for Googlebot. Use URL Inspection in Search Console and view the rendered HTML Google received. If your content isn't in there, Google can't read it. After fixing anything here, request a recrawl, then wait, since Google says crawling takes a few days to a few weeks and repeat requests won't speed it up.

On the noindex point, there's a trap worth understanding because it causes weeks of confusion. Google's documentation is explicit: for a noindex rule to work, the page must not be blocked in robots.txt. If it's blocked, the crawler never sees the noindex, and the page can still appear in search results when other sites link to it. People often block a page in robots.txt and add noindex, thinking they've been thorough. They've actually guaranteed the opposite of what they wanted.

The related rule: robots.txt is not a privacy tool. It manages crawler traffic. To keep a page out of Google, use noindex or password protection.

Tier 2: the problems that quietly cost you rankings

These won't take you offline. They'll just make every other bit of SEO work harder than it should.

• Every page has a unique title and meta description. Duplicates across a site usually mean a template problem.
• Canonical tags point where they should. Every page should self-canonicalise unless it's deliberately a duplicate.
• An XML sitemap exists, is submitted, and lists only indexable pages. A sitemap full of noindexed or redirected URLs sends mixed signals.
• Redirects from any old URLs are in place. This is the one that destroys traffic after a redesign.
• No redirect chains. A redirecting to B redirecting to C wastes crawl budget and loses a little signal each hop.
• Internal links reach every important page. An orphan page with no internal links is close to invisible.
• Headings follow a logical order, one H1 per page, no skipped levels.
• Images have descriptive alt text and are compressed and served in modern formats.
• 404 pages return an actual 404 status, not a 200 with a "not found" message on it.

Redesign redirects deserve their own warning. We see more rankings destroyed by a launch without a redirect map than by any other single event. If you're planning a website redesign, the redirect plan is part of the build, not an afterthought for the week of launch.

Tier 3: speed and Core Web Vitals

Speed matters, and the industry wildly overstates how much. A site that goes from awful to acceptable gains. A site that goes from good to excellent usually gains very little.

Google's three Core Web Vitals thresholds are worth knowing precisely:

Metric	What it measures	Good
Largest Contentful Paint (LCP)	Loading	Within 2.5 seconds
Interaction to Next Paint (INP)	Responsiveness	200 milliseconds or less
Cumulative Layout Shift (CLS)	Visual stability	0.1 or less

Two details most articles skip. First, Google measures at the 75th percentile of page loads, split by mobile and desktop. So three quarters of your real visitors need a good experience, not your best-case test run. Second, a page passes only when all three metrics hit their target at that percentile.

This is why your PageSpeed Insights score misleads you. That number is lab data from a simulated load. What counts is field data from real Chrome users, which appears lower down the same report and in Search Console. Chase the field numbers, ignore the score.

Practical checks:

• Run your three most important pages through PageSpeed Insights and read the field data section
• Check the Core Web Vitals report in Search Console for sitewide patterns
• Compare mobile against desktop, since mobile is almost always the weaker one
• Look at your largest images first, because they're usually the LCP problem
• Check whether your cookie banner or chat widget is causing layout shift

If mobile is bad and desktop is fine, your hosting is probably adequate and your front end is heavy. If both are bad, look at hosting first.

Tier 4: structured data and the things that help at the margins

Worth doing, not worth panicking about.

• Organization or LocalBusiness schema on the site, with real details
• Breadcrumb schema if you use breadcrumbs
• FAQ schema where you have genuine FAQs on the page
• Product or Service markup where relevant
• Validate everything with Google's Rich Results Test
• Open Graph tags so shared links look right
• hreflang tags if you serve multiple countries or languages

Structured data doesn't make you rank higher on its own. It makes your results richer and your facts easier to parse, which matters increasingly as AI systems read pages rather than just index them. For businesses serving several countries, hreflang errors are a recurring source of duplicate content problems, and they're worth getting a developer to check rather than guessing at.

How often to run this technical SEO checklist

Quarterly for a stable site. Monthly if you publish often or have a store. And always immediately after any of these events:

1. A redesign or replatform
2. A CMS, theme or plugin update that touched templates
3. A hosting or domain change
4. A sudden traffic drop
5. Adding a new language or country version

That fourth one is the real trigger. If organic traffic falls off a cliff, work down the Tier 1 list before you assume it was an algorithm update. In our experience it's usually self-inflicted: a noindex, a broken redirect, a robots.txt edit nobody documented.

What to do with what you find

Sort your findings into three buckets and treat them differently.

Fix now, yourself. Sitemap submission, meta titles, alt text, a stray noindex in your CMS settings. These are settings changes, not development.

Fix soon, with a developer. Redirect chains, render-blocking scripts, image delivery, layout shift, schema implementation.

Log and monitor. Small canonical inconsistencies, minor crawl anomalies, pages with one or two issues each. These matter at scale and rarely matter on a 40-page site.

The mistake we see most often is spending three weeks on Tier 3 and 4 items while a Tier 1 problem sits unfixed. If Google can't index your service pages, your Core Web Vitals score is irrelevant.

Your next step

Open Search Console, go to the Page Indexing report, and compare the number of indexed pages against the number of pages you believe you have. If those two numbers differ by more than a few, you have your starting point, and it's more valuable than anything further down this list.

If you'd rather have it checked for you, a free site audit with Buzzing Bee covers the Tier 1 and Tier 2 items automatically and emails you the report. Our SEO and organic growth service starts with the full audit and the fixes, and the SEO guides go deeper on individual items. For the development side, our web development team handles the fixes that need code rather than settings.

FAQs

What is technical SEO?

Technical SEO covers everything that determines whether search engines can discover, crawl, render and index your pages, along with the performance and security signals that affect how those pages are treated. It sits underneath content and links. Strong content on a site Google can't crawl properly will underperform, no matter how good the writing is.

How do I check if my site has technical SEO problems?

Start with Google Search Console, which is free and shows Google's actual view of your site. The Page Indexing report tells you which pages are indexed and why others aren't. The Core Web Vitals report shows performance issues. URL Inspection shows exactly what Googlebot received for any single page.

Does site speed affect rankings?

Yes, through Core Web Vitals, which feed Google's ranking systems. The effect is real but smaller than most articles suggest, and it's strongest when a site is genuinely slow rather than merely imperfect. Improving from poor to good is worth doing. Chasing a perfect score past that point rarely pays for the effort.

How often should I do a technical SEO audit?

Quarterly for most business websites, monthly for ecommerce or sites publishing frequently. More important than the schedule is auditing immediately after any structural change: a redesign, a platform migration, a hosting move, or a plugin update that altered templates. Those events cause most technical problems.

Can I do technical SEO myself?

Partly. Indexing checks, sitemap submission, meta tags, alt text and spotting problems are all within reach of a business owner with an afternoon and Search Console. Fixing render-blocking scripts, redirect logic, schema implementation and server performance usually needs a developer. Knowing which bucket a problem sits in is the useful skill.

Why did my traffic drop after a redesign?

Almost always missing or incorrect redirects from old URLs to new ones. When old URLs return 404s, the rankings and link equity they held are lost rather than transferred. A secondary cause is a staging-site noindex tag surviving into production. Check both before considering any other explanation.