Technical SEO Checklist for Small Business Websites

Technical SEO makes sure Google can find, crawl, understand and index your pages, and that visitors get a page that loads properly on their phone. For most small business sites this is a short list: check that nothing is blocked by mistake, that each page has one clear URL, that the site is secure and mobile-friendly, and that Search Console isn't reporting errors. This checklist covers each item, what Google's documentation says about it and how to check it yourself.

Before you start: a myth worth dropping

Many audit reports warn about "crawl budget". For a typical business website, it isn't something to worry about. Google's crawl budget guide is written for large sites (roughly a million or more unique pages changing weekly) and medium sites (around 10,000 or more pages changing daily). Google calls these rough estimates, not exact thresholds, and says that if your new pages tend to be crawled the same day they're published, you don't need the guide. For everyone else, Google says keeping your sitemap up to date and checking the Page Indexing report regularly is enough.

So if your 40-page site is being sold a "crawl budget optimisation" package, ask what problem it actually solves.

1. Crawling and indexing

Google's technical requirements are short: Googlebot isn't blocked, the page works (returns an HTTP 200 status) and the page has indexable content. Google also notes that meeting them doesn't guarantee indexing. Most technical problems come down to breaking one of these by accident.

robots.txt

Open yourdomain.com/robots.txt and check that it doesn't block important pages or the whole site. A leftover Disallow: / from a staging site is a common mistake after launch.
Know what robots.txt is for. Google says it tells crawlers which URLs they can access and is mainly for managing crawler load. It is "not a mechanism for keeping a web page out of Google". A blocked URL can still appear in results, just without a description.

noindex

Use a noindex rule for pages that shouldn't appear in search, such as thank-you pages or internal search results. Google says it drops such pages from results entirely.
Don't combine it with a robots.txt block. Google's documentation explains that if robots.txt blocks the page, the crawler never sees the noindex rule, so the page can still show up.
Check that important pages don't carry noindex by mistake. WordPress's "Discourage search engines" setting and some SEO plugins can add it site-wide.

Canonical URLs

Each page should have one preferred URL. Variations like http:// vs https://, www vs non-www, or tracking parameters can create duplicates.
Google lists redirects and rel="canonical" as strong signals for the preferred URL, and sitemap inclusion as a weak one. It may still choose a different canonical if signals conflict.
Google advises against using robots.txt or noindex for canonicalisation within a site. Use rel="canonical" or redirects.

XML sitemap

Google says you might not need a sitemap if your site is small (about 500 pages or fewer) and well linked internally. It's still cheap to have one, and most CMSs generate it automatically.
Include only pages you want indexed: no redirects, no noindex pages, no 404s.
Submit it in Search Console. Google notes that a sitemap doesn't guarantee everything in it will be crawled and indexed.

2. HTTPS

Every page should load over HTTPS with a valid certificate. Google's page experience guidance asks whether pages are served securely, and its canonicalisation guide says Google prefers HTTPS pages over equivalent HTTP ones.
Redirect all HTTP URLs to their HTTPS versions permanently.
Check for "mixed content", where an HTTPS page loads images or scripts over HTTP.

3. Mobile

Google uses the mobile version of a site's content for indexing and ranking. Make sure the mobile version has the same content as desktop. Hidden sections, missing service details or stripped-down mobile menus can cost you.
Google recommends responsive design as the easiest pattern to implement and maintain.
Don't lazy-load primary content only after a user interaction, and don't block CSS, JavaScript or images Google needs to render the page.
Avoid intrusive pop-ups that cover the content on phones. Google's page experience self-assessment asks about intrusive interstitials.

4. Core Web Vitals

Core Web Vitals measure loading, responsiveness and visual stability for real visitors. The thresholds from web.dev:

Metric	What it measures	"Good" threshold
LCP (Largest Contentful Paint)	How quickly the main content appears	2.5 seconds or less
INP (Interaction to Next Paint)	How quickly the page responds to taps and clicks	200 milliseconds or less
CLS (Cumulative Layout Shift)	How much the layout jumps while loading	0.1 or less

web.dev says to measure at the 75th percentile of page loads, separately for mobile and desktop.
Use field data (Search Console's Core Web Vitals report, PageSpeed Insights) for the real picture. Lighthouse is a lab tool and doesn't measure INP directly; it uses Total Blocking Time as a proxy.
Keep it in proportion. Google says there's no single page experience signal, that good Core Web Vitals don't guarantee top rankings, and that it will show the most relevant content even if page experience is sub-par. Fix real slowness, but don't neglect content for a perfect score.

If your site runs on WordPress, our guide to passing Core Web Vitals on WordPress covers the usual culprits.

5. Structured data

Structured data describes your page in a standard format. Google generally recommends JSON-LD.
For a local business, LocalBusiness (or a more specific type) with your name, address and phone is a sensible start. Add types like Product or Article only where they fit the page.
Only mark up what visitors can see. Google advises against adding structured data about information that isn't visible to the user.
Validate with Google's Rich Results Test. Structured data can make pages eligible for richer results; it doesn't promise them.

6. Broken links and redirects

Find internal links pointing to pages that no longer exist and update them.
When you move or rename a page, use a permanent server-side redirect (301 or 308). Google treats permanent redirects as a signal that the new URL should be canonical. Temporary redirects (302, 307) don't carry that signal, so the old URL may stay in results.
Avoid redirect chains (A to B to C). Point old URLs straight to the final page.
After a redesign, check that every old URL with traffic or links redirects to its closest new equivalent, not just the homepage.

7. Search Console checks

Search Console is free and shows how Google sees your site. Verify your site, then check these regularly:

Page Indexing report: which pages are indexed, and why others aren't (blocked, noindex, duplicate, not found).
Sitemaps: submitted and read without errors.
Core Web Vitals report: groups of URLs rated poor or needing improvement.
HTTPS report: pages not served securely.
Manual actions and Security issues: should both say no issues detected.
URL Inspection: test an important page to see its indexing status and the canonical Google selected.

The short version

robots.txt isn't blocking anything important.
No accidental noindex on key pages.
One canonical URL per page; HTTP and duplicates redirect permanently.
Clean sitemap submitted in Search Console.
HTTPS everywhere, no mixed content.
Mobile version has the same content as desktop.
Core Web Vitals in the "good" range for real users, or a plan to get there.
Structured data valid and matching visible content.
No broken internal links; old URLs redirect to the right new pages.
Search Console shows no manual actions or security issues.

Want a second pair of eyes?

We check and fix these issues as part of our technical SEO service. Send us your URL and we'll tell you what needs attention first.

Based on Google Search Central documentation (technical requirements, robots.txt, noindex, canonicalisation, sitemaps, redirects, mobile-first indexing, page experience, structured data, crawl budget) and web.dev's Core Web Vitals guidance, as read on 18 October 2026.

Sources

Written by Koushik Paikar

Founder of Pocket Web Dev, a digital marketing and web development agency in Kolkata. About us