Website audit checklist for local-service companies.

Check the pages → Test the lead path → Check the tracking → Record the fixesFollow the source labels in order. The numbered path runs across the top row, then returns to the lower left and continues right.Check the pagesTest the leadpathCheck thetrackingRecord thefixes
Test the customer path before choosing fixes.

Check that your website helps customers reach your business. This list shows owners how to test pages, forms, phone links, and the systems behind them. Start with the live site and save what works, what fails, and what needs a fix.

This guide is part of How to QA a Personal Brand Website. Next, explore How We Audit: Which Exam to Run, What Pass Means, or SEO Audits by Dennis Yu.

Audit the business function first, then the technology. A familiar CMS or hosting brand is not evidence that a site is generating, routing, or measuring leads correctly.

Where this sits. Operator map: How we audit. Personal-brand QA master: Website QA audit. This page is the older local-service checklist — a skin, not a second trunk.

Platform-neutral rule. Record the provider, CMS, dependencies, licenses, and access actually in use. Do not recommend a host or CMS merely because BlitzMetrics has used it before. Choose and test the architecture against the site’s accepted functional baseline.

1. Business job

  • Primary services and service areas are clear.
  • The intended action—call, form, booking, or purchase—is visible.
  • Ownership exists for every lead destination.

2. Public experience

  • Important pages, navigation, media, and URLs work.
  • Mobile layouts have no clipping or horizontal overflow.
  • Trust proof is specific, sourced, and relevant.

3. Lead path

  • Primary forms and phone links are tested.
  • Spam/consent behavior and success states are recorded.
  • Notifications, CRM routing, and responsible people are verified.

4. Measurement

  • Analytics and tag-manager ownership are known.
  • Calls, form submissions, bookings, and qualified leads are measurable.
  • Conversion events fire once and reach the right account.

5. Search controls

  • Titles, descriptions, canonicals, robots directives, and sitemaps are verified live.
  • Organization/local-business schema matches the real entity.
  • Important redirects are inventoried and tested.

6. Delivery and recovery

  • HTTPS and delivery behavior are correct for the recorded architecture.
  • A recovery method, retention, and rollback owner are recorded.
  • No uptime or recovery guarantee is inferred from a provider logo.

7. Dependencies

  • Used plugins, snippets, APIs, frameworks, and licenses map to a business function.
  • Unused, abandoned, unknown, or unlicensed components are flagged.
  • Custom behavior and third-party fees have an owner.

8. Migration readiness

  • Content/data exports and key URLs are available.
  • The destination has acceptance tests for every recorded function.
  • The source and rollback path remain until tests pass.

The output is a functional baseline.

A useful audit leaves behind a testable record of pages, lead routing, tracking, redirects, search controls, publishing, dynamic behavior, dependencies, recovery, and exceptions. That record can survive a move to a new host, CMS, headless stack, or static build.

Where this task fits in the Content Factory

This task supports work across the Content Factory (our four-stage process for using real content). Its inputs and next handoff determine which stage uses it.

1. ProduceCapture real work
2. ProcessTurn sources into useful assets
3. PostPublish and connect approved assets
4. PromoteShare proven work and measure results
Follow the numbered stages from Produce to Promote. Each stage links to its part of the Content Factory guide.

Start, finish, and next step

Start when
A local-service website needs a functional audit or baseline before an architecture change.
Have ready
  • Site scope and primary business action
  • Known lead destination and owner
  • Authorized measurement and recovery evidence
Follow the steps
  1. Check the business job
  2. Test public experience and lead path
  3. Verify measurement and search controls
  4. Record delivery, recovery and dependencies
  5. Produce the baseline and action record

Use the detailed instructions in this article for each step.

Finish with
A testable website baseline with specific defects, dependencies and next actions.
Measure the result
  • Forms, calls and routing are checked where authorized
  • Numbers and conversions have real source evidence
  • Search controls and redirects are tested live
  • Recovery claims have evidence or remain exceptions
Hand off next
Give the baseline and defects to the site owner; use it to verify later fixes or a migration.

Before closing the run, name the actual next task, receiving owner, and trigger in the execution record. The assignment and findings determine that handoff.

Reference material for the inputs

Open this article’s tasks in the Task Library (our directory of tasks and recipes; see current Task Library). The library connects the current recipe, its smaller tasks, and the records of work performed.

Close the learning loop. Write a meta article: the record of this execution with the starting state, recipe version, result, checks, failures, and next owner. Link it back to this recipe and register the run under the same Task Library task. Reuse one execution ID for revisions and retries. A partial or failed run stays labeled that way. Public release follows the recorded publication authority; writing the run record is part of doing the task. Writing and revising that record belong to the original execution; they do not start another meta-article task. Use the findings to propose and verify a recipe improvement. See how recipes and execution records work together.

Need this managed for an existing client site?

Review the company-site hosting add-on and its exact service boundaries.

View the hosting add-onRead the standards