I audited 100+ local business websites. Here are the 5 technical mistakes almost all of them make.

Over the last month, our team manually audited more than 100 local business websites across the US, Canada, and the UK. Mostly law firms, med spas, clinic websites, and home trade contractors.

These were not companies running on $50 DIY page builders from 2008. Most had paid an agency anywhere between $3,000 and $10,000 for their current build.

Yet over 80% of them had basic technical defects that actively hurt their page load speeds and search engine visibility.

If you build or maintain client websites, here are the five mistakes we ran into repeatedly, plus how to fix them in 15 minutes.

1. The 6MB uncompressed hero image

This was on almost every site.

The agency exported a stock photo or drone shot straight from the camera as a 4500x3000 JPEG. It weighed 6.2MB. It sat directly in the hero container with no compression, no srcset, and no loading="eager" or fetchpriority="high".

On a MacBook running on office fiber, nobody noticed. On a mobile phone loading over a spotty LTE connection outside an office, the First Contentful Paint took 6.8 seconds.

The fix:

Resize the image to what the layout actually displays. Convert it to modern formats like AVIF or WebP.

src="/hero.jpg"
alt="Dental clinic reception area in Austin"
width="1200"
height="675"
fetchpriority="high"
decoding="async"
/>

That single change usually brings the hero payload under 120KB and cuts load times in half.

1. Single Page Apps where standard HTML was needed

We saw dozens of boutique law offices and clinics built as client-rendered React or Vue single-page applications.

When you inspected the raw network response via curl -s https://example.com, you got this:

<!DOCTYPE html>

Google claims its web crawler renders JavaScript, and it does eventually. But rendering JS costs Google compute resources. For small local sites with low domain authority, search bots frequently scrape only the blank initial HTML shell, wait days or weeks to render the full bundle, and miss core metadata altogether.

If a site exists purely to inform visitors and capture local search leads, ship server-rendered HTML. Whether you use Next.js, Astro, Remix, TanStack Start, or clean static HTML, the raw response needs to contain actual readable text, headings, and meta tags.

1. Missing or copy-pasted, invalid JSON-LD schema

Local search engines rely on structured data to verify physical locations, opening hours, phone numbers, and service areas.

Out of 100 audited sites:

46 had no structured data at all.

31 had structured data, but it was broken. Missing closing brackets, duplicate @id entries, or outdated schema types like generic WebPage.

Only 23 had valid, complete LocalBusiness, LegalService, or MedicalBusiness schema.

Here is what a clean, minimal LocalBusiness block looks like:

{
"@context": "https://schema.org",
"@type": "LegalService",
"name": "Oak & River Law Practice",
"url": "https://example.com",
"telephone": "[phone]",
"address": {
"@type": "PostalAddress",
"streetAddress": "100 Main St, Suite 400",
"addressLocality": "Denver",
"addressRegion": "CO",
"postalCode": "80202",
"addressCountry": "US"
},
"areaServed": ["Denver", "Aurora", "Lakewood"]
}

Always run your output through Google's Rich Results Test or schema.org validator before shipping. Do not guess.

1. 404ing sitemaps and staging links in robots.txt

You would expect a sitemap to be table stakes, but we found broken sitemaps on roughly 25% of the sites we checked.

Common variations we found in production:

robots.txt pointed to https://example.com/sitemap.xml, but that URL returned a 404 page.

The sitemap still listed the agency's staging domain (for example, staging.webagency-test.dev/about) instead of the live production domain.

Every dynamic blog post or subpage created in the CMS was never wired into the sitemap generator, so only the homepage was submitted.

Verify your /robots.txt and /sitemap.xml directly in your deployment checklist. It takes 30 seconds with curl -I:

curl -I https://example.com/sitemap.xml

If it returns anything other than a 200 OK with application/xml or text/xml, fix the route before running outreach or paid campaigns.

1. Third-party script bloat killing mobile CPU

The desktop version looked fast. The mobile experience was a mess.

When we opened DevTools Performance on our test phones, the main thread was blocked for 2.5 seconds. Why?

Three separate analytics trackers running simultaneously.

An interactive booking widget loading before user interaction.

A live chat widget injecting an entire iframe plus 400KB of React bundle.

Four weights of Google Fonts imported via CSS @import instead of preloaded tags.

None of these third-party scripts were deferred or lazy loaded.

The quick remedy:

Move chat widgets and heavy scheduling modals behind a lightweight button facade. Only load the third-party script when the visitor actually clicks "Chat with us" or scrolls past 50% of the page.

Replace multiple analytics scripts with a single tag manager, or switch to lightweight, privacy-focused options.

Self-host your web fonts and subset them to only the glyphs you need.

Summary

Building a beautiful website is only half the job. If the site ships 8MB hero photos, empty HTML shells, broken sitemaps, and unoptimized scripts, search crawlers and mobile users will bounce.

We run these checks continuously for client builds at https://mediastrategylab.com and in our free teardowns at https://mediastrategylab.com/free-audit. Catching these five basics before launch puts any local business site ahead of 80% of its competitors in the same zip code.

What technical mistakes do you see most often when taking over legacy client codebases?