DEV Community: Joshua Gutierrez

State of Small Business Websites (2026 Study). 96.9% Fail Core Web Vitals.

Joshua Gutierrez — Fri, 24 Apr 2026 17:13:34 +0000

Every performance article on Dev.to quotes the same two stats. You know them. Amazon. Walmart. The 100ms one. Everyone has seen them.

Nobody measures what their own prospect list looks like. We did. 292 real B2B websites ran through a headless Chromium audit in April 2026. The results are not academic.

96.9% fail at least one Core Web Vital on mobile. Only 3.1% pass all three. 100% of 191 sites with valid accessibility data failed the axe-core Link Labels rule. The full dataset is open. The methodology is reproducible. This post walks through the technical failures one by one with the fixes.

Report: axiondeepdigital.com/research/state-of-small-business-websites-2026

Key stats (copy-paste friendly)

Metric	Sample	Result
Fail at least one Core Web Vital (mobile)	n=191	96.9%
Pass all three Core Web Vitals (mobile)	n=191	3.1%
Fail axe-core Link Labels rule	n=191	100%
Post "poor" mobile LCP (>4.0s)	n=191	86.4%
Post "poor" mobile FCP (>3.0s)	n=191	72.4%
Pass mobile CLS (<0.1)	n=191	85.5%
Total domains scanned	n=292	—

Source: State of Small Business Websites 2026, Axion Deep Digital Research. April 2026.

How we measured

This study runs on our production audit infrastructure. DeepAudit AI is the same pipeline we run against client sites daily. The dataset below is 292 consecutive scans pulled from a single week in April 2026. Because the pipeline runs continuously, future snapshots will replicate this analysis against a larger and eventually randomized sample, and the methodology stays frozen so the comparisons hold.

Each scan runs a real Chromium instance inside a Lambda (Puppeteer plus @sparticuz/chromium), renders the page the way Googlebot would, waits for hydration, and then measures against:

Lighthouse mobile Core Web Vitals (LCP, FCP, CLS) using Google's published thresholds
axe-core accessibility evaluations
60+ technical SEO checks (meta, headings, schema, canonicals, alt text)
Open PageRank for domain authority

191 of the 292 sites returned valid Lighthouse mobile data. 191 returned valid axe-core data. 260 had valid Open PageRank. Every finding below is gated on the subset of sites where the relevant measurement succeeded, not averaged over missing data.

What this study does and does not prove

Before the numbers, the honest scope:

This is a purposive sample, not a random one. The 292 domains came from a North American B2B prospect list, which skews toward construction, trades, and small professional services. It is not representative of the web as a whole.
What it does represent is the category of business that small digital agencies actually get hired to fix. If you pitch to this market, the sites you convert will look like this sample.
One snapshot per site. Results reflect the state of each site on the day it was scanned.
Lighthouse mobile scores vary. Google's Lighthouse CI documentation acknowledges a ±5 point variance across runs. None of the findings below hinge on a difference smaller than that. The 96.9% failure rate and the 100% Link Labels failure are robust to that noise.

The full dataset is open. Every row, every score, every axe-core violation is downloadable from the methodology page. If you disagree with a finding, you can reproduce it or refute it.

Finding 1: LCP is the silent killer

86.4% of sites post poor mobile LCP. Only 5.2% are good.

Largest Contentful Paint over 4.0 seconds is Google's "poor" threshold. Most of the sites we measured clock in between 4 and 8 seconds on mobile. Some over 10.

What is causing it, in order of frequency:

1. Hero images served as full-resolution PNG

One site we looked at ships a 2400x1600 PNG as its hero, served at 3.2 MB. Mobile user on 4G? That is 6 seconds of transfer on a good connection. The image renders last, so LCP measures the whole download.

The fix is trivial if you are on Next.js:

import Image from 'next/image';

<Image
  src="/hero.jpg"
  alt="..."
  width={1200}
  height={600}
  priority
  sizes="(max-width: 768px) 100vw, 1200px"
  quality={75}
/>

priority injects a preload hint. sizes tells the browser to pick the right srcset variant for the viewport. quality=75 on JPEG looks identical to 90 in blind testing. Next.js serves WebP or AVIF automatically based on the Accept header.

If you are not on Next.js, the same rules apply. <link rel="preload" as="image">, <picture> with AVIF first, and a srcset + sizes combo.

2. Render-blocking JavaScript in the head

Tag Manager. Hotjar. Intercom. Drift. One of every four sites we audited had three or more synchronous third-party scripts in the head. Each one blocks HTML parsing until it is fetched, parsed, and executed.

The defer attribute is older than most React developers. Use it:

<script src="/vendor/gtm.js" defer></script>

Or on Next.js:

import Script from 'next/script';

<Script src="https://www.googletagmanager.com/gtm.js" strategy="afterInteractive" />
<Script src="https://widget.intercom.io/widget.js" strategy="lazyOnload" />

afterInteractive loads after hydration. lazyOnload waits until the browser is idle. Neither blocks the LCP element.

3. Custom fonts with no `font-display` directive

Default font-loading behavior blocks text rendering for up to 3 seconds. If your LCP element contains text, it cannot paint until the font loads.

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
}

swap tells the browser to render with a system fallback immediately, then swap to the custom font once it arrives. On Next.js, next/font does this automatically. On anything else, you write it in three lines.

Finding 2: First Contentful Paint is worse than LCP, and nobody talks about it

72.4% of sites post poor mobile FCP.

FCP is the time to the first pixel of anything meaningful. It is the metric that correlates most directly with user perception of speed. If it takes 4 seconds to paint a single headline, the user has already decided the site is broken, regardless of how fast the rest of the page loads.

The causes overlap with LCP but there is one specific pattern we saw repeatedly: a client-side routing framework rehydrating the whole page before rendering anything.

Here is the anti-pattern. A site ships a React SPA that serves an empty shell HTML, boots up, fetches the route data, then renders. The browser sees nothing visible until JavaScript finishes executing. The fix is either:

Server-side render the first paint (Next.js App Router, Remix, SvelteKit, pick one)
Ship static HTML for the first paint, hydrate on demand (Astro model)

If you are shipping a React SPA as the entire site in 2026, you are fighting gravity. The frameworks that win on FCP are the ones that put real HTML on the first GET.

Finding 3: 100% of sites failed Link Labels

This is the number that should bother you most.

axe-core's Link Labels rule checks that every <a> element has a discernible accessible name. Every single one of the 191 sites we evaluated had at least one link that failed this rule. Every one.

What does a failing link look like? It looks like this:

<a href="/products">
  <svg>...</svg>
</a>

A screen reader reads "link" and stops. There is no text content and no aria-label. The user has no idea where the link goes.

The fix is one attribute:

<a href="/products" aria-label="Our products">
  <svg aria-hidden="true">...</svg>
</a>

Social icon sets are the most common offender. Every Twitter, LinkedIn, and Instagram icon in every footer. Almost every one of them was an unlabeled link. Across 191 sites, we did not find a single site that had labeled every one of its icon-only links.

This is not an edge case. This is the baseline.

The broader pattern is: developers ship component library icons without reading the a11y docs. React-icons, Font Awesome, Lucide, Heroicons. All of them render SVGs inside anchors by default, and unless you explicitly add an aria-label or sibling text, the resulting link is unreadable.

If you ship a component with an icon-only link, wrap it:

export function SocialLink({ href, label, children }) {
  return (
    <a href={href} aria-label={label}>
      <span aria-hidden="true">{children}</span>
    </a>
  );
}

Three lines. You now pass axe-core.

Finding 4: CLS is the one metric most sites get right

85.5% of sites pass mobile CLS.

Cumulative Layout Shift is the one Core Web Vital developers have actually internalized. It helps that every modern framework bakes in width and height on images by default, and that font-display: swap cuts down on font-swap shifts. The sites that fail CLS are doing something unusual: late-loading ads, position: sticky headers without reserving space, or hero carousels that resize after the first slide loads.

If your site passes everything else but fails CLS, the cause is almost always one of those three.

The takeaways for developers

If you read nothing else from this, read this:

Priority-load one image and one font. Your LCP element and your primary typeface. Everything else lazy-loads. This single change moves most sites from "poor" LCP to "good."
Defer or lazy-load every third-party script. If Tag Manager is synchronous in your <head>, you are paying for it on every paint. Move it.
Run axe-core on every PR. A CI check that runs @axe-core/cli against your built site will catch unlabeled links before they ship. It takes 10 minutes to configure and it will save you from the baseline failure.
Test on mobile, not desktop. Every site we audited looked fine on desktop. 96.9% of them fail on mobile. Chrome DevTools has a "Mobile" preset in the Performance tab. Use it on every build.

The dataset

The full 292-site dataset, methodology, and reproducibility notes are open. If you want to cite any of these findings in a post, article, or conference talk, you can pull the raw scan JSON and reproduce every chart.

Report: State of Small Business Websites 2026

Suggested citation:

Gutierrez, J.R. (2026). State of Small Business Websites 2026.
Axion Deep Digital Research, n=292.
axiondeepdigital.com/research/state-of-small-business-websites-2026

If you find an error, contact us and we will update the public methodology page with the correction and the reporter credit.

The takeaway, in one sentence

The small business web is not sophisticated enough to be slow. It is slow because nothing is prioritized, nothing is deferred, and nothing is labeled. Every one of the findings above is fixable in a single afternoon by a developer who knows the four keywords: priority, defer, font-display: swap, and aria-label.

That is what the 3.1% do.

Your Website Exists. AI Doesn't Know That.

Joshua Gutierrez — Fri, 10 Apr 2026 00:02:55 +0000

Someone just asked ChatGPT for a recommendation in your industry.

Your competitor was in the answer. You weren't.

Not because they're better. Because the AI knew what they do. It didn't know what you do.

That gap is growing every day. And it has a very simple fix.

The Problem No One Is Talking About

Google crawls your site. It reads your HTML, follows your links, indexes your pages. That system is 25 years old and it works.

AI assistants don't do that.

When Perplexity, ChatGPT, or Claude constructs an answer, it pulls from whatever structured context it can find. If your site is a JavaScript-heavy single-page app with no clear text about what you offer, where you operate, or what you charge -- the AI has nothing. It skips you. Or worse, it gets your details wrong and recommends someone else.

This is not theoretical.
It is happening right now.
Across every industry.

The Fix: One File, 10 Minutes

The solution is called llms.txt.

Think of it as robots.txt for AI. Where robots.txt tells search crawlers what to index, llms.txt tells AI assistants how to understand and recommend your business.

It's a plain Markdown file at the root of your domain. No plugins. No API. No special server config. Just text that tells AI exactly who you are.

The standard defines two files:

llms.txt is the summary. Your name, what you do, key links. Think elevator pitch in plain text.

llms-full.txt is the deep reference. Every service, pricing, process, FAQs, team, locations, and URLs. Everything an AI needs to answer any question about your business without visiting another page.

What Goes In Each File

Here's exactly what the AI needs to see. Miss any of this, and you're invisible again.

llms.txt -- Keep It Tight

# Your Business Name

> What you do, in one sentence.

- Full details: https://yourdomain.com/llms-full.txt

## Services

- **Service 1**: What it is. What makes it different.
- **Service 2**: What it is. What makes it different.

## Free Tools

- **Tool Name**: What it does. Direct URL.

## Areas Served

- City, State (headquarters)
- City, State

## Contact

- Website: https://yourdomain.com
- Email: hello@yourdomain.com

No HTML. No JavaScript. No images. Pure Markdown.

llms-full.txt -- Go Deep

This is where specificity wins. For each service, include what's included, how the process works, pricing ranges, timelines, and FAQs with real answers. For each location, include the city page URL, population, and key industries. For your team, include names, roles, and credentials.

The goal: an AI reading this file should be able to answer any question a potential customer would ask. Without visiting your site.

The single biggest mistake people make is being vague. "We offer digital solutions" tells an AI nothing. "Custom web development with React and Next.js. 95+ Lighthouse scores. Starting at $2,500." gets quoted verbatim.

Implementation

Next.js / Static Sites

Drop both files in /public:

public/
  llms.txt
  llms-full.txt
  robots.txt

Served automatically. Done.

WordPress

Upload to your root directory via FTP. Or use any plugin that serves static files from document root.

Optional: Reference in robots.txt

Sitemap: https://yourdomain.com/sitemap.xml
Llms: https://yourdomain.com/llms.txt

Not part of the formal spec yet. But it makes the file more discoverable.

Three Mistakes That KillThe Problem No One Is Talking About Your AI Visibility

Writing marketing copy instead of facts. AI assistants ignore superlatives. "Award-winning" and "industry-leading" get filtered out. Specific numbers and concrete descriptions get quoted. Write like you're filling out a form, not a brochure.

Skipping the full version. llms.txt alone is a business card. Without llms-full.txt, the AI fills in the blanks with guesses -- or with your competitor's details. The full file is where the real value lives.

Forgetting to update it. New service? New city page? Changed pricing? Both files need to reflect current state. Stale information is worse than no information, because the AI will confidently repeat it.

How to Know It's Working

Visit yourdomain.com/llms.txt in your browser. If you see plain text, it's live.

Then test it. Ask ChatGPT or Perplexity about your business. Ask about your services, your pricing, your locations. If the AI references details from your llms.txt, it's beiYour account may not be allowed to perform this action. Please refresh the page and try again.ng consumed.

This is new enough that the feedback loop is fast. Add the file today, and AI assistants can reference it within days.

The Bigger Picture

llms.txt is one piece of a broader shift. AI discoverability is becoming as important as search engine optimization was 10 years ago.

Structured data (JSON-LD) on every page tells Google's AI Overviews about your services and FAQs. City-specific landing pages let AI assistants answer location queries. FAQ schema gives AI direct question-answer pairs to pull from. Clean semantic HTML gives crawlers content they can parse without rendering JavaScript.

The businesses that build for AI discoverability now will own the answers for the next 2-3 years. The ones that wait will wonder why they keep getting skipped.

The file takes 10 minutes to write. The cost of not having it compounds every day.

Written by Joshua R. Gutierrez in collaboration with the engineering team at Axion Deep Digital. We build high-performance websites, rank them on Google, and make sure AI knows they exist.

Right now, AI is recommending someone else. Find out if you're even in the conversation. 60 seconds. No signup.

Try DeepAudit AI | SEO Scanning Tool for Free (No Signup Required):

What a 98 Lighthouse Score Actually Takes

Joshua Gutierrez — Tue, 31 Mar 2026 21:41:06 +0000

Everybody talks about Lighthouse scores, but almost nobody actually has a high one.

Across the sites we have audited at Axion Deep Digital, the average score is 44 out of 100. Not a typo. And these are not abandoned websites. These are real businesses actively spending on ads, running campaigns, and trying to grow.

The problem is that most people treat performance like a nice to have. It is not. Google uses Core Web Vitals as a ranking signal, and users feel performance immediately. A slow site does not just rank lower, it converts worse. You end up paying for traffic that leaves before it even engages.

We rebuilt our own site with one clear goal. Reach a 98 plus Lighthouse score across all categories on mobile, under real world conditions. Not on a fast laptop, but on a throttled connection the way Google actually tests it.

Here is what that actually required.

The biggest shift starts with how your site is built. Your framework sets your ceiling. If your stack is heavy or overly dynamic, you are working against yourself from the beginning. We use static generation so pages are pre rendered and delivered instantly. That removes a huge amount of overhead before optimization even begins.

From there, images are almost always the largest issue. On most sites, they make up the majority of page weight. It is common to see oversized, uncompressed assets that slow everything down. We convert everything to modern formats, resize images to their actual display size, and lazy load anything below the fold. Small changes here can dramatically reduce load time.

Fonts are another silent performance killer. Many sites load fonts from external providers with multiple round trips before text even appears. We self host, reduce font sizes, and ensure text renders immediately. That alone can shave seconds off perceived load time.

JavaScript is where things really add up. Every piece of it has to be downloaded, parsed, and executed. Most sites are carrying far more than they need. We aggressively remove unused code, split what remains, and defer anything that is not critical. The result is a much lighter, faster experience.

CSS also plays a role in how quickly a page becomes visible. Instead of forcing the browser to wait for a full stylesheet, we inline only what is needed for the initial view and load the rest afterward. That allows the page to render immediately.

All of this feeds into the metrics that actually matter. Core Web Vitals are not abstract scores. They directly measure how fast your content appears, how stable the layout is, and how responsive the page feels. Getting those right requires coordination across everything above.

Even with a well built frontend, server configuration still matters. Compression, caching, and proper headers all contribute to how efficiently your site is delivered. Many sites overlook this completely.

Accessibility is another area that is often ignored, even though it overlaps heavily with both usability and SEO. Simple things like proper headings, alt text, and labeled inputs make a measurable difference.

When you put it all together, the work is not about chasing a score. It is about building a site that loads quickly, behaves predictably, and works for real users in real conditions.

That is also why most testing is misleading. If you are checking your site on fast WiFi on a new device, you are not seeing what your customers see. The real test is a slower device on a weaker connection.

We built DeepAudit AI to evaluate sites the way Google does. It runs your site in a real browser and analyzes what actually renders, not just the source code.

It is free, takes about a minute, and gives you a clear picture of what is holding your site back.

If you want to see where your site really stands, you can run it here
axiondeepdigital.com/free-seo-audit

One Button Too Many

Joshua Gutierrez — Wed, 25 Mar 2026 10:39:13 +0000

We had five OAuth login options on our sign in page.

Google. GitHub. LinkedIn. X. Facebook.

It looked complete. It felt right. More options, more flexibility.

Then one night around 11pm, we were staring at logs trying to figure out why our X integration kept connecting the wrong account.

That is when things got interesting.

What We Build

We are building Made4Founders, a business platform for startup founders.

One of the features is social posting. You connect your X account, write a post in the dashboard, and it publishes for you.

Simple idea. Should be straightforward.

We also let users sign in with X.

At the time, it felt obvious. If we support X, we should support logging in with it too.

What Went Wrong

Here is the problem.

A user signs in using their personal X account. That is the account already active in their browser.

Later, they go to connect their company account for posting.

But X does not give you an account picker. It does not ask which account you want. It just grabs whatever session is active.

So it silently reconnects the personal account.

The user thinks they connected their business account. They write a company update, hit post, and it goes to their personal feed.

Not ideal.

The “Fixes” That Did Not Work

We tried to patch it.

We added a hint telling users to switch accounts on X first.

It did not help.

Even after switching inside X, OAuth still defaulted to the primary session.

The only workaround was telling users to:

Open an incognito window
Log into their business account only
Come back and connect

We actually wrote that into a tooltip.

Then we looked at it and realized how ridiculous that was.

The Question We Should Have Asked Earlier

We stopped debugging and checked our data.

How many users had actually signed up using “Sign in with X”?

Zero.

Not low. Zero.

Every user used Google or email. A few used GitHub or LinkedIn.

Nobody used X.

So we had been maintaining:

OAuth flows
Token refresh logic
API credentials
Debugging time

For a feature nobody used.

The Fix Took 10 Minutes

We deleted the button.

Removed the frontend component. Cleaned up the API call.

About 20 to 30 lines of code.

Then we separated our X apps:

One app for login (now disabled)
One app for posting

Same pattern we already used for LinkedIn.

Immediately, everything worked.

Four login options. No conflicts. Posting works as expected.

What We Actually Learned

This was not really about X.

It was about a common engineering habit.

Adding things because we can, not because they are needed.

Each OAuth provider feels cheap to add.

Just another button. Another callback. Another env variable.

But they are not free.

Each one adds:

Token flows that can break
Credentials that expire
APIs that change
Edge cases you do not control

And sometimes, they conflict with other features.

The Real Cost of “Just One More Option”

We spent hours debugging X.

Token issues
Session conflicts
API limitations
OAuth redirect loops

X has also become harder to work with:

Pay per use pricing
Limited free tier
Hidden requirements in the developer console

All of that for a login button nobody clicked.

The Broader Point

Every feature has a maintenance cost.

Not just code.

Debugging time
Support tickets
Mental overhead
Edge cases

OAuth is especially messy.

Every provider behaves differently:

Google gives an account picker
LinkedIn requires separate apps
Facebook has business requirements
X uses whatever session is active

There is no standard. Only variations.

Our Rule Now

Before adding a login option, we ask one question:

Would our target user actually sign up this way?

For founders using a business tool:

Google and email cover almost everything
GitHub works for technical users
LinkedIn makes sense

X and Facebook do not.

If the answer is no, we do not add it.

If You Are Building Something Similar

A few things we learned the hard way.

1. Do not mix login and integration OAuth

Session conflicts are real and you cannot control them.

2. Separate your developer apps

Authentication and integrations should not share the same setup.

3. Test with multiple accounts

Most bugs only appear in real world usage patterns.

4. Remove what is not earning its place

It feels wrong, but it is often the right move.

The Result

Four login buttons.

No conflicts.

No late night debugging sessions over something nobody uses.

Sometimes the best feature you can ship is a deletion.

Closing

We are building Made4Founders.

One dashboard to replace a stack of disconnected tools for startup founders.

If you are building in this space, you already know how messy it gets.

We are trying to make it simpler.

# I Audited 61 Business Websites With AI. Here’s What Broke on Almost Every Single One.

Joshua Gutierrez — Mon, 23 Mar 2026 23:01:13 +0000

I run a small engineering shop. We build websites, handle technical SEO, and set up lead capture systems for businesses that want their site to actually do something, not just sit there.

A few months ago we built an internal tool called DeepAudit AI. It uses a real headless browser to crawl a site and score it across more than 60 checks. Technical SEO. Content. Performance. Accessibility. Security. Structured data.

Not basic HTML scraping. It renders the page the same way Google does.

At first we used it to prep for sales calls. Run the audit, find the weak points, have a real conversation instead of guessing. But after running it on 61 business websites back to back, the same problems kept showing up.

So I wrote them down.

These were not random personal projects. These were established businesses. Agencies. SaaS companies. Consultants. Real revenue, real clients. The kind of teams that should not be missing the basics.

Here is what we found.

The Numbers

Out of 61 websites:

Average score: 71 out of 100. Barely passing.
Only 1 in 5 scored 80 or higher.
Nearly a third were below 70.
The lowest score was 21. That site had no title tag, no meta description, no viewport tag, no charset, and no H1. It was basically invisible.
The highest was 88. Good, but still not clean.

The median was 73. So if your site feels average, it is still failing about a third of what actually matters.

The 7 Most Common Problems

These are ranked by how often they showed up as top issues across all audits. This is not edge case stuff. This is what most sites are doing wrong.

1. HTML Validation Errors (43%)

This was the most common issue by far.

Unclosed tags. Duplicate IDs. Deprecated attributes. Broken markup. One site had more than 60 errors on a single page.

Most developers never validate after launch. If it looks fine in Chrome, it ships. But crawlers do not behave like browsers. They read your markup literally. If your HTML is broken, parts of your content might not even exist to them.

2. Missing or Broken H1 (40%)

The H1 tells Google what the page is about. It is one of the most basic signals you can send.

Four out of ten sites either had no H1, had multiple competing H1s, or used something vague like “Welcome.”

Your homepage should have one clear H1 that explains exactly what you do. Not clever. Not abstract. Clear.

3. Accessibility and Form Issues (26%)

This one stood out.

More than a quarter of sites had form fields with no labels. That means screen readers cannot tell users what to enter.

Beyond usability, this is a compliance risk.

Looking deeper, the average accessibility score across all sites was under 50. Missing focus states. Links with no readable text. Poor contrast everywhere.

If you work with enterprise clients, this matters more than most people realize. Procurement teams are starting to check for this before signing anything.

4. No Sitemap.xml (23%)

Almost a quarter of sites had no sitemap.

A sitemap is just a list of your pages for search engines. It tells them what exists and what has changed.

Without it, Google has to guess by following links. That means some pages never get indexed.

If you are on WordPress, this is automatic. If you are on a custom setup, it takes maybe 15 minutes to create.

5. Missing Meta Description (21%)

One in five sites had no meta description.

That means Google is pulling random text from the page to display in search results.

This is your chance to control how your site shows up. It is the short block of text that decides whether someone clicks your link or skips it.

Keep it under 155 characters. Say what you do. Give a reason to click.

6. No Structured Data (19%)

Structured data tells search engines what your business actually is.

Name. Services. Location. Reviews. Hours.

Without it, you miss out on enhanced search results like star ratings and rich listings.

Almost 1 in 5 sites had none at all. Adding basic schema takes minutes and immediately improves how your site appears in search.

7. Broken Internal Links (17%)

Nearly 1 in 5 sites had links pointing to pages that no longer exist.

Every broken link is a dead end. Users hit it. Crawlers hit it. Both stop.

One of the worst cases we saw was a JavaScript error leaking into the HTML and generating links to something that was not even a real URL. The site was literally creating broken paths on its own.

The Pattern Nobody Talks About

These problems do not show up alone. They stack.

A site missing meta descriptions is usually missing Open Graph tags too. A site with no H1 often has no structured data. A site with broken HTML usually has accessibility issues and bad links on top of it.

The lowest scoring sites were not failing one thing. They were failing everything.

Nobody had ever done a real technical audit. The site looked fine, so everyone assumed it was fine.

The higher scoring sites were different. Not perfect, but clearly maintained. Someone had actually looked under the hood.

What This Means for Your Business

If your website has never gone through a real technical audit, not a design review, not a marketing check, but an actual engineering level audit, there is a good chance you are losing traffic and leads without realizing it.

The fixes themselves are not hard.

Writing a meta description takes seconds. Adding structured data takes minutes. Fixing an H1 is one line.

The hard part is knowing what is broken.

That is why we made DeepAudit AI free. No signup. No call. Just paste your URL and get a full report in about a minute.

👉 https://axiondeepdigital.com/free-seo-audit

You might be sitting at an 88. You might be at a 21.

Either way, you should know.

Joshua R. Gutierrez, M.S.

CEO, Axion Deep Labs

Founder, Axion Deep Digital

We Built 3 Websites. None of Them Ranked.

Joshua Gutierrez — Fri, 20 Mar 2026 17:08:53 +0000

We launched three products this year at Axion Deep Labs. Three websites. All built on Next.js, all statically exported, all "optimized for SEO." Except they weren't. Not even close. Here's every real mistake we made and how we found out the hard way.

1. Our Entire Website Was Invisible to Google

This one still hurts.

Next.js has a file called loading.tsx. Drop it in your app directory and it shows a loading spinner while the page hydrates. Great for UX. Terrible for SEO.

That file creates a Suspense boundary around ALL page content in the static HTML export. When Google's crawler hit our site, it didn't see our homepage, our service pages, or our blog posts. It saw a loading spinner. On every single page.

We spent days fixing heading hierarchy, anchor text, meta descriptions. None of it mattered. The crawler was looking at an empty page the whole time. The fix was deleting one file.

Lesson: Don't trust your source code for SEO. Run the build, open the actual HTML output, and look at what the crawler sees. We wrote a script that counts words and checks for spinners in our built files now.

2. Google Analytics Said Our Tag Was Working. It Wasn't.

Google has a tag verification tool. You click "Test my website," get a green checkmark, and move on. We got the green checkmark. Two weeks later: zero data. Not low traffic. Zero.

The problem was Google Consent Mode v2. We'd implemented a cookie consent banner that defaulted analytics_storage to "denied" and only switched to "granted" when someone clicked "Accept." Most people don't click cookie banners. They ignore them.

Google's tag test checks if the script is present in the HTML. It doesn't check if consent mode is blocking data collection. Green checkmark. Zero data. Weeks of analytics, gone.

Lesson: If you're a US company, you probably don't need opt-in consent for analytics. Default to granted, make the banner an opt-out. And check your Realtime report after deploying, don't just trust the tag test.

3. We Had Five H1 Tags on One Page

Our homepage had a server-rendered article with an H1. A client component with another H1. Service cards with H1s inside them. Google doesn't know which one matters when there are five, so it kind of shrugs.

We also had H4 tags in the footer that appeared in the DOM before the H1. Heading hierarchy was completely broken. We didn't notice because visually it looked fine.

Lesson: One H1 per page. Everything else is H2 or lower. The H1 has to be the first heading in the DOM, not just the first one visible on screen.

4. Every Link on Our Site Said "Learn More"

Twelve service cards. Every single one had a "Learn more" link. Identical anchor text, twelve times, pointing to twelve different pages.

Google uses anchor text to understand what the linked page is about. When every anchor says "Learn more," you're telling Google twelve different pages are about nothing specific.

We replaced them with descriptive anchors. "Explore our SEO services." "See our web development process." "Learn how lead capture works." Took 20 minutes.

Lesson: Every link on your page should have unique, descriptive anchor text. If you can't tell what the target page is about from the anchor text alone, rewrite it.

5. Client Components Killed Our Server-Rendered Content

Next.js server components render to HTML on the server. Client components need JavaScript to render, which means crawlers might not see them.

We had components using usePathname() from Next.js. That single hook forces the entire component to become a client component. Our content shell and footer were client components for no good reason. Just to highlight the current nav item.

We refactored them to server components, moved the pathname logic to a tiny client child, and suddenly our static HTML had actual content instead of empty divs waiting for hydration.

Lesson: If you're using Next.js, grep your components for "use client" and ask if each one truly needs to be client-side. One misplaced hook can make an entire page invisible to crawlers.

6. Our Privacy Page Had the Wrong Analytics ID

We switched Google Analytics properties and updated the tag in our layout. But our privacy policy still had the old measurement ID hardcoded in the text. Anyone trying to verify what we track would have seen a different ID than what was actually running.

Not an SEO issue technically. But it's a trust issue. And trust issues become bounce rate issues.

7. Our Sitemap Had Wrong Dates

Our sitemap.xml was generated at build time using new Date() in JavaScript. The build ran on a CI server with a slightly off clock. Our sitemap was telling Google that pages were last modified at times that didn't match reality. We hardcoded the dates.

8. 78 Images With Zero Metadata

Every image was optimized for file size and format. WebP, compressed, proper dimensions. But none had IPTC or XMP metadata. No titles, no descriptions, no keywords, no copyright.

Google Image Search uses this metadata for indexing. Social platforms use it as fallback when sharing. It's also how you prove ownership if someone takes your images.

We wrote exiftool scripts to tag every image with contextual titles, descriptions, keywords, author, copyright, and source URLs. 78 images. Took an hour.

9. Our Old Brand Name Was Still in Five Places

We built from a template and rebranded everything. Or so we thought. Five places still had the old brand name. Two had the old email. The hero section still had template copy. All buried in secondary pages, JSON-LD schema, and error states that we never checked.

Lesson: Find and replace across your entire codebase after a rebrand. Then do it again.

The 4 Things That Actually Matter

After months of fixing SEO across three sites, it comes down to this:

Crawlability

Can Google actually see your content? Suspense boundaries, client rendering, and JavaScript dependencies can make your pages invisible.

Rendered Content

What does the built HTML look like? Not your source code. The actual output. Check it.

Data Accuracy

Is your analytics collecting? Are your sitemaps correct? Are your meta tags matching reality? If your data is wrong, every decision you make from it is wrong.

Structure

One H1. Descriptive anchors. Proper heading hierarchy. Image metadata. These are boring. They also compound over every page on your site.

Get these right first. Then worry about keyword strategy and backlinks.

We got a 98 Lighthouse score on one of our sites and it generated zero leads. Performance is necessary but not sufficient. The basics have to work.

Most of these issues are invisible unless you know where to look.

We built a free tool that checks 60+ of them in seconds.

Try DeepAudit AI Free →

We Built a Free AI SEO Audit Tool — Here's What We Learned Scanning 500+ Sites

Joshua Gutierrez — Mon, 16 Mar 2026 21:12:54 +0000

We're Axion Deep Digital, a web development and SEO agency. Six months ago we built DeepAudit AI — a free tool that renders pages in a real Chromium browser, runs 60+ SEO checks, and uses AI to rewrite your meta tags.

Since launch, hundreds of sites have been scanned through it. Here's what we found — and what we built to fix it.

Why We Built It

Every free SEO tool we tried did the same thing: parse raw HTML, give a vague score, and upsell a $99/month plan.

The problems:

They don't render JavaScript, so they miss content on React/Next.js/Vue sites
They check 10-15 surface-level things and call it an "audit"
They tell you what's wrong but never how to fix it

We wanted a tool that works the way Google actually crawls — real browser rendering, real Lighthouse scores, and actual fix snippets you can copy-paste.

What We Found Scanning 500+ Sites

78% have broken or missing meta descriptions

The most common issue. Either the meta description is missing entirely, or it's a generic CMS default like "Just another WordPress site." AI rewrites these in seconds.

65% fail basic accessibility checks

Missing alt text, no skip navigation, poor color contrast, unlabeled form inputs. These aren't just compliance issues — Google factors accessibility into rankings.

71% have no structured data

No Schema.org markup at all. No FAQ schema, no LocalBusiness, no breadcrumbs. This is free real estate in search results that almost nobody claims.

Average Lighthouse performance score: 44

The average small business site scores below 50 on Lighthouse performance. Unoptimized images, no lazy loading, render-blocking scripts. Most don't even know their score.

83% missing at least one security header

HSTS, CSP, X-Frame-Options — most sites ship with none of these. Search engines increasingly factor security signals into trust.

Only 12% have proper internal linking

Orphan pages, broken links, no logical hierarchy. Crawlers can't find what isn't linked.

The Tech Stack

For anyone curious about how we built it:

Frontend: Next.js 16, Tailwind CSS, Framer Motion
Audit Engine: AWS Lambda with Puppeteer (real Chromium rendering)
AI Layer: DeepSeek for meta tag rewrites and action plan generation
Performance Data: Google PageSpeed Insights API
Security Checks: Mozilla Observatory methodology
Report Generation: Puppeteer PDF export, stored in S3 with presigned URLs

The Lambda function spins up a headless Chromium instance, navigates to the target URL, waits for JavaScript to execute, then extracts everything — DOM structure, meta tags, headings, images, links, structured data, security headers, and more.

All 60+ checks are deterministic. AI only comes in at the end to analyze results and generate the rewrite suggestions and action plan.

The 7 Categories We Score

Each site gets a weighted score across:

Technical SEO — HTTPS, canonical URLs, robots.txt, sitemap, structured data
Content & Keywords — word count, keyword density, heading hierarchy, readability
Performance — Lighthouse scores, Core Web Vitals, image optimization
On-Page SEO — title tag, meta description, alt text, internal/external links, Open Graph
Accessibility — contrast, form labels, ARIA landmarks, focus indicators
Security — HSTS, CSP, X-Frame-Options, referrer policy
Site Health — multi-page crawl, broken links, redirect chains

Final score: 0-100 with a letter grade.

What Makes It Different

Real browser rendering. Most tools fetch raw HTML with a simple HTTP request. We spin up Chromium. If your site uses React, Next.js, or any client-side rendering, we actually see your content.

Copy-paste fixes. Every failing check includes the exact HTML, CSS, or server config snippet to fix it. Not "improve your meta description" — the actual rewritten tag you can paste into your <head>.

AI-generated action plan. After all checks run, AI reads every result, your Lighthouse scores, and your keyword data, then generates a prioritized list ranked by revenue impact.

Competitor comparison. Run any two sites side-by-side across all 60+ checks.

No signup. 3 audits per day, no account, no credit card, downloadable PDF report.

Try It

DeepAudit AI — Free AI SEO Audit Tool

Paste any URL and get a full report in under 60 seconds. If you find bugs or have feature requests, drop a comment — we're actively building.