A technical SEO audit checklist for a small-business website

Start with the pages that matter to the business: the home page, service pages, legitimate location or service-area pages, contact paths, portfolio or proof pages, and useful articles. Combine the live navigation, XML sitemap, analytics landing pages, Search Console reports, and known campaign URLs. This exposes important pages omitted from navigation as well as obsolete URLs that still receive visits or links.

Record a baseline before changing anything. Note indexed-page patterns, branded and non-branded search visibility, organic landing pages, qualified inquiries, and known technical incidents. These measures will not prove that one repair caused every later movement, but they prevent the audit from becoming a disconnected list of scores. Save the crawl date, crawler settings, site version, and any exclusions so the review can be repeated.

Group URLs by template and purpose before reviewing individual warnings. A canonical defect across every service page is one shared problem, not fifty separate tasks; a broken booking page may deserve attention even if it is the only affected URL. Mark pages as business-critical, supporting, legacy, utility, or intentionally excluded. This creates the denominator needed to say whether a finding is isolated, systemic, or expected.

• Priority pages grouped by service and customer purpose
• Sitemap, navigation, analytics, and Search Console URL sources
• Baseline visibility, landing-page, and inquiry observations
• Recorded crawl date, settings, exclusions, and site version

A page can be linked but not indexable, indexable but difficult to discover, or accessible to a browser while important resources are blocked from a crawler. Check internal links, HTTP status codes, robots.txt access, robots meta directives, authentication, and the rendered page. Remember that robots.txt controls crawling; it is not the dependable way to remove an already known URL from search. Use the appropriate noindex or access control for that job.

Inspect representative URLs with Search Console rather than assuming that one crawl tells the whole story. Important pages should normally return a successful status, appear in the sitemap, receive crawlable internal links, and avoid accidental noindex directives. Remove broken sitemap entries and decide what should happen to retired URLs: a relevant direct redirect, a truthful not-found response, or continued availability when the content still serves a real purpose.

Compare the raw HTML response with the rendered page when JavaScript is involved. Google describes crawling, rendering, and indexing as separate stages, and content that appears only after a user click or after a failed request may never become dependable primary content. Verify that headings, explanatory copy, canonical and robots directives, structured data, and ordinary `href` links are present without requiring interaction. Server rendering or static generation can simplify this path, but the live response still needs to be tested.

• Correct status, robots access, and index directive for each template
• Crawlable internal links to every important landing page
• Sitemap entries limited to preferred indexable URLs
• Live inspection of representative pages and rendered resources

Choose one public form for each page and make the signals agree. HTTPS, hostname, trailing-slash rules, capitalization, parameters, internal links, sitemap entries, redirects, and canonical elements should not nominate competing versions. A canonical is a hint about the preferred duplicate; it is not a substitute for redirecting a URL that users and crawlers should never need to visit.

Map redirected URLs to the closest useful destination, especially after a redesign or service-name change. Avoid long chains, loops, redirects to unrelated pages, and blanket routing of every retired URL to the home page. Check external links and high-traffic old URLs first. Where filtered, tracking, print, or staging variants exist, document why they exist and prevent them from creating an uncontrolled collection of indexable duplicates.

For multilingual pages, evaluate the canonical and language signals together without confusing their jobs. A fully translated English page and Spanish page normally remain self-canonical because each is a distinct experience; reciprocal hreflang connects the equivalents. Test both directions, include every live member of the language group, and make sure the destinations return successful, indexable pages. A correct-looking tag that points to a redirect or non-canonical variant still creates contradictory evidence.

• One preferred URL reflected in links, sitemap, redirect, and canonical
• Direct redirects from legacy URLs to the closest useful replacement
• Parameter and filtered variants documented and deliberately controlled
• Localized alternates reciprocal, indexable, and canonically aligned

Google indexes from the mobile version, so confirm that responsive pages expose the same primary content, headings, metadata, links, images, and structured facts on a narrow screen. Test navigation, tap targets, forms, validation, phone links, consent controls, and confirmation states with a real device as well as automated tools. Content hidden only because a script failed is not useful to a visitor or a crawler.

Use field data where enough real-user information exists and laboratory tests to diagnose individual templates. Review loading, interaction responsiveness, and layout stability, then trace the causes: oversized media, blocking fonts or scripts, third-party widgets, unstable dimensions, or expensive client rendering. A perfect synthetic score is not the goal. Prioritize failures that affect common devices, important pages, accessibility, or completion of a call, form, or booking.

Test more than the home page. Select one URL from each layout, plus the heaviest article, the longest service page, a conversion form, and any page with maps, reviews, scheduling, video, or consent software. Use throttled lab runs to reproduce problems and field data to understand whether real visitors experience them. Record the tested device, viewport, network assumptions, and tool date so later comparisons do not mix unlike measurements.

• Equivalent primary content and metadata on mobile and desktop
• Working menus, forms, calls, consent, and confirmation states
• Field trends reviewed separately from laboratory diagnostics
• Large media, scripts, fonts, and layout shifts assigned for repair

Every important page needs a concise, descriptive title, a useful main heading, and copy that answers its actual intent. Meta descriptions can help explain a result but are not guaranteed to appear. Validate supported structured data against the visible content, required properties, and current documentation; passing a validator does not guarantee a rich result. Also check breadcrumb markup, image alternatives, social previews, and contact facts for consistency.

Compare similar pages for duplication and intent overlap. Two service pages targeting the same need with minor wording changes can compete for the same internal links and leave the visitor unsure which one applies. Conversely, combining genuinely different services into one vague page can prevent either subject from being explained well. The audit should identify where architecture, navigation labels, headings, and content need consolidation or separation based on a real customer task.

Treat structured data as a machine-readable description of visible facts, not a hidden advertising channel. Use supported types and properties, match names, URLs, images, prices, ratings, FAQs, and business details to what a person can verify on the page, and remove markup for content that no longer appears. Passing a syntax test only proves that the data can be parsed; it does not guarantee eligibility, indexing, or a special search treatment.

Finish with a prioritized register, not a raw export. For each finding, record affected URLs, evidence, user and search impact, recommended fix, owner, effort, dependency, and retest method. Separate blockers from improvements and observations. A useful priority considers business importance and breadth as well as technical severity: a shared template that hides every service description is more urgent than a cosmetic warning on one archived article.

Fix shared causes before individual symptoms, then test in an environment that represents production. Preserve a sample of before-and-after responses, screenshots, structured-data output, crawl results, and conversion tests. After deployment, request the same URLs from outside the development network, confirm status and redirect behavior, crawl again, and inspect a representative sample in Search Console. Do not close a ticket merely because the code changed.

Set a cadence based on change and risk. Recheck after migrations, navigation changes, domain or protocol moves, major releases, new language sections, and incidents; use lighter recurring monitoring for uptime, forms, index directives, sitemaps, and high-value templates. No technical audit can guarantee rankings, but a documented baseline, assigned repair, and repeatable verification can prove that a known obstacle was removed and detect when it returns.

• Affected templates, evidence, impact, owner, effort, and dependency
• Specific acceptance test for every repair before work begins
• Production crawl and conversion checks after deployment
• Monitoring cadence tied to site changes and business risk