What does a contractor website audit catch?
What does a contractor website audit catch?
A contractor website audit catches failures that keep a qualified visitor from finding a service page, trusting the business, or making contact. It checks crawl access, indexability, page speed, mobile usability, service and location coverage, proof, calls to action, forms, phone links, and measurement. The output should be a prioritized repair list, not a design score.
Why is this audit different from a visual website review?
A visual review asks whether the site looks current. That is useful, but it cannot tell you whether Google can index the important pages, whether the phone link works on a mobile device, or whether a completed form reaches the right inbox.
A contractor website has three jobs: appear for relevant work, help a visitor decide whether to trust the company, and make the next step easy. The audit follows those jobs in order. A polished page still fails if it is excluded from search. A fast page still fails if it never names the service or service area. A clear offer still fails if its form submission disappears.
What should the audit test first?
Start with access and indexability. There is little value in revising headlines on a page that search engines cannot crawl or are instructed not to index.
- Load every priority URL. The home page, core service pages, location pages, contact page, and confirmation page should return the intended content without an error or redirect loop.
- Inspect indexing controls. Check the robots meta tag, HTTP headers, robots.txt rules, and canonical tag on each priority page.
- Compare the sitemap with the live site. Important canonical URLs should be present. Removed, redirected, duplicate, and utility URLs should not be presented as priority pages.
- Use Search Console evidence. The Page Indexing report and URL Inspection tool can show whether Google discovered, crawled, rendered, and selected the intended canonical page.
Google is explicit about one common mistake: robots.txt manages crawler access but is not the correct way to keep a web page out of search results. A blocked URL can still appear without a description if other pages link to it. Pages that must stay out of search need an appropriate indexing control or access restriction.
How fast should a contractor website be?
Use field data where it is available, then use lab tests to diagnose the cause. A single desktop score is not a substitute for the experience of real mobile visitors.
Google's published Core Web Vitals thresholds define a good experience as Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. Google recommends evaluating these at the 75th percentile of page loads, separated between mobile and desktop.
Those figures are diagnostic thresholds, not a promise of higher rankings or more leads. The practical audit question is simpler: can a visitor see the main service message quickly, tap without waiting, and read without the page shifting under their finger?
What should be checked on each service and location page?
Each priority page should answer the reason a visitor opened it. Generic copy spread across dozens of near-identical location pages makes that harder for both people and search systems.
| Audit area | What to verify | Failure to flag |
|---|---|---|
| Search intent | The page clearly names the service and who it is for | A broad page that never answers the specific job |
| Service area | The location claim matches the areas the business actually serves | Unsupported city claims or copied location pages |
| Proof | Licensing, credentials, photos, and reviews are accurate and attributable | Vague badges, stock proof, or claims without a source |
| Next step | The phone number and request path are visible and usable | A hidden call to action or a form with unclear expectations |
| Internal links | Related services and useful supporting pages are reachable | An orphan page with no path from the main site |
The goal is not to force every page into one template. It is to verify that every page makes a truthful, specific case for the work it covers.
How do you test whether the contact path actually works?
Test the site as a customer would, on a phone and on a desktop. Use clearly labeled internal test details so the team can separate the audit from a real inquiry.
- Tap every visible phone number and confirm that the dialed number is correct.
- Submit each form with valid test data and with required fields missing.
- Confirm that the visitor sees a clear success state after submission.
- Confirm that the inquiry reaches the intended destination with the entered details intact.
- Check whether the source page and campaign details are captured when tracking is supposed to collect them.
- Repeat the test after accepting and declining optional tracking consent.
A thank-you message proves only that the browser displayed a thank-you message. It does not prove that a notification arrived, a CRM record was created, or attribution was preserved. Each handoff needs its own evidence.
What measurement checks belong in the audit?
Measurement comes after the customer path works. First confirm what the business considers a lead, then verify that the site records that action once.
Check phone clicks, form submissions, scheduler completions, and any other agreed primary action. Compare the browser event with the destination system. Duplicate tags can inflate counts, while missing confirmation logic can record a button click even when no inquiry was delivered.
This is where a website audit connects to a measurement reconciliation. The website, analytics platform, advertising platform, and CRM answer different questions. The audit should document those differences instead of forcing them to match.
How should the findings be prioritized?
Rank each finding by business impact, confidence, and repair effort. Fix blocked access, broken contact paths, false claims, and missing lead delivery before design preferences.
- Critical: the page is unavailable, unintentionally excluded from search, or unable to deliver an inquiry.
- High: the main mobile path is difficult to use, the service is unclear, or a primary conversion is not measured reliably.
- Medium: proof, internal links, metadata, or page structure is incomplete.
- Low: a cosmetic inconsistency does not block discovery, trust, or contact.
Every item should include the affected URL, the observed evidence, the expected behavior, and the smallest safe repair. That turns an audit into a work plan instead of a folder of screenshots.
When does a contractor website need repair instead of replacement?
Repair is usually the right starting point when the platform is maintainable, the page structure can support the needed services, and the contact path can be corrected without rebuilding the system. Replacement becomes reasonable when the current platform blocks essential changes, the information architecture cannot represent the business accurately, or repeated patches create more risk than a controlled rebuild.
We separate that decision from the audit itself. The evidence should determine whether the site needs a focused repair list or a new foundation. Our earlier field note explains the customer-facing symptoms of a contractor website that costs jobs. This audit is the technical and operational check that locates those failures.
Fair questions
Can we run this audit without redesigning the site?
Yes. The audit is a diagnosis, not a redesign commitment. Many findings can be repaired within the existing site, including indexing controls, broken forms, phone links, internal links, and measurement. A rebuild should be recommended only when the current platform or structure prevents a safe, maintainable repair.
Does a good PageSpeed score mean the website passes?
No. Speed is one audit area. A fast site can still hide its phone number, misroute a form, omit an important service page, or exclude pages from search. The audit checks discovery, trust, contact, and measurement together because a failure in any one of those stages can break the customer path.
What should we receive at the end of the audit?
You should receive a prioritized list tied to specific URLs and observed evidence. Each finding should state what failed, what the expected behavior is, and what repair is recommended. The useful deliverable is a sequence the team can execute and verify, not a general score or a collection of unexplained screenshots.
Sources
- web.dev: Web Vitals, Core Web Vitals definitions, thresholds, and measurement guidance.
- Google Search Central: Introduction to robots.txt, crawling and indexing control guidance.
- Google Search Central: How Google Search works, discovery, crawling, rendering, and indexing overview.
- Google Search Central: Build and submit a sitemap, canonical URL and sitemap guidance.
What is the practical next step?
Choose the pages that produce or support inquiries, then walk through the audit in order: access, performance, page purpose, proof, contact, and measurement. Record evidence before changing anything. If you want a senior-led review of the whole path, see our contractor website audit and build scope.