The No-Nonsense Technical SEO Checklist for Small Business Websites

Key Takeaways

• An automated SEO audit report with 200 “critical errors” is almost never a genuine emergency. The majority of flagged issues on a small business website are either irrelevant at your scale, cosmetically suboptimal, or enterprise-grade concerns that simply do not apply to a 10–50 page local or service site.
• Technical SEO for a small website has one primary objective: removing the specific roadblocks that prevent Google from crawling, indexing, and understanding your pages. Everything beyond that is optimisation, not triage.
• The fatal flaws are few and fixable without a developer. Accidental noindex tags, robots.txt blocking your own site, and broken 404 links are the technical errors that actually suppress rankings — and all three are identifiable through free tools in under an hour.
• Mobile-first indexing is not a preference — it is Google’s default evaluation mode. If your site is not usable on a phone, it will not rank competitively, regardless of how well-optimised your desktop version is.
• HTTPS is not optional. An HTTP site in 2026 displays a browser security warning that kills both trust and conversions before a visitor has read a single word.
• A “good enough” page speed is genuinely good enough. A local tradesman’s website that loads in 3.5 seconds will consistently outrank a technically immaculate competitor with better Core Web Vitals but weaker content and fewer reviews. Chase functional, not perfect.
• The tools required for a competent small business technical SEO audit cost nothing. Google Search Console, Screaming Frog’s free tier (up to 500 URLs), and either RankMath or Yoast on WordPress cover 95% of what you need to check and fix.
• Canonical tags, hreflang, JavaScript rendering issues, and CSS minification are enterprise concerns. Unless your site operates in multiple languages, across multiple domains, or uses a heavily JavaScript-rendered architecture, these are audit report noise that you can safely and permanently deprioritise.

---

---

The 80/20 Rule of Technical SEO for Small Sites

The anxiety-inducing audit report you received — the one flagging 247 critical issues across your 18-page WordPress site — is not a faithful representation of your site’s actual SEO health. It is the output of an enterprise-grade crawler applying enterprise-grade criteria to a site that operates at a fundamentally different scale and with fundamentally different competitive requirements. Understanding this distinction is the first and most important step in approaching technical SEO as a small business owner.

Why Small Websites Don’t Need Enterprise SEO Solutions

The technical SEO challenges facing a 50,000-page e-commerce catalogue are categorically different from those facing a 25-page local plumbing company’s website. The tools designed to audit large sites — Ahrefs, Semrush, Screaming Frog at full crawl depth — are exceptional instruments for the problems they were built to solve. When applied to a small site, they produce a disproportionate volume of low-severity warnings because they have no scale-sensitivity: a flagged issue on a 50,000-page site, where it affects 3,000 pages, is a genuine crisis. The same flag on a 25-page site, where it affects two pages, is a five-minute fix at most — or, in many cases, not worth fixing at all.

The specific concerns that make enterprise technical SEO complex — JavaScript rendering at scale, international hreflang implementation, canonicalisation across millions of near-duplicate product URLs, crawl budget management across deep site architectures — do not exist in any meaningful form for a local service business or a small e-commerce store with a curated product range. These are problems of scale, and your site does not have a scale problem.

What your small site does have is a focused set of technical concerns that genuinely affect whether Google can find your pages, evaluate their quality, and serve them to the right searchers. Those concerns are the subject of this checklist. Everything else is background noise.

The Trap of “100/100” PageSpeed Scores: Why Perfection is a Waste of Budget

The Google PageSpeed Insights score is one of the most misunderstood metrics in small business digital marketing, and the pursuit of a perfect 100/100 score has caused more wasted developer budget and site-breaking experimentation than almost any other SEO misconception.

The reality, documented through extensive ranking factor correlation studies, is this: Page speed is a tiebreaker in competitive ranking scenarios, not a primary ranking determinant. A local accountancy practice in Winchester that loads in 3.2 seconds will consistently outrank a competitor that loads in 1.8 seconds if the first site has stronger content, more genuine reviews, and better local relevance signals. The speed difference, in the context of a 10-page service site competing against other 10-page service sites, is not the variable that determines the winner.

What does matter from a speed perspective:

• Pages that take longer than approximately 5–6 seconds to display meaningful content on mobile create user experience failures that generate high bounce rates and reduced dwell time — behavioural signals that do affect rankings
• Unoptimised images that add 3–5MB of unnecessary page weight to every load are a genuine, easily fixable problem
• Intrusive third-party scripts (live chat widgets, marketing tracking pixels, video embeds) that block page rendering are addressable without touching core code

The benchmark for a small business site is not 100/100 on PageSpeed — it is “fast enough that users on a standard mobile connection can start reading within 3 seconds.” Reaching that benchmark is a free, tool-assisted afternoon of work. Getting from 78/100 to 96/100 thereafter requires either a skilled developer or weeks of plugin experimentation with meaningful risk of breaking things. The SEO return on that second investment is negligible for a site competing locally.

How Technical SEO Actually Works: Crawling, Indexing, and Ranking Explained Simply

Google’s relationship with your website has three sequential stages, and a technical problem at any stage blocks all subsequent stages. Understanding this sequence in plain English tells you immediately why certain issues are fatal and others are trivial.

Stage 1 — Crawling: Google dispatches automated bots (Googlebot) that follow links to discover and read your pages. If your robots.txt file or a noindex tag tells these bots to stay away, they leave and never return. If your site has no internal links pointing to certain pages, the bots may never find those pages. A crawling problem means Google cannot see your content at all.

Stage 2 — Indexing: After crawling a page, Google decides whether to add it to its index — the database of pages eligible to appear in search results. If the page is blocked, too thin, or a duplicate of another page, Google may choose not to index it. An indexing problem means your page is invisible in search results even if it exists on your server.

Stage 3 — Ranking: Once a page is indexed, Google evaluates it against hundreds of relevance and quality signals to determine where it should appear for relevant queries. Technical factors like speed, mobile usability, and structured data are signals at this stage. A ranking problem means your page is indexed but not competitive enough to appear where users will find it.

The 80/20 rule of technical SEO follows directly from this model: the fatal flaws are exclusively Stages 1 and 2 problems. A site that cannot be crawled or indexed cannot rank regardless of how good its content is. A site that is crawled and indexed but has a 78/100 PageSpeed score will rank based on the quality of its content, relevance signals, and backlinks — the factors that matter far more for a small site than milliseconds of render time.

---

Phase 1: The “Fatal Flaws” — Fix These Immediately

The fatal flaws are the technical issues that directly prevent your pages from appearing in Google search results. Every other technical concern in this guide is subordinate to these three. Before you do anything else — before you check your speed, before you set up schema markup, before you optimise a single image — verify that none of these issues are present on your site.

Checking Indexability: Using the “site:” Search Operator and GSC Coverage Report

The fastest way to understand how much of your site Google has indexed is to use the site: search operator directly in Google. Type site:yourdomainname.co.uk into Google search (replacing with your actual domain) and the results page shows every page from your domain that Google currently has in its index.

What to look for:

• If zero results appear: Your site has a severe indexing problem — likely a sitewide noindex tag, a robots.txt block, or a domain configuration issue. This requires immediate investigation before anything else.
• If significantly fewer pages appear than you have published: Some of your pages are not indexed. Note which content areas appear to be missing and investigate those pages specifically.
• If approximately the right number of pages appear: Your basic indexing is functional. Proceed with the remainder of this checklist.

The Google Search Console Coverage Report (more precise):

1. Log into Google Search Console at search.google.com/search-console
2. In the left sidebar, navigate to Indexing → Pages
3. Review the four categories: Indexed (pages Google has included in its index), Not indexed (pages Google has found but excluded), Crawled – currently not indexed (pages Google visited but decided not to include), and Discovered – currently not queued (pages Google knows about but hasn’t yet visited)

The Not Indexed section is your primary concern. Expand each sub-category to see why Google has excluded those pages. The most common legitimate reasons for small sites include:

• “Alternate page with proper canonical tag” — indicates duplicate content that Google has correctly consolidated
• “Crawled – currently not indexed” — often indicates thin or low-quality content that Google has decided not to include; review those specific pages
• “Excluded by ‘noindex’ tag” — confirm whether these exclusions are intentional

Rogue “Noindex” Tags and Accidentally Blocking Crawlers via Robots.txt

These two errors are the most catastrophically impactful technical SEO mistakes a small business owner can make — and both are embarrassingly easy to trigger accidentally on a WordPress site.

The WordPress “Discourage Search Engines” Checkbox:
WordPress has a setting under Settings → Reading that, when ticked, adds a noindex directive to your entire site and instructs search engines not to crawl it. This setting is designed to prevent indexing during site development — but it is regularly left enabled after launch, or accidentally activated during a theme or plugin update. A site that has had this checkbox ticked for three months is effectively invisible to Google.

How to check it right now:

1. Log into your WordPress admin dashboard
2. Go to Settings → Reading
3. Look for “Search engine visibility” — the checkbox should be unticked for a live site. If it is ticked, untick it and save changes immediately.

Robots.txt accidental blocking:
Your robots.txt file, accessible at yourdomainname.co.uk/robots.txt, tells search engine bots which areas of your site they are allowed to crawl. A misconfigured robots.txt can accidentally block your entire site or block specific subdirectories containing important content.

How to check it:

1. Type yourdomainname.co.uk/robots.txt directly into your browser
2. You should see a file containing something similar to:

   User-agent: *
   Disallow:
   Sitemap: https://yourdomainname.co.uk/sitemap.xml

3. A blank Disallow: line means “no restrictions for all bots” — this is correct for a public site
4. If you see Disallow: / (with a forward slash), this is blocking all bots from your entire site — a critical error requiring immediate correction

In Google Search Console, you can verify your robots.txt configuration under Settings → robots.txt without needing to access your server directly.

Finding and Fixing Broken Internal Links (404 Errors)

A 404 error page — the “page not found” error that appears when a URL no longer exists — is a crawl dead end for Googlebot. When a bot follows an internal link to a 404 page, it stops there. No page equity passes through the broken link. If that 404 page previously had external backlinks pointing to it, all of that link authority is lost rather than flowing to your current pages.

For a small site, 404 errors typically arise from:

• Deleted pages where the URL was not redirected
• Changed permalink structures (e.g. reorganising WordPress categories) without implementing redirects
• Manual typos in internal link URLs

How to find 404 errors for free:

Method 1 — Google Search Console:
Navigate to Indexing → Pages → Not Indexed → Not Found (404). This shows every URL on your domain that Googlebot has encountered and found to be a 404. These are the broken links Google has discovered through your internal link structure or through external backlinks.

Method 2 — Screaming Frog (free for up to 500 URLs):

1. Download the free version of Screaming Frog SEO Spider from screamingfrog.co.uk
2. Enter your domain URL and run a crawl
3. In the results, filter by Response Codes → Client Error (4xx)
4. This shows every internal URL returning a 404 or similar error, along with which pages contain the broken link

How to fix 404 errors:
The correct fix for a 404 on a page that previously had content is a 301 redirect — a permanent redirect that tells both users and search engines that the page has moved to a new URL. On WordPress, the Redirection plugin (free) manages 301 redirects through a simple admin interface with no code required. On Shopify, URL redirects are manageable directly in the admin panel under Online Store → Navigation → URL Redirects.

Expert Tip: Before implementing redirects, check whether any of your 404 pages have external backlinks pointing to them. In Google Search Console, go to Links → External Links → Top Linked Pages — any deleted page appearing in this list has external authority to recover through a well-targeted 301 redirect. Prioritise these above any unlinked 404s.

---

Phase 2: The User Experience (UX) Essentials

Once you have confirmed that your site is crawlable and indexed, the next priority tier addresses the technical factors that directly affect how users — and Google’s evaluation of user experience — interact with your site. These are not as immediately catastrophic as the fatal flaws, but they have a significant impact on both ranking competitiveness and conversion rates.

Mobile-First Indexing: Ensuring Your Site is Actually Usable on Phones

Google moved to mobile-first indexing as its default in 2019, and as of 2024 all sites are evaluated under mobile-first principles. This means that Google uses the mobile version of your site — not your desktop version — as the primary basis for evaluating content, relevance, and ranking. If your mobile experience is materially worse than your desktop experience, your rankings reflect the mobile quality.

The most common mobile usability failures on small business sites:

• Text too small to read without zooming: Google’s recommended minimum font size for body text is 16px. Smaller text forces users to pinch-zoom, and Google’s Mobile Usability report flags this as a problem.
• Tap targets too close together: Buttons and links that are closer than approximately 48px apart are difficult to tap accurately on a touchscreen. Menus and contact buttons are the most common offenders.
• Content wider than the screen: Elements (images, tables, embedded content) that exceed the viewport width force horizontal scrolling — one of the clearest signals of a non-mobile-optimised page.
• Intrusive interstitials: Full-screen pop-ups that appear immediately on mobile page load are penalised by Google’s intrusive interstitials algorithm. Timed pop-ups that appear after 10–15 seconds of engagement are generally acceptable; immediate full-screen cover overlays are not.

How to check mobile usability for free:

1. Google Search Console → Experience → Mobile Usability — shows specific pages flagged for mobile usability errors with the error type identified
2. Google’s Mobile-Friendly Test (search.google.com/test/mobile-friendly) — provides an immediate pass/fail evaluation and identifies specific issues for any individual URL
3. Simply use your phone — load your most important pages on a real phone and attempt to navigate, read, and use the contact form without zooming. Your experience as a first-time mobile visitor is the most honest evaluation available.

The fix: If your site is running a modern WordPress theme (Divi, Astra, Kadence, GeneratePress, OceanWP — any theme updated within the past two years) on current versions, mobile responsiveness is likely built in and configurable through the theme’s mobile settings without any code. If your site is running on a theme from 2015 that has not been updated, a theme change is the correct solution — not CSS customisation of a fundamentally non-responsive codebase.

SSL Certificates (HTTPS): The Absolute Baseline for Browser Trust and Conversions

An SSL certificate is the technology that encrypts the connection between your website and your visitors’ browsers, indicated by the padlock icon in the browser address bar and the https:// prefix in your URL. In 2026, HTTPS is not a competitive advantage — it is the minimum technical requirement for a legitimate business website. An HTTP site displays a “Not Secure” warning in Chrome (and all major browsers), which is one of the most effective conversion killers in web design: a significant proportion of first-time visitors will leave immediately upon seeing this warning, regardless of how good the site content is.

How to check whether your SSL certificate is correctly configured:

1. Type your domain URL into a browser and verify that the address bar shows https:// and a padlock — not http:// or a warning symbol
2. Check that all pages redirect correctly from HTTP to HTTPS (type http://yourdomainname.co.uk and verify it automatically redirects to the HTTPS version)
3. Verify that there are no mixed content warnings — pages that load via HTTPS but contain images, scripts, or stylesheets referenced via HTTP URLs. These generate a broken padlock or warning symbol despite the HTTPS certificate. In Chrome, right-click → Inspect → Console will show mixed content warnings in red.

SSL certificates are free through Let’s Encrypt, and all major hosting providers (SiteGround, Kinsta, WP Engine, Cloudflare) provide one-click SSL installation. If your hosting control panel (cPanel or equivalent) does not have Let’s Encrypt already installed, contact your host — any reputable provider in 2026 will enable this for free within minutes.

“Good Enough” Site Speed: Optimising Images Without Hiring a Developer

Image optimisation is the single highest-return speed improvement available to a small business site owner with no technical development skills. Uncompressed images — the high-resolution photographs output by modern smartphone cameras, stock photo downloads, and design software exports — are frequently the single largest contributor to slow page load times, and they are fixable through a free WordPress plugin in under 20 minutes.

The image optimisation priority list:

Step 1 — Identify the problem:
Run your homepage and your single most important landing page through Google PageSpeed Insights (pagespeed.web.dev). Scroll to the “Opportunities” section. If “Properly size images” or “Serve images in next-gen formats” appears here, you have an image weight problem worth addressing.

Step 2 — Install an image compression plugin (WordPress):
ShortPixel (free tier: 100 images/month) and Imagify (free tier: 200 images/month) both automatically compress and convert images to WebP format (Google’s preferred modern image format) on upload and retroactively across your existing media library. The free tiers are sufficient for most small sites to complete an initial optimisation pass.

Step 3 — Set appropriate image dimensions at upload:
The single most impactful manual change: never upload an image wider than 1,200–1,400 pixels for web use. A 4,000px-wide photograph from a camera or stock library serves the same visual purpose at 1,200px wide — but at one-third the file size or less. Resize images before uploading using free tools like Squoosh (squoosh.app) or simply Preview on Mac.

Step 4 — Lazy load images:
Most modern WordPress themes and page builders have lazy loading enabled by default (images below the fold load only as the user scrolls to them, rather than all at once on page load). Verify this is active in your theme or page builder settings.

---

Phase 3: Helping Google Understand Your Site Structure

Phases 1 and 2 address preventing Google from being blocked and ensuring users have an acceptable experience. Phase 3 is about active communication — giving Google the signposts and structural signals that help it understand what your site covers, which pages are most important, and how all your content relates to each other.

Generating and Submitting a Clean XML Sitemap to Google Search Console

An XML sitemap is a structured file that lists every important URL on your website, providing Googlebot with a complete map of the content it should prioritise crawling. For a small site with a clean internal link structure, Google will eventually discover your pages through link-following alone — but submitting a sitemap removes the “eventually” and ensures Google is aware of your full content inventory promptly after publication.

For WordPress sites:
If you are using RankMath or Yoast SEO (both free, both covered in detail in the tools section), your XML sitemap is generated automatically and available at yourdomainname.co.uk/sitemap.xml (RankMath) or yourdomainname.co.uk/sitemap_index.xml (Yoast). No manual configuration is required.

For Shopify sites:
Shopify automatically generates and maintains an XML sitemap at yourdomainname.co.uk/sitemap.xml. No plugin or configuration is required.

Submitting your sitemap to Google Search Console:

1. Log into Google Search Console
2. In the left sidebar, navigate to Indexing → Sitemaps
3. In the “Add a new sitemap” field, enter your sitemap URL (e.g. sitemap.xml or sitemap_index.xml)
4. Click Submit

Google will now regularly revisit your sitemap to discover new and updated content. After submission, check back after 48–72 hours to confirm the sitemap is showing as “Success” and that the number of submitted URLs matches your expected page count.

Sitemap hygiene checklist:

• Ensure your sitemap contains only pages you want Google to index — do not include admin pages, thank-you pages, or login URLs
• Verify the sitemap URL is referenced in your robots.txt file (most plugins add this automatically)
• Remove or noindex low-value pages (thin tag pages, author archives, date archives in WordPress) before they appear in your sitemap

Flat Architecture: Why No Important Page Should Be More Than 3 Clicks from the Homepage

Site architecture — the hierarchical structure of how your pages link to each other — affects both crawl efficiency and the distribution of link authority throughout your site. A flat architecture, where every important page is reachable from the homepage within three clicks, is the structural ideal for a small business site.

Why depth matters:
Googlebot allocates a crawl budget to each domain — a finite number of pages it will crawl in a given period. For a small site, this budget is more than sufficient to cover all pages if they are well-linked. However, pages buried four or five levels deep in a site hierarchy are crawled less frequently and receive less internal link authority than pages close to the homepage. A local service page at yoursite.co.uk/services/residential/plumbing/emergency-callouts/bournemouth/ is crawled far less efficiently than the same content at yoursite.co.uk/emergency-plumber-bournemouth/.

The flat architecture audit:

1. List your ten most commercially important pages
2. Starting from the homepage, count how many clicks it takes to reach each one by following the natural navigation path
3. Any important page requiring more than three clicks is either too deep in your architecture or is not being properly surfaced through your navigation

Practical restructuring for WordPress:
You rarely need to change your URL structure (which would require 301 redirects across affected pages) — the more practical fix is ensuring that your most important pages are directly linked from your homepage, your main navigation, and your footer navigation. These placement decisions reduce the effective click depth without restructuring your URL hierarchy.

Fixing Orphan Pages: Ensuring Every Valuable Post Has Internal Links

An orphan page is a page that exists on your website but has no other pages linking to it. Googlebot discovers pages primarily by following links — an orphan page that is not linked from anywhere on your site is unlikely to be crawled regularly (if at all), will accumulate no internal link authority, and will typically rank poorly even for highly specific queries where it would otherwise be competitive.

How to find orphan pages:

1. Export a list of all URLs on your site (from your XML sitemap or a Screaming Frog crawl)
2. Run a Screaming Frog crawl and export the list of all URLs that were discovered through crawling (i.e. found by following links)
3. Any URL in your sitemap export that does not appear in the crawl-discovered list is an orphan page — it exists but has no internal links pointing to it

The orphan page fix:
For each identified orphan page, add contextual internal links from at least two to three relevant pages on your site. A blog post, a service page, or a footer link — any link that is contextually natural and places the orphan page within your site’s navigational logic. After adding links, submit the previously orphaned page via the URL Inspection tool in Google Search Console to request a fresh crawl.

---

What to Safely Ignore: The “Don’t Panic” List

This section is, for many small business owners, the most valuable in the entire guide. These are the audit tool flags you can permanently deprioritise, without qualification, for a small local or service site — freeing your time and budget for the genuinely impactful work above.

Micro-Optimising Core Web Vitals

Core Web Vitals — Google’s three user experience metrics comprising Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) — are a legitimate ranking factor in Google’s Page Experience signal. However, they are a secondary ranking factor that is only likely to differentiate competitive rankings in scenarios where all other signals are broadly equal.

The realistic guidance: If your Google Search Console Page Experience report shows the majority of your URLs as “Good”, you have passed the threshold that matters. If a small number of pages are flagged as “Needs Improvement” (yellow, rather than red “Poor”), the ranking impact on a local competitive landscape is genuinely negligible — the content, review, and authority signals discussed elsewhere in this guide matter far more.

What you can ignore permanently:

• PageSpeed Insights scores in the 65–85 range (unless specific “Poor” flagged metrics are present)
• Individual millisecond improvements to LCP or FID
• Minor CLS issues on pages with no significant content stability problems
• Optimising third-party script loading order beyond what your caching plugin handles by default

What you should actually check: Does your site load within 5 seconds on a mid-range mobile device on a 4G connection? If yes, your speed is not a meaningful ranking constraint. If no, return to Phase 2 and address the image optimisation and caching basics before worrying about any CWV metric specifically.

Complex Canonical Tags and Hreflang

Canonical tags are HTML elements that tell Google which version of a duplicate or near-duplicate URL should be treated as the original. Hreflang tags signal to Google which language and geographic version of a page to serve to users in different countries. Both are legitimate technical SEO tools — for sites that need them.

For a typical small UK business website:

• Canonical tags are managed automatically by RankMath or Yoast, which applies a self-referential canonical to every page by default. You do not need to manually configure, audit, or optimise canonical tags unless your site has a specific structural reason to produce duplicate content (which most small sites do not).
• Hreflang tags are entirely irrelevant for a single-language, single-country website targeting UK customers in English. If your site has no international audience and no content in multiple languages, ignore every hreflang warning in every audit report you ever receive.

Minifying Every Line of CSS and JavaScript

CSS and JavaScript minification — the process of removing whitespace, comments, and unnecessary characters from code files to reduce their size — is a legitimate optimisation that can modestly reduce page load times. It is also a task that most WordPress caching plugins (WP Rocket, W3 Total Cache, LiteSpeed Cache) handle automatically with a single checkbox.

What to do: Enable your caching plugin’s minification option (usually under a “File Optimisation” or “Minification” tab) and leave it to handle this automatically. Do not manually edit CSS or JavaScript files. Do not hire a developer to manually minify your code. Do not spend time attempting to diagnose which specific files are the best minification targets.

The important caveat: Aggressive JavaScript minification, particularly combining and deferring scripts, can sometimes break functionality on WordPress sites (especially page builders, booking forms, and WooCommerce checkout flows). If you enable minification and something on your site stops working correctly, disable the JS minification option — the marginal speed gain is not worth a broken checkout or contact form. Most experienced WordPress developers will tell you the same thing.

---

The Free Tech SEO Tool Stack for Small Businesses

A fully functional technical SEO audit and monitoring workflow for a small business website requires exactly zero paid software subscriptions. The following three-tool stack covers crawl error detection, indexation monitoring, and on-page SEO automation — the entirety of what a small site requires on an ongoing basis.

Google Search Console: Your Single Source of Truth for Indexing

Google Search Console (GSC) is the most authoritative, most directly Google-data-sourced, and most completely free SEO tool available. It is not a third-party estimate of your site’s performance — it is Google directly reporting what it knows about your site, what it has indexed, what errors it has found, and what queries are driving your organic traffic.

The GSC reports every small business owner should review monthly:

Report	Location in GSC	What to Look For
Pages (Coverage)	Indexing → Pages	Any sudden changes in indexed page count; new “Not Indexed” categories appearing
Performance	Performance → Search Results	Your top ranking queries; CTR for key pages; pages gaining or losing impressions
Mobile Usability	Experience → Mobile Usability	Any pages flagged with mobile usability errors
Core Web Vitals	Experience → Core Web Vitals	Pages in “Poor” status (red); ignore “Needs Improvement” unless widespread
Sitemaps	Indexing → Sitemaps	Confirm sitemap status remains “Success”; check submitted vs. indexed URL count
Links	Links	Monitor for unexpected changes in external linking patterns
Manual Actions	Security & Manual Actions	Any manual penalties applied to your site — check this immediately if rankings drop suddenly

Setup requirement: GSC requires domain verification to access data. The easiest verification method for a WordPress site is through the RankMath or Yoast SEO plugin, which connects your site to GSC automatically during setup. Alternatively, verify via your Google Analytics property or by adding a meta tag to your site’s header (both methods are guided within the GSC setup interface).

Screaming Frog SEO Spider: Using the Free Version to Find Broken Links

Screaming Frog SEO Spider is a desktop application that crawls your website exactly as Googlebot does, following every internal link and reporting on the technical attributes of every URL discovered. The free version crawls up to 500 URLs — sufficient for every small business site at the scale described in this guide.

The free version’s most valuable use cases for small sites:

Finding 404 broken links:
After running a crawl (enter your domain URL and click Start), filter the results by Response Codes → Client Error (4xx). This surfaces every internal URL on your site that returns a 404 error, along with the specific page that contains the broken link — giving you both the problem and the location to fix it.

Finding orphan pages:
Export your full crawl URL list and compare it against your XML sitemap URL list (export from GSC or from your plugin). Any URL in the sitemap but not discovered during the crawl is an orphan page with no internal links.

Checking page titles and meta descriptions at scale:
Navigate to Page Titles and Meta Description tabs to review your on-page SEO elements across all pages simultaneously. Flag any pages with missing, duplicate, or over-length titles and descriptions for quick manual correction.

Identifying redirect chains:
Filter by Response Codes → Redirection (3xx) to find pages going through multiple redirect hops (A → B → C rather than A → C). Redirect chains add unnecessary load time and dilute link authority — flatten them to direct redirects where possible.

Practical usage note: Run a Screaming Frog crawl quarterly rather than obsessively — the site errors it surfaces do not change minute-to-minute, and the time investment of interpreting a full crawl report more frequently than this rarely reveals new issues on a stable small site.

Leveraging Free WordPress Plugins (RankMath or Yoast) to Automate the Heavy Technical Lifting

RankMath and Yoast SEO are the two dominant WordPress SEO plugins, and both free versions automate the majority of the technical SEO configuration that would otherwise require manual code editing — making them the single most impactful technical tool investment available to a WordPress site owner. (The investment being zero, since both are entirely free at the level required by small sites.)

What RankMath or Yoast handles automatically for you:

• XML sitemap generation and maintenance — automatically includes new pages and posts; automatically excludes administrative URLs
• Robots.txt management — configurable through the plugin’s settings panel without file-level access
• Canonical tag implementation — applies self-referential canonical tags to all pages by default, preventing accidental duplicate content signals
• Schema markup / structured data — adds LocalBusiness, Article, BreadcrumbList, and WebSite schema automatically; configurable through the plugin settings without touching JSON-LD code
• Meta title and description management — provides individual page-level controls for every page and post through the WordPress editor interface
• Open Graph and Twitter Card tags — controls how your pages appear when shared on social platforms
• Breadcrumb navigation — configurable structured breadcrumbs that improve both user navigation and Google’s understanding of site structure
• Google Search Console integration — connects your site to GSC through the setup wizard, simplifying the verification process

RankMath vs. Yoast: which to choose?
For a small business owner implementing one for the first time in 2026, RankMath is the recommended choice. Its free version includes schema markup tools and advanced configuration options that Yoast reserves for its premium tier, its interface is more intuitive for non-technical users, and its setup wizard provides guided configuration that produces a sensible default technical setup without requiring expert knowledge.

For sites already running Yoast with established configurations and redirects managed through the plugin, switching is rarely worth the migration effort — Yoast’s free version is entirely adequate for small site technical SEO requirements.

---

Conclusion

The automated audit report that triggered this search was not lying — those issues are technically present on your site. But it was applying an enterprise measuring stick to a small business context, and the resulting alarm is disproportionate to the genuine impact of most flagged items.

The actual technical SEO work for a small business site is this: confirm your site is not accidentally blocking Google from seeing it, ensure it is usable on a mobile phone, get an SSL certificate active, fix any obvious 404 broken links, submit a sitemap, and ensure your most important pages are accessible within three clicks of the homepage. Install RankMath or Yoast and let them manage the structural technical details automatically. Check Google Search Console once a month for unexpected changes. Run Screaming Frog once a quarter for broken link maintenance.

That is the entire technical SEO foundation your site needs. Everything beyond it — the PageSpeed decimal points, the canonical audits, the JavaScript minification tuning — is legitimate optimisation work for a specialist with time and budget to invest. For a small business competing locally in Southampton, Dorchester, or Salisbury, the ranking leverage is in your content quality, your review strategy, and your local relevance signals — not in the last seven milliseconds of your LCP score.

Fix the fatal flaws. Reach “good enough” on everything else. Spend the remaining time building the content and credibility that actually wins local search.

---

FAQ

My site passed the “site:” check and shows correctly on mobile, but I’m still not ranking. Is this a technical problem?

Almost certainly not. If your site is crawled, indexed, and mobile-friendly with an SSL certificate, your technical foundation is sound. The more likely causes for poor rankings are: insufficient topical authority (not enough quality content covering your target topic area), insufficient local relevance signals (incomplete or unoptimised Google Business Profile, few genuine reviews), or insufficient backlink authority relative to the competitors currently ranking above you. These are content, local SEO, and authority-building challenges — not technical SEO problems. Use the remaining guides in this series to address those dimensions systematically.

My automated audit tool says I have 312 critical errors. Do I need to fix all of them?

No. Run the site through the Phase 1 fatal flaw checks described in this guide and confirm that your pages are indexable and not blocked. If those checks pass, your 312 “critical errors” are almost certainly a combination of: duplicate title tag warnings across similar service pages (low priority for a small site), image alt text missing from decorative images (accessibility concern, not a ranking issue), redirect chain notices for minor legacy URLs, and various Enterprise-grade configuration suggestions that are irrelevant to your site’s scale. Address the Phase 1 and Phase 2 items in this guide and review the remainder item-by-item against the “What to Safely Ignore” section before acting on anything else.

Do I need to hire a developer to fix any of the issues in this guide?

For the vast majority of small business sites on WordPress, Shopify, or Wix, no. Every Phase 1 fix (noindex checks, robots.txt, 301 redirects via a plugin), every Phase 2 fix (image compression, SSL certificate, mobile usability), and every Phase 3 fix (sitemap submission, internal linking) is achievable through plugin interfaces, admin panels, and free online tools without accessing server files or writing code. The only scenarios where a developer is genuinely required are: a fundamentally broken site architecture requiring URL restructuring at scale, a custom-built site without a CMS interface, or a specific technical issue (such as a server configuration problem) that falls outside the scope of plugin-manageable settings.

How often should I re-run a technical SEO audit on my small business site?

For a stable small business site that is not undergoing active development, a quarterly Screaming Frog crawl for broken links and a monthly review of your Google Search Console Coverage and Performance reports is entirely sufficient. A full audit — working through this checklist systematically — is worthwhile whenever: you launch a new site, migrate to a new domain or hosting provider, make significant structural changes to your navigation or URL structure, or experience a sudden unexplained drop in organic traffic. The last scenario specifically warrants checking the Manual Actions report in GSC first, followed by the Coverage report for any sudden changes in indexed page counts.

My site is on Wix or Squarespace, not WordPress. Does this guide still apply?

The technical SEO principles in this guide are platform-agnostic — crawlability, indexation, mobile usability, HTTPS, and site structure apply equally to every website regardless of how it was built. The specific implementation steps vary: Wix and Squarespace both provide built-in SEO settings panels (accessible through their respective admin dashboards) that manage most of the same configuration that WordPress plugins handle, without requiring a separate plugin. Wix has a dedicated SEO Setup Checklist within its dashboard; Squarespace has an SEO panel under Marketing. The Google Search Console integration, sitemap submission, and mobile usability check processes are identical regardless of your platform. The primary limitation of hosted platforms (Wix, Squarespace, Shopify) versus WordPress is reduced flexibility for advanced configuration — but for the small site technical SEO baseline described in this guide, that limitation is inconsequential.