Technical SEO Checklist for Small Business Sites (17 Checks)

This technical SEO checklist is built for small business sites with fewer than 500 URLs, and it includes the server-side checks most lists leave out: response codes, redirect chains, caching headers and AI crawler access. Each item comes with a way to check it yourself, usually in under five minutes.

Why most technical SEO checklists don't fit a small site

Search for a technical SEO checklist and you'll find lists with 70 or 100 items. Many were written for sites with a million pages. They talk about crawl budget, log file sampling and JavaScript rendering pipelines as if your 40-page plumbing site needs all of it.

It doesn't. Google's own crawl budget guide says it's aimed at sites with 1 million+ pages, or 10,000+ pages that change daily. If your pages get crawled the day you publish them, Google says you don't need to read it.

What small sites do get wrong is the plumbing underneath the pages. A robots.txt file that returns a server error. A redirect that bounces three times. A security plugin that quietly blocks ChatGPT's crawler. Those problems live on the server, so SEO checklists written by content people tend to skip them. I spend a lot of my time on servers (cPanel, Plesk, Cloudflare, plain Linux), so that's where this list leans.

If you'd rather have someone run all of this for you, my technical SEO audit questionnaire takes a few minutes, and I reply with a plan and a fixed quote within one business day.

The technical SEO checklist: 17 checks for sites under 500 URLs

You'll need Google Search Console (Google's free dashboard for site owners), a browser, and ideally a terminal for the curl commands. Swap example.com for your domain throughout.

1. robots.txt loads with a 200 and blocks nothing important

Your robots.txt file (a plain-text file telling crawlers what they may visit) has to answer quickly and correctly. Google's robots.txt rules are strict here: if the file returns a 5xx server error, Google stops crawling the site for the first 12 hours, then falls back to the last good copy for up to 30 days.

# Should print 200. A 5xx here is an emergency, a 404 just means "no rules".
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/robots.txt

Then read the file. A leftover Disallow: / from a staging site is more common than you'd think. Also remember robots.txt is not a way to keep a page out of Google. A blocked URL can still be indexed if other pages link to it.

2. AI search crawlers can reach the site

This is the check almost nobody runs. OpenAI states that sites opted out of OAI-SearchBot won't be shown in ChatGPT search answers. Its training crawler, GPTBot, is a separate bot with a separate rule. Google works the same way: blocking Google-Extended doesn't affect inclusion or ranking in Google Search.

So you can allow AI search and still say no to training:

# robots.txt: allow ChatGPT search, opt out of OpenAI and Gemini model training.
# Could break: nothing in Google Search. Delete the Disallow lines if you're happy to be used for training.
User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

robots.txt is only half of it. Firewalls block bots before they ever read the file. If you use Cloudflare, check its AI bot settings in the dashboard. Cloudflare's docs describe new default AI bot policies for new domains from September 15, 2026, with search allowed but training and agent bots blocked on pages that show ads. Security plugins can block unfamiliar bots too, so read their logs. I wrote up the details on Cloudflare quietly blocking ChatGPT.

3. The XML sitemap lists only real, final URLs

A sitemap (a list of pages you want Google to find) should hold only pages that return 200, aren't redirected, and are the canonical version. Google's sitemap guidelines cap a file at 50,000 URLs or 50 MB, say <priority> and <changefreq> are ignored, and only trust <lastmod> when it's consistently accurate.

On a small site, open the sitemap and skim it. Tag archives, test pages and "thank you" pages don't belong. Then submit it under Sitemaps in Search Console.

4. Every page returns the right response code

A response code (the three-digit status a server sends with every page) tells Google what to do with a URL. Your live pages should return 200. Deleted pages should return 404 or 410, because Google removes indexed URLs that return a 4xx.

The trap is the soft 404: an error page that returns 200. Google flags those, and they waste crawling on nothing. Test a page that can't exist:

# Should print 404. If it prints 200, your "not found" page is a soft 404.
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/no-such-page-8472/

5. Redirects take one hop, not three

A redirect chain is one redirect pointing at another, such as http://example.com to https://example.com to https://www.example.com. Google follows up to 10 hops, but the same crawl budget guide says to avoid long redirect chains because they hurt crawling. Visitors feel the delay too.

# Shows every hop. You want one 301 and then a 200.
curl -sIL http://example.com/ | grep -iE "^(HTTP|location)"

On Apache, this collapses HTTPS and www into a single hop:

# Sends http:// and non-www requests straight to https://www in ONE 301.
# Could break: behind Cloudflare "Flexible" SSL, %{HTTPS} is always off and this loops.
# Use Cloudflare's Full (strict) mode, or test %{HTTP:X-Forwarded-Proto} instead.
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]

Also check that permanent moves use 301, not 302. My post on 301 vs 302 redirects explains why that one character matters.

6. HTTPS works everywhere, with no mixed content

Google's page experience self-assessment asks plainly whether your pages are served securely. Check that the certificate is valid, that every page loads on https://, and that no images or scripts still load over http:// (that's mixed content, and browsers block or warn about it). Your browser's developer console (F12) lists mixed content warnings on each page.

7. One canonical version of every page

Your site probably answers on four addresses: with and without www, with and without https. Pick one, redirect the rest (check 5), and add a canonical tag (a line in the page code naming the preferred URL) to every page.

Google ranks the signals: redirects and rel="canonical" are strong signals, sitemap inclusion is a weak one, and robots.txt shouldn't be used for canonicalization at all. Watch for trailing-slash duplicates and tracking parameters like ?utm_source= too.

8. No accidental noindex on pages that matter

A noindex tag (an instruction telling Google not to list a page) left over from a staging site can wipe out a launch. On WordPress, check Settings > Reading and make sure "Discourage search engines from indexing this site" is unticked.

Then open the Page indexing report in Search Console and look for the "URL marked 'noindex'" reason. Google itself says not to expect every URL to be indexed. What matters is that your service, product and location pages are.

9. No index bloat from thin archive pages

Index bloat is when Google indexes lots of low-value pages, such as tag archives, author archives, image attachment pages and internal search results. On a 40-page site, 300 indexed URLs is a warning sign.

Search site:example.com and scroll. If you see pages you'd never want a customer to land on, noindex them in your SEO plugin. I cover the WordPress-specific cleanup in the index bloat guide.

10. The mobile version has the same content

Google uses the mobile version of your site for indexing and ranking. If your mobile theme hides service details, reviews or FAQs that desktop shows, Google may not count them. Load your top five pages on a phone and compare. Content that only appears after a tap or swipe deserves a second look.

11. Core Web Vitals pass on real visits

Core Web Vitals are Google's three speed and stability measures. Google's targets: LCP within 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. In plain English: the main content shows up fast, taps respond quickly, and nothing jumps around.

Run your homepage and one service page through PageSpeed Insights. Look at the field data section at the top (real visitors), not just the lab score below it. My Core Web Vitals guide for small business owners covers what to fix first.

12. Static files send long-lived caching headers

Caching headers tell browsers and CDNs how long they may reuse a file. MDN's Cache-Control reference describes the modern pattern: versioned files (where the file name or ?ver= changes when the content changes) get a one-year max-age plus immutable. WordPress adds ?ver= to most theme and plugin files, so this fits well.

# One-year browser cache for static files. Needs mod_headers.
# Could break: if you replace an image under the same file name, returning visitors
# may see the old one for a while. Leave HTML to your page cache plugin or host.
<IfModule mod_headers.c>
  <FilesMatch "\.(css|js|woff2|webp|avif|jpe?g|png|svg)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
</IfModule>

Googlebot uses a different mechanism. Google's crawler docs recommend ETag over Last-Modified for its caching, and use the ETag when both are present. Most servers send one by default. Check with curl -sI https://example.com/ | grep -i etag.

13. The server stays healthy under crawling

A slow or overloaded server shows up in Google before customers complain. Google's status code docs (the ones from check 4) say 5xx and 429 errors make its crawlers slow down, and URLs that keep failing are eventually dropped.

In Search Console, open Settings > Crawl stats. The Crawl Stats report shows host status, average response time and a breakdown of response codes. Any red host status, or a rising share of server errors, is a hosting conversation, not a content one.

14. Titles and meta descriptions are unique

Google's title guidance asks for a descriptive, concise <title> on every page, and warns against keyword stuffing and repeated boilerplate. On small sites, the usual problem is ten service pages all titled "Services | Company Name."

Meta descriptions don't rank you, but they often become the snippet under your link. One honest sentence per page about what the visitor gets beats the theme's default.

15. Every important page has a crawlable internal link

Google can only reliably follow links that are <a> elements with an href, and it says every page you care about should have a link from at least one other page on your site. Menus built purely in JavaScript, and pages reachable only through a search box, can leave pages orphaned. Make sure each service page is linked from the menu or the homepage with descriptive anchor text, not "click here."

16. Search Console and Bing Webmaster Tools are verified, by you

Verify a Domain property in Search Console, so every version of the site is covered. Then check Settings > Users and permissions and remove anyone you don't recognize. Add Bing Webmaster Tools too. It takes five minutes, because Bing can import verified sites and their sitemaps straight from Search Console.

17. No exposed files or open directory listings

This one sits on the line between SEO and security. Directory listing is an Apache feature: if a folder has no index file, the server returns a formatted listing of everything in it. Open https://example.com/wp-content/uploads/ in your browser. If you see "Index of," anyone can browse your files, and so can Google.

Add Options -Indexes to your root .htaccess to switch it off. While you're there, look for leftover files like wp-config.php.bak, backup.zip or a .git folder in the web root. Hacked sites full of spam pages cost far more rankings than any missing meta tag.

What to skip on a small site

Leave these off your list unless you have a specific reason:

• Crawl budget tuning. Google says it's for very large or fast-changing sites.
• Hreflang (language and country tags), if your site has one language for one market.
• Meta keywords. Google doesn't use them.
• Chasing a perfect 100 lab score. Passing Core Web Vitals on real visits is the goal. A green lab score on a page with no visitors proves little.

Vlad's take on running this checklist

Run it in order. Checks 1 to 5 decide whether Google can reach your pages at all, so a problem there outranks everything below it. A broken robots.txt beats a weak meta description every time.

When a small site fails this list, it's rarely on the famous items. It's a redirect chain from an old HTTPS move, a firewall rule nobody remembers adding, or a staging noindex that survived launch. Each one is a 10-minute fix once you know it's there.

If you want a second pair of eyes before spending money, the free website check covers ten of these on your homepage and a couple of service pages.

Final Thoughts

A technical SEO checklist for a small site should fit on one page and finish in an afternoon. Start with the server: robots.txt, response codes, redirects, caching and crawler access. Then move up to canonicals, indexing and titles.

When you'd rather have every page checked and a prioritized fix list your web person can follow, that's my technical SEO audit. It starts at $750 for sites under 100 pages and $1,500 for 100 to 1,000 pages. Tell me about your site in the audit questionnaire and I'll reply with a plan.

Technical SEO Checklist FAQs

What should a technical SEO audit checklist include for a small business?

For a site under 500 pages: robots.txt status, AI crawler access, a clean XML sitemap, correct response codes, one-hop redirects, HTTPS, canonical URLs, no stray noindex tags, no index bloat, mobile content parity, Core Web Vitals, caching headers, server health, unique titles, crawlable internal links, verified Search Console, and no exposed files. Skip crawl budget work unless you have tens of thousands of pages.

How often should I run a technical SEO check?

A quick pass every three months is plenty for most small sites, plus a full run after any redesign, host move, theme change or HTTPS change. Those events cause most technical problems. Search Console's Page indexing and Crawl stats reports are worth a five-minute look each month, because they warn you about new errors before traffic drops.

Can I do technical SEO myself without a developer?

Most of it, yes. Checking robots.txt, sitemaps, titles, noindex settings and Search Console needs no code. Redirects, caching headers and firewall rules need access to your server or hosting panel, and a mistake there can take the site down, so test on one rule at a time and keep a backup of any file you edit.

Does blocking AI crawlers hurt my Google rankings?

Blocking Google-Extended doesn't. Google says it has no effect on inclusion or ranking in Google Search. Blocking OAI-SearchBot is different: OpenAI says opted-out sites won't appear in ChatGPT search answers. Blocking Googlebot itself would remove you from Google. Check both robots.txt and your firewall, since either one can do the blocking.

Is a technical SEO checklist enough to rank?

No. Technical SEO makes sure Google can find, crawl and index your pages. Rankings still depend on whether those pages answer the search better than competitors, and on your reputation across the web. Think of this checklist as clearing the road. You still need something worth driving to.