The problem is not the number of tools. The problem is that most businesses assemble their stack randomly, adding tools one at a time as needs arise, without any coherent strategy connecting them. The result is data silos, manual workarounds, and missed opportunities that compound silently over months.

There is a better approach. When you build your digital stack intentionally, with each layer designed to feed into the next, the entire system compounds. Traffic becomes leads. Leads become customers. Customer data informs strategy. Strategy drives growth. Here is how that works in practice.

Layer 1: The Website

Your website is not a brochure. It is the hub of your digital presence, the single asset that every other channel points to. If it is slow, poorly structured, or invisible to search engines, everything downstream suffers.

A high performance website in 2026 means sub second load times, 98 plus Lighthouse scores, mobile first responsive design, and technical SEO built into the architecture from day one. Modern frameworks like React and Next.js deliver this out of the box when implemented correctly. Structured data, semantic HTML, proper heading hierarchies, and fast server response times are table stakes.

If your website does not meet these standards, that is where you start. Everything else builds on this foundation. Axion Deep Digital has written extensively about what separates a website that performs from one that just exists.

Layer 2: SEO and Organic Traffic

Paid advertising has its place, but organic traffic is the only channel that compounds without increasing spend. Every blog post, every optimized landing page, every piece of structured data markup builds long term equity in search results.

Effective SEO in 2026 goes beyond keywords. It means fast Core Web Vitals, comprehensive meta data, internal linking structures that help search engines understand your content hierarchy, and regular content that addresses the questions your target customers actually ask.

The key insight most businesses miss is that SEO is not a separate project. It is a property of a well built website. If your site architecture is clean, your content is structured properly, and your pages load quickly, you are already doing 70 percent of the work.

Layer 3: Lead Capture and CRM

Traffic without conversion is vanity metrics. You need a system that turns website visitors into contacts your sales team can follow up with, and that system needs to work automatically.

This means more than a contact form. An AI chat widget engages visitors in real time, answering questions and collecting information around the clock. Smart forms that appear at the right moment capture interest before it fades. And all of it needs to flow directly into a CRM with zero manual data entry.

Site2CRM solves this specific problem. It connects your website forms and AI chat directly to HubSpot, Salesforce, Pipedrive, or whichever CRM your team uses. No copying and pasting. No delayed follow up. Every lead is captured, enriched with source data, and ready for your team the moment it comes in.

Layer 4: Business Operations

As your business grows, the operational complexity grows with it. Compliance deadlines, financial tracking, team management, investor relations, hiring, contracts, and a hundred other things compete for your attention.

Most founders handle this by adding more tools. A separate app for each function. The smarter approach is to consolidate operations into a single dashboard that gives you visibility across every function.

Made4Founders was built specifically for this. It combines compliance tracking, financial management, cap table management, hiring, team operations, and investor reporting in one place. Not a shallow integration layer, but deep functionality in each domain, connected by a unified data model.

How the Layers Connect

The real power of an intentional digital stack is not in any single layer. It is in the connections between them.

Your website attracts visitors through SEO. Your lead capture system converts those visitors into CRM contacts with source tracking, so you know exactly which pages and keywords drove each lead. Your CRM tells your sales team who to call and when. Your business dashboard shows you the revenue that resulted, the team that delivered it, and the operational metrics that indicate whether you can scale further.

Every layer feeds the next. Data flows forward. Insights flow back. And the whole system gets smarter over time.

Getting Started

You do not need to build all four layers simultaneously. But you do need to build them in order.

Start with the website. Make it fast, make it findable, and make it convert. If you already have a website, audit it honestly. Load it on your phone over a cellular connection. Check your Core Web Vitals. Search for your business on Google and see what shows up.

Then add lead capture. Connect your forms and chat to your CRM so every visitor interaction is recorded and actionable. This is the highest leverage improvement most businesses can make because it turns existing traffic into pipeline.

Then build your operational layer. As revenue and team size grow, the need for structured operations becomes unavoidable. Getting ahead of it before you are drowning in spreadsheets is the difference between scaling smoothly and scrambling to catch up.

The businesses that thrive are not the ones with the most tools. They are the ones whose tools actually talk to each other.

Google Lighthouse is the tool that settles the debate. It is a free audit built right into Chrome that scores your website from 0 to 100 across performance, accessibility, best practices, and SEO. A score of 98 or above means your site is in the top tier of the entire internet.

Most business websites score somewhere between 40 and 70. And that gap between 70 and 98 is not just a vanity metric. It directly affects how many people stay on your site, how Google ranks you, and ultimately how many leads you generate.

Speed and Bounce Rates

Google's own research shows that as page load time increases from one second to three seconds, the probability of a visitor bouncing increases by 32%. Push that to five seconds and it jumps to 90%.

Think about what that means in practice. If your site takes 3.5 seconds to load and you are getting 1,000 visitors per month, roughly 320 of them are leaving before they ever see your content. They never read your headline, never see your services, never encounter your chat widget or contact form. They are gone.

A site that loads in under one second keeps almost all of those visitors on the page. Same traffic, dramatically different results.

The SEO Connection

Google has been using page speed as a ranking factor since 2010, and they made it even more important with Core Web Vitals in 2021. Your Lighthouse score directly maps to the metrics Google uses to rank you:

Largest Contentful Paint measures how quickly your main content appears. Interaction to Next Paint measures how responsive your site feels when someone clicks something. Cumulative Layout Shift measures whether the page jumps around while loading.

Sites that score well on all three get a measurable boost in search rankings. We have seen clients move from page two to page one of Google results after improving their Lighthouse score from the 60s to the mid 90s. No content changes, no new backlinks. Just making the site faster.

What Goes Wrong on Most Sites

When we audit business websites, the same problems show up over and over.

Uncompressed images are the number one culprit. A single hero image saved as a 2MB PNG instead of a 200KB WebP can add two full seconds to your load time. Every image on every page needs to be properly compressed and served in modern formats.

Too many third party scripts are the second biggest issue. Analytics tags, chat widgets, social media embeds, font loaders, retargeting pixels. Each one adds weight and blocks the browser from rendering your actual content. Most businesses are running six to ten third party scripts and half of them are not even being used anymore.

Render blocking resources are the third. Large CSS files and synchronous JavaScript that have to fully download before the browser can paint anything on screen. Modern build tools handle this automatically through code splitting and lazy loading, but sites built five years ago rarely have these optimizations.

What We Do Differently

When we build a website at Axion Deep Digital, performance is not an afterthought. It is baked into every technical decision from the start.

We use React with Next.js and Tailwind CSS because these tools produce lean, optimized output by default. Code splitting happens automatically. CSS is generated on demand instead of shipping a massive stylesheet. Images are automatically converted to WebP and served at the right size for each device.

Every site we deliver scores 98 or above on Lighthouse. Not 80. Not 90. Ninety eight. That is the standard because that is what the data says matters.

We pair that fast foundation with built in SEO, real time lead capture, and AI chat integration. Speed gets visitors to your site and keeps them there. The rest converts them into leads. It all works together as a single system.

Checking Your Own Score

Open Chrome, navigate to your website, and press F12 to open Developer Tools. Click the Lighthouse tab, select "Mobile" (because that is what Google uses for rankings), and click "Analyze page load."

If your score is under 60, your site is actively hurting your search rankings and driving away visitors. Between 60 and 80, there is significant room for improvement. Between 80 and 90, you are doing okay but leaving performance on the table. Above 95, you are in great shape.

Most business websites we audit for the first time land between 45 and 65. The good news is that the fixes are well understood and the improvements are immediate. A site that goes from 55 to 95 will see the difference in both search rankings and visitor behavior within weeks.

The consultant runs an audit and finds a list of structural problems. The URL structure does not make sense. There are no heading hierarchies. The meta tags are either missing or generic. There is no sitemap. The images have no alt text. The page speed is poor. And the internal linking is nonexistent.

Fixing all of that on an existing site is painful. It means restructuring pages, rewriting URLs (and setting up redirects so you do not lose whatever rankings you do have), updating templates, and basically retrofitting an SEO foundation into a building that was not designed for one.

All of this could have been avoided by making the right decisions during the original build.

What "SEO From Day One" Actually Means

When we say we build SEO into every website, we are not talking about stuffing keywords into your homepage. We are talking about the structural and technical decisions that determine whether Google can properly crawl, understand, and rank your site.

Clean URL structure. Every page gets a readable, descriptive URL. Your services page lives at /services/web-development, not /page?id=47&cat=3. This is trivial to set up during development and incredibly annoying to change later because every old URL needs a redirect.

Proper heading hierarchy. Every page has exactly one H1 tag that describes what the page is about. H2s break the content into logical sections. H3s handle subsections. This structure helps Google understand your content and it helps screen readers navigate your site. Getting it right during development costs nothing. Fixing it later means editing every page.

Meta tags on every page. A unique title tag and meta description for each page, written to include your target keywords naturally while being compelling enough to click on in search results. These take five minutes per page to write during development. Retrofitting them requires an audit to even figure out which pages are missing them.

Structured data. JSON-LD markup that tells Google exactly what your business is, where you are located, what services you offer, and what your pages contain. Search engines can figure some of this out on their own, but structured data removes the guesswork and can get you rich snippets in search results.

XML sitemap. An automatically generated file that tells Google about every page on your site and when each one was last updated. Every modern framework can generate this automatically during the build process. There is zero reason not to have one.

Image optimization. Every image compressed, served in modern formats like WebP, with descriptive filenames and alt text. This improves page speed (which is a ranking factor) and makes your images discoverable in Google Image search.

The Timeline Difference

Here is what the SEO timeline looks like when it is built in from day one versus bolted on later.

When SEO is built in, Google starts crawling your properly structured site within days of launch. Within a few weeks, you start appearing in search results for long tail keywords. Within two to three months, you are building momentum on your target keywords. Within six months, you are competing for page one positions.

When SEO is an afterthought, the first few months after launch are wasted. Google crawls your poorly structured site and does not know what to do with it. Then you spend a month or two fixing structural issues. Then you wait for Google to recrawl and reindex everything with the new structure. You have effectively lost four to six months of potential ranking progress.

That delay has real financial impact. If your site would have generated 50 organic leads per month at maturity, and you delayed that by five months, you missed 250 leads. At any reasonable close rate and deal size, that is a lot of lost revenue.

The Cost Difference

Building SEO into a website during development adds approximately zero to the project cost. The developer is already creating pages, writing markup, and configuring the build system. Making the right choices (clean URLs, proper headings, meta tags, sitemap) takes roughly the same amount of time as making the wrong ones.

Fixing SEO after the fact costs real money. An SEO audit runs $500 to $2,000. Implementing the recommendations on an existing site takes 20 to 40 hours of developer time. Ongoing SEO consulting runs $1,500 to $5,000 per month. And you are paying for all of this on top of what you already spent on the original website.

What We Include in Every Build

At Axion Deep Digital, every website we build includes the full technical SEO foundation as standard. Not as an add on. Not as a premium package. Standard.

That includes page speed optimization (98+ Lighthouse scores), proper HTML structure, meta tags on every page, structured data, XML sitemap, image optimization, internal linking strategy, and mobile responsiveness. We also set up Google Search Console and provide a 90 day SEO roadmap for content and link building after launch.

Because when the technical foundation is right from day one, everything you do afterward to improve your rankings builds on solid ground instead of trying to patch holes.

Your website is often the first interaction someone has with your business. And human beings form opinions about credibility in milliseconds. A site that loads slowly feels cheap, outdated, and untrustworthy. It does not matter if your services are excellent or your prices are competitive. If the first impression is a loading spinner, you have already lost ground.

Trust Erodes Instantly

Stanford's Web Credibility Research found that 75% of users judge a company's credibility based on their website design. Speed is a huge component of that judgment. When a site loads instantly, it feels polished and professional. When it takes three or four seconds, visitors start wondering if something is wrong.

This is not rational and it does not have to be. It is instinctive. The same way a physical storefront with flickering lights and a broken sign makes you hesitate, a slow website triggers doubt. And once doubt enters the picture, your conversion rate drops.

Conversion Rates Drop With Every Second

Portent published research showing that a site that loads in one second has a conversion rate 3x higher than a site that loads in five seconds. Not 3% higher. Three times higher.

The relationship is not linear either. The biggest drop happens between one and three seconds. After that, you have already lost most of the persuadable visitors. The ones who stick around on a slow site are the ones who were going to convert regardless. You are leaving all of the "maybe" visitors on the table.

For an e-commerce site doing $100,000 per month, the difference between a one second load time and a three second load time can easily represent $20,000 to $30,000 in lost monthly revenue. For a service business, the math works out differently but the direction is the same. Fewer leads, fewer calls, fewer deals.

Mobile Is Where It Hurts Most

More than half of all web traffic is mobile. And mobile connections are slower and less reliable than desktop connections. A site that loads in 1.5 seconds on desktop might take 4 or 5 seconds on a phone using a cellular connection.

Google uses your mobile page speed for rankings, not desktop. So even if your site feels fast on the office WiFi, what matters is how it performs on a phone on a 4G connection. That is the experience Google measures and that is the experience most of your visitors are actually having.

The Hidden Cost: Paid Advertising Waste

If you are running Google Ads or Facebook Ads, a slow website literally wastes your advertising budget. You pay per click. If 30% of those clicks bounce because your site takes too long to load, you are throwing away 30% of your ad spend.

At $3 per click and 1,000 clicks per month, a 30% bounce rate from slow load times costs you $900 per month in wasted ad spend. That is $10,800 per year. For some businesses, that number is much higher.

Fixing your website speed before scaling your ad spend is one of the highest ROI investments you can make. You are not buying more traffic. You are just keeping more of the traffic you already paid for.

What Fast Actually Looks Like

A properly built website loads its main content in under one second. Not two seconds. Not "pretty fast." Under one second. The visitor clicks a link or types your URL and the page is there almost immediately.

This requires intentional engineering. Optimized images in modern formats. Code that is split into small chunks and loaded on demand. A hosting setup with server response times under 200 milliseconds. Fonts that load without blocking the page render. CSS that is generated efficiently instead of shipping a massive file.

None of this is cutting edge technology. It is standard practice for teams that prioritize performance. The problem is that most web agencies do not prioritize it. They build something that looks good, check the "it loads" box, and move on.

Measuring Your Own Site

Go to Google PageSpeed Insights, type in your URL, and look at the mobile score. That is the number that matters.

If you are under 50, your site is actively losing you money every day. Between 50 and 75, there is significant room for improvement. Between 75 and 90, you are doing better than most but still leaving performance on the table. Above 90, you are in good shape.

The fixes are not mysterious. Compress your images. Remove unused scripts. Upgrade your hosting. Use a modern framework that handles optimization automatically. The specific recommendations will show up right in the PageSpeed report.

But if your site was not built with performance in mind from the start, individual fixes can only get you so far. At some point, the fastest path to a fast website is building one properly from scratch.

This means that a huge number of SEO tools are auditing a blank page and telling you that you have no H1 tag, no meta description, and 12 words of content. That is not an audit. That is a misunderstanding of how the web works in 2026.

We decided to build something better.

Why We Built This

At Axion Deep Digital, we build websites for businesses. Every client engagement starts with the same question: where does your current site stand? We needed a tool that could give us an honest, thorough answer in under a minute.

The existing options fell into two camps. Free tools that barely scratched the surface, running maybe five or six checks against raw HTML. And enterprise platforms charging $100 or more per month that were overkill for a quick site assessment.

We wanted something in between. A tool that was genuinely thorough, powered by real browser rendering, enhanced with AI analysis, and completely free for anyone to use.

How It Actually Works

The tool runs on AWS Lambda with a headless Chromium browser. When you submit a URL, here is what happens behind the scenes.

First, Puppeteer launches a real browser instance and navigates to your page. It waits for JavaScript to finish executing, for network requests to settle, and for the DOM to stabilize. This is the same rendering process that Googlebot uses. If your content only appears after JavaScript runs, our tool still sees it.

Once the page is fully rendered, we extract everything. Title tags, meta descriptions, heading hierarchy, image alt attributes, link structure, Open Graph tags, Twitter cards, JSON LD structured data, word count, reading level, DOM complexity, and inline style usage. All of this comes from the rendered page, not the raw HTML source.

In parallel, we run external checks. We fetch your robots.txt and sitemap.xml. We query the Mozilla Observatory for security header analysis. We send your URL to the W3C validator for HTML compliance. We check your redirect chain to see if requests are bouncing through unnecessary hops before reaching your actual page.

Then we analyze keyword density. We tokenize your visible text content, filter out stop words, and calculate frequency distributions for single words, two word phrases, and three word phrases. We check whether your top keywords actually appear in the places that matter: your title tag, H1, meta description, and URL path.

All of this data gets packaged up and sent to an AI model that synthesizes everything into a prioritized action plan. Not generic advice like "improve your meta tags." Specific, numbered recommendations ranked by revenue impact, referencing your actual scores and your actual content.

Finally, we generate a branded PDF report with score circles, category breakdowns, keyword tables, and the full AI analysis. The PDF gets uploaded to S3 with a temporary download link that expires after an hour.

The entire process takes about 15 to 30 seconds depending on how fast your site loads.

What Surprised Us

After scanning hundreds of sites during development and testing, a few patterns kept showing up that we did not expect.

Most small business sites have zero structured data. Not weak structured data. Not incomplete structured data. Literally nothing. No JSON LD, no microdata, no schema markup of any kind. This is one of the easiest wins in SEO. A LocalBusiness schema takes ten minutes to add and immediately makes your site eligible for rich results in Google.

Security headers are almost universally missing. This one caught us off guard. We expected most sites to at least have HSTS and basic content security policies. The reality is that the vast majority of small business websites serve no security headers at all. No HSTS, no CSP, no X Content Type Options, no referrer policy. Google has confirmed that HTTPS is a ranking factor, and security headers are part of that picture.

Image optimization is still terrible. Missing alt text is the obvious problem, but the bigger issue is missing width and height attributes. Without explicit dimensions, browsers cannot reserve space for images before they load. This causes layout shift, which directly hurts your Core Web Vitals CLS score. CLS is a ranking factor.

Keyword placement is accidental, not strategic. Most sites have reasonable content, but their top keywords do not appear in all three critical locations: title tag, H1, and meta description. Usually the keyword is in the body text but missing from at least one of these high value positions. It is not that site owners are ignoring SEO. They just do not know which placements carry the most weight.

The Technical Decisions

Building this taught us a few things about serverless architecture for compute heavy workloads.

We run on a 2GB Lambda function with a 90 second timeout. Puppeteer with Chromium needs at least 1.5GB to run reliably, and the combination of page rendering, external API calls, and PDF generation needs the extra headroom. The sparticuz/chromium package gives us a Lambda compatible Chromium binary that stays under the deployment size limits.

Rate limiting uses DynamoDB with a composite key of IP address and date. Each IP gets three free audits per day. The table uses DynamoDB TTL to automatically clean up old entries after 48 hours, so we never have to worry about storage growth.

PDF reports go to an S3 bucket with a lifecycle rule that deletes everything after one day. Reports are ephemeral by design. If you want to keep yours, download it. This keeps our storage costs effectively zero.

We chose DeepSeek for the AI analysis because it offers strong reasoning at a fraction of the cost of larger models. For a free tool that needs to handle volume without burning through API credits, the price per token matters. The quality of the recommendations has been consistently good, especially for the structured data we feed it.

What People Actually Do With the Results

The reports break down into three audiences.

Business owners use them to understand where their site stands without needing to interpret technical jargon. The AI summary speaks in plain language about revenue impact and specific next steps.

Developers use the technical checks as a punch list. Every check has a specific pass, warning, or fail status with actionable detail. Missing canonical tag? The report tells you exactly what to add. Heading hierarchy skipped from H1 to H3? It flags the exact issue.

Agencies use the PDF reports as part of their sales process. Run a free audit, show the prospect their score, and walk them through the fixes you can provide. We built the report with a clean, professional design for exactly this use case.

Try It Yourself

The tool is live at axiondeepdigital.com. Enter any URL and get a full audit with AI recommendations and a downloadable PDF report. Three free audits per day, no signup required.

If your site needs more than a report, that is what we do. Axion Deep Digital builds high performance websites with SEO baked in from the first line of code. Every site we ship scores 90 or above on Lighthouse, has complete structured data, and connects directly to your CRM for lead capture.

But the tool is genuinely free with no strings attached. We built it because better SEO across the web is good for everyone, and because we believe the best way to earn trust is to give value before asking for anything in return.

This time I ran my own audit tool against one of our own sites. DeepAudit gave it a 99, and the two warnings underneath that score exposed a problem in my own scoring model. The easier, mostly cosmetic fix was enough to produce a perfect score. The fix that actually mattered was not.

I changed the tool. This is what happened and why I changed it.

The site

The site is lascrucescleaning.com. Crystal runs the cleaning business from our house, and I built the site, so this is not a client site being picked apart in public. It is a ten-page static site with no analytics and no advertising trackers.

DeepAudit gave it a score of 99 out of 100 and a grade of A+. It ran 79 checks, returned two warnings, and listed six notices. The notices are informational and do not affect the score.

I expected the last point to be easy. It turned into a review of the scoring system itself.

The two warnings

The first warning was on the privacy page. It contained 285 words, which put it below DeepAudit's 300-word short-page threshold.

The second warning said the site had no social sharing buttons. That check looks for links that open a prefilled post or message on services such as Facebook or X.

One warning led me to a real omission. The other came from applying a publishing-oriented rule to a local house cleaning site. The score should have reflected that difference. It did not.

The arithmetic

This is the exact scoring formula DeepAudit used. I am including it because the result only makes sense when the rounding is visible.

Every check is marked pass, warning, fail, or info. A pass counts as 1.0, a warning as 0.5, and a failure as 0. Info checks are not scored. DeepAudit calculates each category as a percentage and rounds that category to a whole number. It then multiplies each category score by its weight, adds the weighted results, and rounds the total again for the score shown in the report.

For this audit, the Technical category had a weight of 0.16 and contained 19 scored checks. Social and Schema had a weight of 0.12 and contained 6 scored checks.

A single warning among 19 checks reduced the Technical category to 97. A single warning among 6 checks reduced Social and Schema to 92. The totals were:

| State | Total before final rounding | Displayed score | |---|---|---| | Both warnings open | 98.56 | 99 | | Privacy page fixed only | 99.04 | 99 | | Sharing buttons added only | 99.52 | 100 | | Both warnings fixed | 100.00 | 100 |

That middle comparison is the reason I am writing this.

Adding three share links took about twenty minutes and made no meaningful improvement for the people using the site. That change alone was enough to make DeepAudit display 100. Rewriting the privacy notice fixed a real gap, but that change alone still displayed 99.

This was not a typo or one bad number in the code. The problem came from the structure of the scoring model. The value of a check depended partly on how many other checks happened to be in the same category. The fewer checks a category contained, the more each individual check was worth, regardless of how important that check actually was. I did not design that behavior intentionally, but the arithmetic created it anyway.

What the short-page warning found

The privacy notice was not a problem simply because it had 285 words. The word count helped me find it, but the actual problem was that the page was incomplete.

The site has a chat bubble. Anything a visitor types there reaches us in much the same way as a form submission, but the privacy notice did not mention it. The page also said nothing about server logs, how we use a phone number to respond to a quote request, or how long we keep an old quote before clearing it out.

Those are ordinary details, but they are still details a visitor should be able to find. I rewrote the notice, which took it from 285 words to 572 by the same count that flagged it, and every addition describes something we actually do.

A word-count check cannot tell me whether a privacy disclosure is complete. It can only point out that a page is unusually short and may deserve another look. In this case, that was useful. The check identified the right page, even though word count was not the real defect. I would treat that as a review prompt, not as a scored failure.

What I changed in DeepAudit

I made two changes.

Social Sharing is now unscored information. The check still appears because sharing controls can be useful on articles and other content people are likely to pass along. It no longer affects the score because their absence is not a defect on most of the sites I audit.

Short pages now appear as their own unscored review item. DeepAudit will still tell you that a page falls below the threshold, but it will not treat that fact as a scored per-page problem. Actual page defects such as a missing title, missing or duplicated H1, missing meta description, or missing canonical still score as they did before.

I did not fix the entire scoring model. Checks still inherit some of their value from the size of the category they belong to instead of declaring their own severity. That is the root problem. Changing it would recalculate every audit DeepAudit has ever produced and make older before-and-after comparisons unreliable. It needs to be handled deliberately, not slipped into an unrelated update.

I removed the buttons too

I had already added the share links before I worked through the scoring arithmetic. Once I understood what the score was rewarding, I removed them again.

I could have made an argument for keeping them. A small cleaning company grows through referrals, and those referrals may happen in a Facebook group or a text message. But that argument came after the fact. I was trying to justify a feature that existed only because an audit score had told me to add it.

If we decide to build a referral feature, it should be based on how customers actually refer the business. Three generic sharing links left behind by a bad scoring rule are not that feature.

The website did not need the buttons. DeepAudit needed a better rule.

The title changes were my call

Two page titles were 64 and 69 characters long because the site template added "| Las Cruces Cleaning" to the end of every title. That suffix used 22 characters before the individual page had finished saying what it was about. I replaced both titles with page-specific versions of 42 and 47 characters.

No audit tool told me to do that. DeepAudit passed both title checks. A separate crawl of all ten pages found no broken pages or indexing problems and reported the title lengths without judging them. The 60-character guideline was mine, and I should not present it as if the tools had flagged a problem.

There is no fixed 60-character limit anyway. Google says title elements do not have a set length limit, and the visible title link is shortened as needed to fit the device. I kept the shorter titles because the repeated suffix was using space without adding much information and the new titles describe the pages more clearly. That is the reason for the change. It has nothing to do with earning the last point.

What a score of 100 still does not mean

The final rescan returned 100 and an A+.

The report now contains seven notices: no hreflang, no bold tags, no llms-full.txt, no embedded map, no geo meta tags, several icon-only links, and no social sharing buttons. None of those notices affects the score, and most do not call for any work on this site. A single-language local cleaning site does not need hreflang. Google's documented supported meta tags do not include generic geo tags. The social icons have no visible text, so the icon-only note is accurate, but they do have proper accessible labels. DeepAudit has a separate scored check for links that genuinely have no accessible name.

The seventh notice is the one worth pointing at. Social sharing is still in the report, because it is still worth knowing. It has simply moved to the part of the report that cannot cost you anything. That is where it should have been all along.

That distinction matters to me. A report should show useful context without turning every observation into another job. Those six notices are not six remaining problems, and I am comfortable leaving them open.

A score of 100 also says nothing about whether the prices are right, whether we answer the phone, or whether anyone in Las Cruces knows the business exists. It only describes what this set of checks found on this crawl. We were fortunate to be arguing about one final point at all. In our 2026 small business website study, 96.9% of the 191 sites with mobile Core Web Vitals data failed at least one metric. That group came from 292 domains scanned.

I am not including a performance score from this round of work. I ran the audit three times over the course of the day. PageSpeed returned a desktop result on the first run, a mobile result on the second, and nothing at all on the third. I have not run enough tests to report a median, and one result is not a measurement I would defend.

The takeaway

An audit score is useful as a work queue. It is not a grade on the website, and it should not decide what gets built. Read the findings, check them against the live site, and decide whether each one is actually relevant to the business. Sometimes the correct response is to leave a check unsatisfied.

If you build the audit tool, you have one more responsibility. When a check repeatedly encourages work that does not improve the site, changing the wording is not enough. It should not be able to move the score. In this case, the website was not the thing that needed fixing. The tool was.

Audit your website

Run the same checks on your own site with DeepAudit AI. It is free and does not require a signup.

The score went from 64 to 100

!Bar chart showing the Ahrefs Health Score rising from 64 to 100 while internal URLs with errors fell from 101 to zero

In the first crawl, 101 of the site’s 199 internal URLs contained at least one error. After the confirmed problems were corrected, the next crawl returned zero internal URLs with errors and raised the Health Score by 36 points, from 64 to 100.

| Measure | First crawl | After fixes | Change | | --- | --- | --- | --- | | Ahrefs Health Score | 64 | 100 | +36 | | Internal URLs with at least one error | 101 | 0 | 101 fewer | | Internal URLs crawled | 199 | 199 | no change |

The improvement was real, but the score alone made the result appear more complete than it was. The same report still contained seven warnings and 59 notices. Those 66 open issues did not prevent the site from receiving a perfect Health Score because Ahrefs does not include them in that calculation.

What an Ahrefs Health Score of 100 actually means

Ahrefs calculates its Health Score using the percentage of crawled internal URLs that contain no errors. If every internal URL passes without an error, the site receives a score of 100. Warnings and notices may still appear in the report, but they do not lower the score. A score of 100 therefore means that one crawler found no errors on the internal pages it reached during that crawl. It does not mean the site is finished, ranks well, attracts traffic, converts visitors, or appears in AI-generated recommendations. It is a useful measure of technical condition, but it is not a complete measure of website performance.

A perfect score can still have 66 open issues

!Chart showing zero errors counting toward the score while seven warnings and 59 notices do not

The completed crawl displayed a Health Score of 100 alongside seven warnings and 59 notices. Six pages still had structured data that did not pass Google’s rich-results validation. All of these findings appeared in the same report, but none counted against the score because Ahrefs classified them below the error level.

| Finding type | Count | Counts toward the Health Score | | --- | --- | --- | | Errors | 0 | Yes | | Warnings | 7 | No | | Notices | 59 | No | | Total open issues | 66 | |

That does not mean every warning or notice represents a problem that must be fixed. Some findings reflect recommendations, crawler limitations, or conditions that require further testing. However, it does mean that the score should never be read without the issue list beside it. The 100 shows that the crawler found no errors. The remaining 66 items show that there was still work to evaluate.

The three problems hiding behind 101 errors

The 101 figure represented internal URLs with at least one error, not 101 unrelated defects. Much of the report could be traced back to three underlying problems:

1. One schema mistake repeated across 39 pages. The pages applied `addressRegion` and `addressCountry` to a City object, even though those properties belong to PostalAddress. Because the same schema generator served every location page, one mistake was reproduced 39 times. 2. Six URLs had been broken for two months. Four cross-posted articles and two retired case studies returned 404 errors. Their redirects were managed through the hosting console rather than the repository, allowing the live rules and the saved configuration to drift apart. 3. One live page was missing from the sitemap. A Spanish-language case study returned a successful 200 response when visited directly, but it was absent from the translated-path map. As a result, it never appeared in the sitemap and had no matching hreflang reference.

!Horizontal bar chart tracing 101 error URLs to three underlying problems affecting 39 pages, 6 URLs, and 1 page

One schema mistake repeated across 39 pages

The site applied `addressRegion` and `addressCountry` to a City object, even though those properties belong to PostalAddress. The correct way to describe the geographic relationship was through `containedInPlace`, which the site was already using elsewhere in its structured data. Because the same schema generator served every location page, one incorrect implementation produced validation errors across 39 pages. Correcting the shared generator fixed all of them at once.

| Structured data property | What the site did | What is correct | | --- | --- | --- | | `addressRegion` | Applied to a City object | Belongs on PostalAddress | | `addressCountry` | Applied to a City object | Belongs on PostalAddress | | `containedInPlace` | Already used elsewhere in the site’s structured data | The correct way to describe the geographic relationship | | Pages affected | 39 | All repaired by correcting one shared generator |

Redirect rules that drifted outside the repository

Four cross-posted articles and two retired case studies had returned 404 errors for two months because their redirects were managed through the hosting console rather than the normal deployment process. The repository contained four rules that had never been applied, while the live console contained three working rules missing from the repository. Replacing the live configuration with the saved version would have repaired the six broken URLs but deleted three valid rules, including one used to serve images.

| Where the rules lived | Rules present | Status | | --- | --- | --- | | Repository | 4 | Never applied to the live site | | Hosting console | 3 | Working, but missing from the repository | | Affected URLs | 6 | Returning 404 for two months |

> If part of a site’s behavior lives outside its repository, it is invisible to code review, invisible to deployment, and free to drift quietly out of sync.

A live page missing from its own sitemap

One Spanish-language case study was live and working, but missing from the translated-path map.

#

What visitors saw

Anyone with the direct link could open the page normally. It returned a successful 200 response and appeared to work like any other page on the site.

#

What search engines saw

The page was absent from the XML sitemap and had no matching hreflang reference connecting it to the English version. The page existed, but the site was not properly telling search engines where to find it or how it related to the rest of the content.

| Signal | Status | | --- | --- | | Direct visit to the URL | 200 response, page loads normally | | Present in the translated-path map | No | | Listed in the XML sitemap | No | | hreflang reference to the English version | No |

> Publishing a page and making it discoverable are two separate jobs. The first can succeed while the second fails silently.

Audit tools report clues, not conclusions

During an earlier crawl of the same site, Ahrefs reported five broken images and two broken scripts. Each of the site’s 41 images and 32 scripts was then tested directly, and every file returned a successful 200 response. Reports of multiple H1 elements and duplicate title tags could not be reproduced either. This does not make the audit useless, but it does show why every finding should be treated as a lead to investigate rather than proof of a defect. Confirm the problem on the live site before changing anything.

| What the crawler reported | What was tested | What was found | | --- | --- | --- | | 5 broken images | All 41 images on the site | Every file returned 200 | | 2 broken scripts | All 32 scripts on the site | Every file returned 200 | | Multiple H1 elements | The live pages | Could not be reproduced | | Duplicate title tags | The live pages | Could not be reproduced |

Check the website visitors receive, not just the source code

Reviewing the project files is not enough because templates, build tools, and scripts can change what is ultimately published. After the schema correction, all 391 JSON-LD blocks in the compiled website were parsed to confirm that none still contained the invalid Place properties. Searching the original source files could have missed generated markup and produced a clean result while the live output remained wrong. The final website, not the code used to create it, is what visitors, search engines, and AI crawlers actually receive.

Fix the generator, not every affected page

The 39 affected location pages did not need 39 separate edits. They were all produced by the same schema generator, so correcting three shared values in one file repaired every page at once. When the same defect appears repeatedly, the first question should be what those pages share. Editing each output individually may clear the current report, but fixing the generator removes the underlying cause and prevents the same problem from returning on the next page created.

Sixteen issues disappeared and the score did not move

After the schema correction was published, a new crawl confirmed the result:

| Measure | Before | After | Change | | --- | --- | --- | --- | | Health Score | 100 | 100 | no change | | Schema validation notices | 16 | 0 | 16 fewer | | Total notices | 75 | 59 | 16 fewer | | Total open issues | 81 | 66 | 15 fewer |

!Paired bar chart showing schema notices falling from 16 to zero and total open issues from 81 to 66 while the Health Score stays at 100

Sixteen confirmed issues disappeared, yet the Health Score remained exactly the same. The total issue count fell by 15 rather than 16 because the new crawl added one unrelated warning. The result demonstrates the limitation of the score using the site’s own data: meaningful technical improvements can be measured, confirmed, and completely invisible to the headline number.

What a score of 100 is actually worth

A Health Score of 100 means that 199 internal pages returned no errors to one crawler during one crawl. That is useful. It confirms that the most severe technical problems have been removed and gives the site a cleaner foundation. It does not prove that the site is finished, visible, competitive, or producing results.

The real value of reaching 100 is not the number itself. It is reaching the point where technical errors can no longer serve as the easy explanation for everything that is not working. From there, attention can move to the harder questions: whether people can find the site, whether the content earns trust, whether search engines understand it, and whether visitors become customers. A perfect audit score is not the finish line. It is where the easy technical excuses end.

Audit your website

If you want to see what a crawler finds on your own website, start with DeepAudit AI. It is free, requires no signup, and runs approximately 100 checks across nine categories, including technical SEO, performance, accessibility, structured data, security, and AI discoverability. It renders the website in a browser, can crawl the sitemap, and provides a report with the affected code so you can see where each finding came from.

Treat its results the same way every audit result should be treated: as a starting point for investigation, not a list to follow blindly. Confirm what is real, fix the underlying cause, and measure the website again after the change.

This wasn't just in a report, and not simply a projection. This was in a logged-out incognito session in Google's AI Mode, starting from a plain search for SEO services in a major metro, following up about AI visibility, and then asking the question every buyer eventually asks: which company is best for a startup?

It picked us, over an agency that has been in business much longer with more reviews than us.

That is the good half of the story. The other half is that in the same set of answers, the AI confidently referenced a domain name for our parent company that did not exist. Nobody had ever even registered it; the AI simply decided that a company with our name ought to live at that address and stated it as fact. That said, we registered the domain the next morning and pointed it at the real site, because the alternative was letting an AI hand our traffic to a URL that anybody could have claimed.

Both halves happened in the same conversation. That is what AI answers are like right now: capable of sending you a customer, and capable of inventing facts about you, in the same breath. Today we are opening up the thing that let us see both: AI Visibility Tracking, the measurement service we have been running on ourselves.

The question nobody is checking

Your customers are asking AI assistants for recommendations. Maybe not all of them, and probably not for everything, but the shift is measurable and it isn't changing soon. Someone in your market is typing "who is the best [what you do] near me" into ChatGPT or Google's AI Mode this week. Will you be recommended? The interesting part is that the assistant doesn't show them ten links, but rather names one or two businesses, describes them, sometimes quotes their prices, and moves on. If you're in that answer, you just received a powerful introduction in marketing. If you're not, a competitor did.

That is the strange part. We measure everything else. Rankings, traffic, conversion rates, review scores. But the question "what does the AI actually say when someone asks about my market" goes unasked and unanswered, because until recently there was no practical way to ask it on a schedule and keep the receipts.

This is why we built the schedule and log the answers, starting with our own agency.

What tracking our own agency taught us

We ran recurring queries about our own market against all the major assistants and recorded what came back. Three things stood out:

The answers cite specific pages, and you can see which ones are working. When Google's AI described us, it was not summarizing from air, but rather cited our services pages and FAQ content, our team's LinkedIn profiles, our product sites, and even our public GitHub repositories (this was an interesting finding). Every one of those citations is a signal about which parts of your web presence the machines actually read and trust. We only learned that our FAQ pages are earning citations because we looked.

The answers get facts wrong, and the errors are specific. The invented domain was the dramatic one, but it wasn't alone. A third-party listing the AI leaned on quoted an annual price for one of our products that doesn't match any plan we sell. Imagine what that means for a buyer: the AI told them a price, the price was wrong, and we would never have known why our prospect arrived with the wrong number in mind. These are issues: Wrong prices, dead links, stale addresses, services you do not offer, and the assistants repeat whatever the web says about you, including the parts that are wrong, all while saying it with complete confidence.

The answers move. Models retrain. Sources get recrawled. An answer that names you in March can drop you in June with nothing on your site having changed. A single check tells you where you stood on one day, but only repeated measurements on a regular schedule can honestly tell you whether you are gaining or losing ground, as well as why.

What the service actually does

AI Visibility Tracking is the loop we ran on ourselves, run for you.

We build query sets from the questions your customers actually ask, then run it against ChatGPT, Gemini, Perplexity, and Google's AI on a set schedule, and every response is captured and archived. For each run we record whether you are named, how you're described, which of your pages actually get cited, which competitors get recommended when you don't, as well as what the models get wrong about you. When we catch a hallucination/inaccuracy, we trace back where the bad data probably came from and correct it at the source. When an update on your own site hides content from the AI crawlers, which actually happens far more often than you may realize, a real-browser re-scan catches the regression before the assistants relearn the wrong thing.

All of it rolls up into a monthly AI Visibility Score, so your standing across the assistants is one number with a trend line, backed by the recorded answers behind it. You watch it the way you already watch search rankings. One thing the service deliberately does not include: promises. Nobody controls what a model says, and anyone who guarantees you a ChatGPT recommendation is selling something they cannot deliver. We sell measurement, and the engineering that follows from it.

Why we think measurement comes first

There is a growing ecosystem of AI search optimization advice, and we sell some of it ourselves. Our AI search optimization service handles the 'fix' side (entity and schema work, answer-shaped content, crawler readiness, etc.). We built it on our own published research, including a crawl of 1,261 business websites that found 89 percent of sites name no human being a machine can read. If you never record what the assistants said before the work and what they said after, you cannot tell the difference between an optimization that worked and a model update that did not go your way. Measuring first means every dollar you later spend on fixes has a baseline to be judged against. Some of our tracking clients will never buy anything else from us, and the service is built exactly for that purpose.

Where to start

Two ways in, depending on how curious you are.

The fast one: run your site through our free audit. It shows what the AI crawlers can and cannot read on your site today, in about 60 seconds, no signup.

The complete one: book a free 15-minute call and we will run your business through the assistants live, on the call. You will hear what they say about you, what they say about your competitors, and what they get wrong.

We went looking for what the machines were saying about us and found a recommendation we did not know we had earned and a fabrication we did not know we needed to fix. Both were sitting there, findable, the whole time. Whatever the assistants are saying about your business right now, it is on the record somewhere. The only question is whether you are the one keeping the record.

We did exactly that last month, on the agency directory an AI answer had pointed our own customers toward. Then we went back and checked whether it had actually put us anywhere a buyer would see.

It had not. Here is the number, and then what it should change about how you evaluate a directory.

Listed is not the same as ranked

On August 5 we opened the ranked category page for SEO agencies in our state. Its own header says 126 companies, spread across four pages, ratings updated that morning. We read all four pages and searched every one of them for our name.

We appear on none of them.

We checked again five days later. Same 126 companies, same four pages, ratings updated that morning, same absence. Two measurements, five days apart, same answer.

The profile itself is fine. It is live, claimed, and filled in: tagline, city and state, founding year, hourly range, and a service selector that lists search engine optimization first. It carries one verified five-star review from a real client engagement. Every field the directory asked us for, we answered.

So a claimed profile and a ranked listing are two different objects. The profile is the page about you. The ranked list is the page buyers actually browse when they use the directory to compare providers. Filling in the first does not put you in the second, and in our case it did not put us in the second at all.

You can see the difference inside a single search result. When we ran the query that started all this, one of the results was a competitor's page advertising that this directory had named it a top SEO company in our city. That is what appearing on the list looks like from the outside. Our completed profile has not put us there.

What that costs a business that never checks

We are a small agency and this was an experiment we chose to run. For a business paying into a directory program, the same gap has a price.

You pay a listing or membership fee, and the invoice does not distinguish between having a profile and being ranked in the pages people browse. Somebody on your team spends hours filling in services, portfolio items, and photos, and that time is real whether or not the profile ever surfaces to a buyer.

The expensive part is the third one. A completed profile creates a status report that says the channel is covered. It looks finished, so nobody goes back and tests it. We would not have tested ours either if an AI had not told us, out loud, that this was where it sends people.

Why "get more reviews" is not the whole answer

The easy explanation for our absence is reviews. We have one. Firms above us have dozens.

Except three agencies headquartered in our own city are on that list right now labeled "not yet reviewed." Zero reviews, listed. So whatever factors influence inclusion, a simple review threshold is not one of them. We cannot tell you what they are, because the directory does not publish the rule. We have a hypothesis involving service categories and account tiers, and a hypothesis is not a finding, so that is all we will say about it.

One fact is printed on the page and worth knowing before your next renewal: the directory discloses that it may earn a fee for some placements, and the top block of every page is labeled sponsored or featured. Organic inclusion and purchased visibility are different line items. Know which one you are buying before you judge whether it worked.

None of this makes the directory the villain. A list you could walk into on demand would be worthless as evidence, and an AI weighting third-party signals would learn to ignore it. The friction is what gives the listing its value. It is also why you should verify you are past it rather than assume.

What we did not measure

Sixteen days passed between claiming the profile and the second check. Sixteen days is nothing, and we would say so to a client asking why their rankings had not moved in two weeks. Our result is evidence that claiming a profile does not produce inclusion quickly. It is not evidence that it never will.

We also checked one directory, in one state, from one place. We did not test other markets, other directories, or the same list over a longer window.

One correction, and it is the interesting part. An earlier version of this post said that when we re-ran the AI search that started all this, no AI answer appeared. That observation came from a browser we were signed into, which made it unrepresentative, and a clean logged-out check the same day showed something different. The AI answer does appear, and it now names us among the local agencies it lists, which it did not do when we first wrote about it in July. That happened while we remained absent from the ranked directory list. So the recommendation moved and the listing did not, which means whatever changed it was not the thing we assumed. We altered several things at once over those two weeks and ran no controlled test, so any clean cause anyone offers here, ourselves included, is a guess.

How to check yours this week

1. Search the ranked list, not your profile. Open the ranked page for your service and your market, state or city depending on how that directory organizes its lists, and search every results page for your business name. Your profile URL loading correctly tells you nothing about this. 2. Read the directory's own disclosure before the next renewal. If some placement is commercial, that is a budget decision rather than an SEO one, and it deserves to be made as a budget decision. 3. Run your key buying query more than once, logged out. Same query, different days. If the results or the AI answer change between runs, whatever you saw the first time is not a baseline to plan against.

If you would rather we did that for you, we will. Send us your city and your main service through our contact form with "AI Visibility Footprint" as the subject, and we will check by hand where your business actually appears in the ranked directory lists, review surfaces, and AI answers for your market, then send back what we find. A person does this and writes it up, so it is not instant and it is not automated. It is free, and it tells you which of those surfaces currently has your name on it.

If you want the other half first, the part on your own website that you do control, our free audit scores rendering, speed, technical checks, and AI-readiness signals: run a free audit.

We claimed the profile the AI pointed at, and we are not on the list it reads. We do not fully know why, and sixteen days is too early to conclude much. We are reporting it anyway, because we said we would report the measured result whichever way it went, and because "we are listed in the major directories" is a sentence a lot of businesses are telling themselves without having checked.

We wrote about that screen when it happened: being the top-cited source in an AI answer is not the same as being the one it recommends. This is the follow-up, and it is about the half of that problem we do not control.

It starts with a distinction most SEO advice treats as one thing.

A description and a referral are not the same document

A description is written from inside your own pages. The machine reads your site, your schema, and your about text, and assembles a summary. That is the readable half, and for us it worked. An AI can now describe our company accurately.

A referral is read from somewhere else. When an assistant decides who to recommend, it does not walk back into your website. It reads the third-party layer: the directory profiles, the review counts, and the ranked lists that other people maintain about you. You can build your own site to a standard. You cannot write the reference that a directory holds, and that is the entire point of it. A reputation you can author yourself is not evidence, and a system weighting referrals knows the difference.

So an accurate description was never going to earn the recommendation. Different document, different author, different source.

We went to the directory it named

The honest move was to take the machine at its word. It named the evidence layer it trusts, out loud, by sending the reader to a directory to compare. So we claimed our place in that layer.

We now hold claimed, populated profiles on the same class of agency directory the AI pointed to, and on the two peers in its category. Location, services, portfolio, and the names of the people behind the work are filled in rather than left as a stub. We also created structured entries in Wikidata, the open knowledge graph that many systems read from, one for the person behind the work and one for the business. A Wikidata editor deleted both in September 2026 for not meeting the notability policy. That is the third-party layer working exactly as described. You cannot write your own entry in a record other people maintain, and that is the same reason a referral read from that layer carries weight in the first place.

That is real work, and it is the right work. Now the part we would rather not skip.

What this does not buy, stated plainly

It is not a link-building trick. Every one of those directory profiles links back with a nofollow tag, which is the directory convention. They pass a citation and a referral path, not ranking equity. If you are claiming directories to collect links, you have the wrong reason. Claim them to be present where the referral is decided.

A claimed profile is an empty line until reviews fill it. We have one verified five-star review on the main directory and a handful of syndicated ones on another. That is a start. It is not a reputation, and we are not going to dress it up as one. A claimed profile is just the listing. The reviews are what give it weight, and those we earn one real customer at a time.

We cannot tell you it moved the recommendation, because we have not measured it. We ran no re-test for this piece. And even when we do, one query on one day, in one city, would not settle it, because that answer is geo-personalized and drifts. We will report the measured result later, the same way we reported the unflattering screen that started this: with the number, whichever way it goes.

Why the slow lever is the right one

It would be easier if schema did it. Ship the markup, get the referral, done. It does not work that way, and the reason it does not is the reason to trust it. The one layer you cannot self-author is the one an assistant can lean on when it decides who to send a stranger to. If you could fill the directory yourself, it would be worthless as evidence, and the machine would ignore it too. The friction is the feature.

What you can do this week

1. Ask the AI where it sends people in your market. Search your main service and city in an assistant, read the answer, and notice which directory or review site it points to at the end. That is the evidence layer it trusts for you. Write the name down. 2. Claim your profile there, and on its two or three peers. Fill it completely: real location, services, a named human, and correct name, address, and phone. An empty or half-claimed profile is worse than none, because it looks abandoned. 3. Ask one real, recent customer for one honest review on that profile. Not ten. One real review, this week, on the directory the machine already reads. One earned line beats a page of thin citations.

The readable half is still worth doing first, because the description has to be right before the referral is worth chasing. Our free audit scores that half, the AI-readiness signals alongside the speed, rendering, and technical checks: run a free audit.

We built the site to be read accurately. We have now shown up in the third-party layer and started, honestly, from one review. The next report tells you whether the machine noticed, including if it did not.

That study invites a fair question back at us. We sell this work, so we should be willing to run the same measurement on ourselves.

Here is what we found, in two parts. The first part went well. The second did not, and it is the more useful half.

We asked an AI to describe us

Open an AI assistant and ask it to describe Axion Deep Digital. Here is what one returned on the day we wrote this, unedited:

> "Axion Deep Digital is a division of Axion Deep Labs, an independent R&D organization. Axion Deep Digital builds custom, engineering-first websites and provides technical SEO and lead-capture systems for small businesses and startups. They apply research-grade engineering to commercial web projects, building sites with React and Next.js that score 98 or above on Google Lighthouse out of the box. Every engagement includes structured data markup, accessibility compliance, and mobile-first responsive design as standard deliverables. Sites are hand-coded in React, Next.js, and TypeScript rather than built on WordPress, Wix, or page builders, with no templates and no outsourced code."

We did not write that paragraph, and it does not appear on our site in that form. A machine assembled it from what it could read, and it got the details right, including the stack and the Lighthouse standard we hold builds to.

What we did, and what we cannot prove it caused

Our AI-Readiness index scores a site from 0 to 10. Two points each for permitting AI crawlers, publishing an llms.txt, publishing identity schema, and publishing review schema. One point each for FAQ and Person schema. Across the 1,261 reachable sites in the study, the mean was 3.77 and the median was 4. The most common single score was 2.

We built our own site to a 10 on that same rubric:

- A named person marked up with Person schema, rather than an anonymous "our team." - Organization and identity schema, so the entity is stated rather than implied. - An llms.txt whose links are real markdown links. Bare URLs fail our own checker, and that is the most common way a well-meant llms.txt scores nothing for us. - FAQ and review schema.

Now the part we would rather not skip. We cannot prove any of that produced the description above. We ran no controlled test. A site with no structured data at all, but a clear about page, might well have produced the same summary. What we can say is narrower: we did the work, the description is accurate, and we have not had to correct anyone. Whether the schema earned it or the plain text did, we did not measure.

The part we have not solved

Being described accurately is not the same as being recommended, and one search shows both at once.

Search Google for SEO in Las Cruces, from Las Cruces. Three things come back on one screen.

In the local map results we are first, at five stars, above an agency holding 32 reviews to our 6.

In the AI Overview above it, the assistant drew on six sources. Ours was the first one it cited. It used our page, our description, and our pricing.

Then it recommended three other agencies. We were not one of them.

The AI read our website first, and then told the searcher to call somebody else.

That is not unfair and it is not a defect. The two answers run on different evidence. A description can be assembled from your own site. A referral is assembled from somewhere else, and this one said so directly: it closed by sending the reader to a third-party directory to compare ratings and budgets.

So we have done the readable half. The other half is third-party evidence, meaning directories, review profiles and ranked lists, and we have not earned enough of it yet. No markup substitutes for that.

What you can do this week

1. Name a human. Add a real person with Person schema instead of a faceless "team," so a system can answer who is behind the business without guessing. 2. Publish an llms.txt using markdown links rather than bare URLs. One H1, a short description, real links. 3. Add Organization, FAQ and review schema, so your answers and your proof are structured rather than buried in prose.

Then run the test we ran. Ask an AI to describe your business and see whether it gets you right or invents something. That is a free five-minute check on the readable half.

If you would rather have it measured, our free audit scores AI readiness alongside the speed, rendering and technical checks: run a free audit.

The study behind these numbers is here: We Crawled 1,629 Business Websites, with the method and data on the research page.

We will report on the second half as we earn it, the same way we reported this one, including the parts that are not flattering.

We crawled 1,629 business websites to find out what an AI system actually encounters when it arrives. Almost everyone lets it in. Almost nobody gives it anything to work with.

What we measured

Every site was checked on three layers.

Permission. Does robots.txt block GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot or the other AI crawlers?

Guidance. Does the site publish an llms.txt, the plain text file that tells an AI agent what the site is and which pages matter?

Structure. Does the site publish schema.org structured data, the machine-readable layer that states who the business is, who works there, what people have said about it, and what questions it answers?

Those three layers combine into a 0 to 10 AI-Readiness index, defined before the crawl ran and registered publicly so we could not move the goalposts afterward.

The sample covers 30 cities across five strata (metro, mid-size, small town, university, tourism) and 11 industries. We crawled 1,629 domains. 1,261 of them responded.

That gap is the first finding, and it arrives before any of the interesting ones. Twenty-three percent of these business websites did not respond at all. Nearly one business in four whose website is a matter of public record does not currently have a working one.

The headline: a 2 out of 10

Across the 1,261 reachable sites, the mean AI-Readiness score is 3.77 out of 10. The median is 4.

The number that matters is the mode. Four hundred ninety-nine sites, 40 percent of the sample, score exactly 2 out of 10. A 2 has a specific meaning in our rubric. It means the site permits AI crawlers and does nothing else. No machine-readable identity, no named people, no structured answers. The door is open and the rooms are empty.

!Distribution of AI-Readiness scores across 1,261 business websites. Forty percent score exactly 2 out of 10.

What is actually on these sites

Adoption across the 1,261 reachable sites, with 95 percent confidence intervals:

| Signal | Adoption | |---|---| | Identity schema | 53% (50-56) | | llms.txt | 25% (23-28) | | Person schema | 11% (9-12) | | Review schema | 8% (7-10) | | Blocks an AI crawler | 5% (4-7) | | FAQ schema | 4% (3-5) |

!Adoption of AI-readiness signals with 95 percent confidence intervals. Blocking an AI crawler is the rarest signal, at 5 percent.

Read the bolded row against the rest. Five percent of businesses block AI. That is the thing the industry argues about. Meanwhile 89 percent never name a single human being in a format a machine can read, and 96 percent publish no structured answers to any question.

The gate is not the problem. Everyone has already left the gate open. The problem is that there is nothing inside worth citing.

The llms.txt mirage

A quarter of sites have an llms.txt, which sounds like fast adoption for a standard barely a year old. It is not what it appears to be.

At least a quarter of those files carry the signature of a tool that generated them automatically, most often a WordPress SEO plugin such as Yoast or Rank Math. The remaining files carry no detected generator, and it is worth being precise about what that means. It means we found no tool signature. It does not mean a human wrote the file. When we classified provenance strictly in our study of 556 accounting firms, only about 9 percent of firms had genuinely authored their own.

Presence is not intent. A file your plugin emitted describes your platform. It does not describe your practice.

Some industries are further along than others

The gap between professions is real and it is wide.

| Industry | Identity | Review | Person | |---|---|---|---| | Lawyers (n=177) | 64% | 22% | 28% | | Dentists (n=240) | 62% | 9% | 12% | | Veterinary (n=100) | 53% | 2% | 6% | | Real estate (n=132) | 51% | 3% | 6% | | Beauty and med spa (n=243) | 50% | 6% | 5% | | Opticians (n=73) | 48% | 1% | 3% | | Auto repair (n=209) | 43% | 8% | 8% | | Accounting (n=51) | 35% | 6% | 10% |

!Identity schema and Person schema adoption by industry. Lawyers lead on both. Accounting has the lowest identity coverage.

Lawyers are the most structured industry we measured, and by a distance. On every one of the three signals they lead. Accounting sits at the bottom on identity, which is a striking place for a profession whose entire product is credentialed expertise.

Two industries in our sample, plumbing and HVAC, returned too few sites to report. Our protocol requires at least 40 sites in a cell before we publish a rate for it, and both came in under that. We are not going to print a percentage we cannot stand behind, so those cells are pooled and flagged rather than reported.

The most important result is the boring one

We have now run this crawl four times, at four different scales: 149 sites, then 487, then 766, and now 1,261.

The numbers barely move. Identity schema lands within a few points of 50 percent every time. Review schema stays near 8 to 11 percent. Person schema stays near 10 to 13. The share of sites blocking AI stays at 4 to 5. The share scoring exactly 2 out of 10 stays around 40.

That stability is the actual finding. A single crawl is a snapshot and can be dismissed as an artifact of who happened to be in the sample. Four crawls, at four scales, in different cities, converging on the same numbers, is a description of the landscape. It means the picture above is not a quirk of our sample. It is what the web looks like right now.

What to do about it

Stop worrying about the gate. You almost certainly are not blocking AI crawlers. Confirm it once, then move on. This is the least of your problems.

State who you are. Identity schema is the floor, and half of all businesses are still below it. It is a small, one-time technical change.

Name your humans. Person schema is the single biggest gap in the data. Eighty-nine percent of businesses have not told any machine that a specific, credentialed person works there and knows a specific subject. When an AI is asked to recommend an expert, it needs to know an expert exists. Most sites never say so.

Write your own llms.txt, or do not count the one you have. If a plugin generated it, it is describing your software, not your business.

Structure your answers. Four percent of sites publish FAQ schema. Answer engines are, definitionally, in the business of answers. Almost nobody is handing them one.

Method and data

The index rubric, the sampling frame and the analysis plan were registered before the confirmatory crawl ran, at OSF (DOI 10.17605/OSF.IO/2Q5ER). Proportions use Wilson score intervals. The crawler, the analysis code and the full dataset are public at github.com/Axion-Deep-Labs/ai-readiness-2026, the code under MIT and the data under CC BY 4.0. A revised working paper covering this confirmatory wave follows.

If you want to know what your own site looks like to an AI crawler, our free audit checks the same layers we measured here.

It wasn't. Most of the firms had never written one.

What an llms.txt file is

llms.txt is a plain-text file that identifies a site and points AI systems toward its important content. In theory, it gives those systems a cleaner map of what the business does and which pages explain it best.

Almost none of them were written by the firm

Of the 556 firms, 92 had a valid llms.txt. When we classified where each file came from, only 43 were written by the firm. The other 49 were generated automatically by the platform the site runs on:

- Wix now emits an llms.txt for every site, advertising its Model Context Protocol endpoint. That was 30 of them. - WordPress SEO plugins (All in One SEO, Yoast, Rank Math) generate their own. Seventeen more. - Shopify emits one for its commerce protocol. Two.

Strip out the automatic files and the real number is 9.3 percent. Fewer than one accounting firm in ten has chosen to publish an llms.txt. The one-in-five figure was a mirage created by a handful of platforms doing it by default.

Why the auto-generated ones do not count for much

An automatically generated llms.txt is not worthless, but it is not the signal it looks like. It describes the platform, not the practice. A Wix-generated file tells an AI agent that the site supports Wix's protocol. It does not tell that agent that your firm has a partner who handles pre-IPO equity compensation, or a team that specializes in trust and estate work. The file exists, but it contains almost none of the information that would help an AI system understand why someone should hire that firm.

The mirage hides a bigger gap

The llms.txt number is a symptom. The deeper finding in the same study is harder to explain away: 94 percent of these firms publish no Person schema at all.

Person schema is the structured data that connects a named human to a role and an area of expertise in a format a machine can read. It is how an answer engine knows that a specific credentialed person, at your firm, handles a specific topic. Our earlier pilot found none. The full study found 27, but that still leaves 94 percent of reachable firms without Person schema.

Here is why the two findings belong together. An llms.txt file cannot identify an equity-compensation specialist if the site never clearly connects that person, credential, and expertise in the first place.

It is not that firms are blocking AI

Accounting firms are not broadly blocking AI crawlers, either. Only 2.4 percent of the firms blocked even one in robots.txt. The doors are open. There is simply nothing structured on the other side to read. This is primarily an implementation gap, not a deliberate refusal to participate. That makes it much easier to fix.

What to do instead of chasing llms.txt

If you take one thing from this, it is the order of operations. Do not start with llms.txt. Start with the structured data that names your people and your services, because that is what an AI actually needs to recommend you, and it is where almost every firm has a gap.

That means Person schema for each of your named CPAs and their credentials, tied to your firm's Organization or AccountingService data. We wrote the practical version of this fix in Schema Markup for CPA Firms and, for the AI-recommendation angle specifically, in Will AI Recommend Your CPA Firm. Neither requires a redesign or a single new page. Both make expertise you already have legible to a machine.

One thing we do not recommend: adding review or rating schema to your own site. Google's guidelines disallow self-serving review markup, and only 3 percent of the firms we checked used it anyway. Person, identity, and FAQ schema are the honest levers.

The firms that get recommended are the legible ones

AI systems cannot evaluate expertise that a firm never clearly publishes. A highly qualified CPA with an unstructured bio may be harder for a machine to identify than a less experienced competitor whose role, credentials, and specialties are clearly connected.

Right now, very few accounting firms are doing this well. That gives the firms that fix it early a real advantage.

The full study, including the methodology and the open dataset, is The State of CPA Firm Websites 2026. If you want to see what an AI actually reads on your own site, our free DeepAudit scan renders the page in a real browser and checks the structured data an answer engine sees. It takes about a minute.

The difference may have little to do with professional ability. One firm may have published clear, corroborated evidence connecting named professionals to their credentials, locations, and specialties. Another may leave those relationships scattered across biographies, service pages, and third-party profiles.

AI does not read your website the way a person does

When you land on a firm's team page, you see it instantly: names, credentials, headshots, a short bio for each partner. One person is the trust and estate specialist. Another handles pre-IPO equity. Your brain connects a person to an expertise in about a second.

An AI system does not necessarily reconstruct those relationships the same way. Depending on the product and the query, it may rely on indexed page text, search results, structured data, links, and information from third-party sources. When those sources consistently connect a person to a firm, a credential, a location, and a specialty, the evidence is easier to interpret.

A biography can still be read without schema. The problem is that the relationship may be less explicit. Is the person currently employed by the firm? Is "CPA" a verified credential or just nearby text? Does the specialty belong to that person or to the practice generally?

Professional quality and machine legibility are different things. A firm can be highly qualified and still publish weak evidence of that expertise.

Person schema can make those relationships more explicit

Person schema is a block of structured data that explicitly describes a named person and can connect that person to an employer, a credential, a profile, and an area of expertise. Search engines and other systems may use that information to better interpret and disambiguate the entity. Paired with Organization data and a substantive biography, it makes the intended relationship explicit: this person works for this firm, holds these credentials, and practices in these areas.

Structured data describes what the page already says. It does not create credibility by itself, and it is not a substitute for the underlying profile.

We have looked at a lot of accounting firm sites. The pattern is consistent: real expertise sitting on the team page and the service pages, and no structured data marking any of it up. The credentials are visible, but the relationships between the person, the firm, the credential, and the specialty remain ambiguous.

In the accounting sites we studied, Person schema was rare. Even a basic implementation would place a firm ahead of most of the current cohort in how explicitly it publishes professional identity, and it does not require writing a single new page.

Why this matters for AI-assisted discovery

Some of the crawlers behind AI answers do not execute JavaScript, and what they can retrieve is limited to what the server sends. In our study of 368 small-business websites, the raw HTML available to non-rendering crawlers omitted at least one answer-critical element on one in four sites. For a professional-service firm, missing names, credentials, specialties, or contact information from the crawler-visible page directly weakens the evidence available to any system trying to understand the business.

Traditional search still matters. AI-assisted answers add another discovery path, but many of the underlying requirements are familiar: crawlable pages, clear authorship, well-supported claims, consistent business identity, and useful content.

What legible actually looks like

Three things, in order:

1. Give each named CPA a substantive profile page. Then use Person or ProfilePage structured data to describe the same visible facts, including role, employer, relevant credentials, and verified external profiles. 2. Shape your key pages like answers, not brochures. A page that directly answers "how are RSUs taxed at IPO" gives search and AI systems something specific to retrieve and attribute. A page that only says "we offer equity compensation planning" provides far less evidence. 3. Make the site crawlable without relying on client-side rendering. Maintain an accurate sitemap and keep important information in the page HTML. An llms.txt file can be added as an experimental supplemental index, but it is a proposed convention, not a substitute for those foundations.

None of this requires inventing a separate version of the firm for AI. It requires publishing the same real-world expertise more clearly: who the professionals are, what they are qualified to do, where they practice, and which independent sources support those claims.

If you want the full version of this built for an accounting firm, that is exactly what our SEO for CPAs work does. Person schema is worth adding, but start with the underlying profile. Make the biography complete, connect it to the relevant services, link verified external profiles, and make sure those facts agree everywhere the firm appears. Then use structured data to make the relationships explicit.

Before publishing more content, we would check these five things.

Your best pages are hard to reach

One of the first things we check is whether a firm's most valuable pages can actually be reached through normal navigation and contextual links. On a lot of accounting firm sites, the genuinely useful pages, the ones on trusts, equity compensation, and exit tax, sit four or five clicks from the homepage with almost nothing pointing at them.

Internal links help Google discover pages, understand how they relate to one another, and identify which pages the site emphasizes. If an equity-compensation page is linked only from an old blog archive, it may well be indexed, but the site is giving Google very little context about its importance. Meanwhile, the homepage and the contact page collect links from nearly every page on the site, while the pages tied to actual services get one or two.

The first fix may not be more content. It may be a clearer structure and contextual links from the homepage, the service hubs, the professional biographies, and related articles down to the pages that matter commercially.

The site is slow for real visitors

Accounting firms love a page builder, and page builders love to ship bloated, slow pages.

Core Web Vitals are part of how Google evaluates page experience. Poor performance will not erase strong content, but it can make a page less competitive, and it makes the site harder for a prospective client to use. That second part matters on its own.

This is not a niche problem. In our study of 292 small-business websites, 191 returned valid mobile Core Web Vitals data. Of those, 96.9 percent failed at least one of the three metrics.

Check the field data in Search Console before rebuilding anything. A single Lighthouse run is a lab test. The Core Web Vitals report shows how groups of pages actually performed for real users, where there is enough data to say.

Each office has become a different version of the firm

Multi-office firms create another failure point. One location uses a shortened business name, another still appears at an old address, a third lists a phone number that routes somewhere else.

Each eligible office needs one accurate identity: the firm's real name, that office's address, its correct phone number, hours, categories, and page on the website. Those facts should agree everywhere that specific location appears. This is not the whole local-ranking system, which Google says is based mainly on relevance, distance, and prominence. It is the part a firm can inspect and correct directly. We covered the full cleanup process in Local SEO for Multi-Office Accounting Firms.

Several pages may be doing the same job

Firms accumulate pages over the years. Having more than one page on a broad subject is not automatically a problem: a cryptocurrency tax-planning service page and an article answering a specific cryptocurrency question can serve different searches, and both can deserve to exist.

The problem is several thin pages answering essentially the same question, with no clear reason for each one to be there.

Search Console will tell you. Filter by a query and look at which URLs pick up impressions for it. When two pages genuinely duplicate each other, combine the useful material into the stronger one and redirect the obsolete URL. When they serve different purposes, make that difference clearer in the title, the headings, the internal links, and the content, rather than deleting one reflexively.

The expertise exists, but the relationships are vague

Most established firms have qualified people on the site. The problem is usually how the evidence is connected. A partner's name appears on the team page, the credential sits in a short biography, and the specialty is mentioned only on a general service page. A reader can piece that together. The site never states the connection especially clearly.

Build a complete profile for each important professional: current role, relevant credentials, specialties, office, authored content, and verified external profiles. Structured data can then describe those same visible relationships more explicitly. We wrote about that separately in Will AI Recommend Your CPA Firm.

Audit what exists before adding more

Notice what is not on this list: "write more content" and "buy more backlinks."

Many established firms already have more useful material than they realize. Before commissioning another year of articles, find out whether the pages already on the site are reachable, distinct, current, fast, and clearly connected to the people and services behind them.

Some of those fixes can be deployed quickly. That does not mean rankings change on the same schedule. It does mean the firm stops piling new content on top of a structure that is already working against it.

A free audit is a reasonable starting point. It renders the site in a real Chromium browser and checks the technical, content, structured-data, performance, accessibility, and crawlability signals. Then inspect the important pages by hand, because no crawler replaces that last step. The full playbook for an accounting firm lives on our SEO for CPAs page.

We would fix two relationships first: the firm and its offices, then the professionals who work there.

First, what schema actually is

Schema markup is structured data: a block of code that describes the people, organizations, places, and content represented on a page. It does not change what visitors see, but it can help search engines and other systems interpret the relationships more explicitly. Think of it as an explicit label attached to information the page already shows.

That last part is a rule, not a throwaway. Schema should describe visible, supportable information rather than inventing claims behind the page. For an accounting firm, the useful part is making relationships clearer: this person works for this firm, holds this role, and practices in these areas.

Start with the business

Use Organization for the parent firm and AccountingService, a subtype of LocalBusiness, for each real, staffed, customer-facing office. Give every node a stable `@id`, and make sure the name, address, phone number, and hours agree with the website, the Google Business Profile, and the firm's major directory listings.

Local business markup does not guarantee a map-pack ranking. It gives search systems a clearer, structured version of facts they can also find elsewhere, and its value increases when those sources agree. If the firm has multiple staffed offices, represent each one separately and connect it back to the parent organization. A virtual office, a mailbox, or a service area is not a branch.

Then connect the people

Each important professional should have a substantive biography that clearly states their role, credentials, specialties, and relationship to the firm. Use Person markup to describe those same visible facts and connect the person back to the organization.

The schema does not prove that someone is qualified, and it does not guarantee that an AI assistant will recommend them. It removes ambiguity. Is this person currently employed by the firm? Is the credential attached to them or just sitting nearby in the text? Does the specialty belong to the person or to the practice generally?

That distinction matters. In our 556-firm study, 94.2 percent of reachable sites had no Person schema at all. The expertise usually existed on the page. The structured connection between the person, the firm, the credential, and the specialty did not.

Be careful with reviews

There is a strong temptation to add Review or AggregateRating schema so a star rating shows up in search. Google does not provide self-review stars when a business controls the reviews about itself, so adding AggregateRating to your own firm is not a shortcut to a richer result. At best Google ignores it for that feature, and misleading or policy-violating markup creates unnecessary risk. Display legitimate reviews for visitors and link to the source.

Other types can still be useful

Do not add a schema type solely because a plugin makes it available. Service, FAQPage, Article, and BreadcrumbList can all be useful when they accurately describe the visible page and connect to the same organization graph. They are not substitutes for getting the core entities right.

The problem is not the number of types. It is unsupported, duplicated, contradictory, or disconnected markup. We see firms with schema on every page but no stable identifiers linking one node to another. Every block validates independently, and the site still fails to express a coherent relationship between the firm, its offices, its services, and its people.

How to check yours

Use Google's Rich Results Test to check markup tied to supported Google search features. Then use the Schema Markup Validator to inspect the complete graph, including types and properties Google's tool does not report. Our free audit flags missing and malformed structured data across the whole site.

Validation is only the first check. The bar is not "the validator turned green." The markup should describe what visitors can actually verify on the page, use stable identifiers, and connect the firm, its locations, and its professionals into one consistent graph.

Most CPA firms do not need forty more schema types. They need the first few to tell one consistent story. Building that graph for an accounting firm is what our SEO for CPAs work does.

Every office accumulates its own version of the firm

Here is a common pattern.

The main office uses one version of the firm's name on the website and another on Google. A second office still appears at an old address on a directory nobody has logged into in years. A third has a phone number that routes to headquarters. Reviews are split between an active profile and a duplicate nobody controls.

To a person, it is clearly the same accounting firm. To Google and to a prospective client, the current information is less obvious. Those differences can send a client to the wrong office, or leave a review attached to a profile the firm does not manage.

That does not mean inconsistent listings are the only thing controlling local rankings. Google says local results are based mainly on relevance, distance, and prominence. But conflicting office information is one of the few parts of that system a firm can find and correct directly.

Give every eligible office a clear identity

Not every address deserves a profile. A profile should represent a legitimate, staffed, customer-facing location, and each location gets exactly one. What each of those offices needs:

- One Google Business Profile, using the firm's real business name as it appears offline, with that office's correct address, local phone number, hours, and categories. - A dedicated location page on the website showing the same office information, plus the professionals and services available there. - AccountingService or LocalBusiness structured data describing that location and connecting it to the parent organization. The schema should confirm what the page already says, not introduce a different version of the business. - Correct listings on the directories and professional profiles clients and search systems are likely to encounter. - A documented decision for every duplicate: keep, correct, claim, merge, or remove.

The location page is the piece most firms skip. It is what the Google profile and the structured data both point back to, and without it there is nothing on the site that specifically represents that office.

Consistency matters, but accuracy comes first. Do not force every office onto the same phone number, hours, or service list just to make the records match. Different offices have different staff and different details. The goal is not to make every location identical. It is to make every source agree about the correct facts for that specific office.

Keep reviews attached to the right location

Reviews contribute to local prominence, and fragmented profiles make them harder to manage. A client may leave feedback on an old or duplicate profile while the office's active profile receives none.

Once the correct profile for each office is established, send review requests directly to that location rather than to one generic firm-wide link. When two profiles genuinely represent the same office, request a merge instead of deleting the duplicate. Google combines the reviews from both profiles when it approves a duplicate merge, although review replies may not carry over.

One note on your own website: display legitimate reviews for visitors and link to the source, but do not expect Review or AggregateRating markup on your own firm to produce review stars. Google excludes self-serving reviews on LocalBusiness and Organization entities from that feature.

Start with an inventory

Search Google and Google Maps for every version of the firm you can think of:

- The firm's exact name - Each office address - Each office phone number - Old firm names and common variations - Each partner or practitioner who may have a separate profile

For every result, record the profile URL, business name, address, phone number, website, categories, hours, review count, and verification and ownership status. Then give each result one action: keep, correct, claim, merge, or remove.

That inventory is the real beginning of multi-office local SEO. It is almost always longer and messier than firms expect. Until the firm knows how each office currently appears, it cannot build a reliable local presence on top of it.

Multi-office cleanup is part of our SEO for CPAs work and our Google Business Profile management. We begin with the inventory, resolve the conflicting profiles, and put a process in place to keep them accurate afterward.

We build software in the SEO and lead-gen space, so we spend a lot of time looking at how people try to grow a website. And the pattern is almost always the same. Somebody buys Ahrefs, installs a WordPress plugin, opens fourteen browser tabs, exports three spreadsheets, and then wonders why the needle isn't moving.

None of those tools is the problem. The problem is that buying them feels like progress, even when nothing connects the research, the site, the leads, and the eventual sale. You end up with copy-paste, manual posting, missed follow-ups, and a graveyard of broken workflows that nobody wired together. Tabs are not a strategy.

Developers already know the difference between installing a library and shipping something reliable with it. We approach SEO the same way: as a system with inputs, dependencies, failure points, and measurable output.

The trap: a shelf of tools is not a pipeline

The size of the software market makes the problem easy to see.

Scott Brinker's martech landscape counted 15,384 tools in 2025, up about 9% year over year and roughly 100x the 150 tools that existed in 2011. So the category isn't just big, it's compounding.

And we barely use what we buy. Gartner's marketing survey found teams using only about 33% of their martech stack's capabilities in 2023, recovering to roughly 49% by 2025. Even after that recovery, teams were still leaving roughly half of their purchased capabilities unused.

We see the far end of this pattern constantly. When we scanned 292 small-business sites, almost all failed a basic mobile performance check. Not for lack of tools. For lack of a system connecting them.

None of that is a tooling shortage. Nobody's problem is "I need a fifteen-thousand-and-first tool." The problem is that the tools don't talk to each other, the workflow between them is manual, and there's no pipeline connecting "I published a thing" to "a customer paid me."

So instead of shopping, build the pipeline. Here's the stack we actually reach for, bottom to top, and what each layer is really doing.

Layer 1: Keyword and backlink research (decide what to build for)

Skipping research is like writing a feature before reading the ticket. The job isn't "find high-volume keywords." It's the intersection of what people search, what you can credibly rank for, and what actually makes you money. A 40,000-searches-a-month term you have no authority to win, and that converts nothing, is worse than a boring 90-a-month term a ready-to-buy customer types in.

Backlink research shows who links to the pages already winning those searches, and whether you have a realistic way to earn comparable links. That tells you whether a page is worth the time before you build it.

Output of this layer: a short, ranked list of pages you're going to build or fix, each tied to a real query and a real conversion. That list is your backlog.

Layer 2: Search performance and indexing data (your production telemetry)

If you ship code without logs and metrics, you're flying blind. Same with a website. Google Search Console is the closest thing you get to production telemetry straight from the search engine, and it's free.

Two reports do most of the work:

- Search Performance: Clicks, Impressions, CTR, and average Position, sliceable by query, page, country, and device. Your "what am I actually ranking for, and where" dashboard. - Page Indexing (the old Coverage report): which URLs are indexed, and for the ones that aren't, why. Reasons like "Crawled - currently not indexed" and "Excluded by noindex tag" are the error log of your site's relationship with Google.

Two limits will bite you if you build on top of it. Performance data is a rolling 16-month window, so export it yourself if you care about year-over-year. And the UI caps exports at 1,000 rows, which is nothing for a real site. Get past the cap with the Search Analytics API (up to 50,000 rows/day per property per search type) or the Bulk Data Export to BigQuery, which isn't row-limited. If you can write a `for` loop, you can pull your own data at real scale instead of squinting at the dashboard.

Don't eyeball GSC once a month. Pipe it somewhere you can query it.

Layer 3: Technical SEO audits

A technical audit is a linter for your site's crawlability. It isn't one official Google checklist, it's an industry-consensus set of categories, but the categories are stable, and they're the same ones our own DeepAudit AI grades:

- Indexability and directives: robots.txt, meta robots, canonical tags, HTTP status codes - XML sitemaps: present, valid, submitted, and actually fresh - Structured data: valid JSON-LD, eligible for rich results - Mobile and responsive: you're being indexed mobile-first whether you like it or not - HTTPS and security: TLS, no mixed content - Site speed and Core Web Vitals: covered below, it's big enough for its own layer - Internal linking and architecture: crawl depth, orphan pages, sane anchor text - Rendering: does the rendered page match what you think you shipped

One honest caveat so you don't over-index on the wrong thing: HTTPS is a (minor) ranking signal, but specific security headers like CSP and HSTS are security best practice, not ranking factors. Do them because they're correct, not because you think they'll bump you up a spot.

Layer 4: Deep site crawls and rendered content

Here's the part most developers get wrong, and it matters more every year because we ship more JavaScript.

Google's pipeline is crawl, then render, then index. Every page that returns a 200 gets queued for rendering. Google runs a headless Chromium, executes your JavaScript, and indexes the rendered HTML, not just the raw source that came off the server.

That rendering step sits in a queue. Google's own docs say a page "may stay on this queue for a few seconds, but it can take longer." This is the reality behind the old "two-wave indexing" phrase people used to throw around. Google doesn't frame it as two fixed waves anymore, but the deferred-rendering queue is real and documented.

Two practical consequences:

1. Raw HTML and rendered DOM can differ, and the difference is what gets indexed. If your content only exists after a client-side fetch, Google has to render to see it, and rendering is deferred. Server-render or statically generate the content that matters. 2. Do not put `noindex` in the raw HTML of a page you want indexed and plan to "fix with JavaScript later." If Google sees `noindex` in the initial response, it can skip rendering entirely and never run your JS. You can't un-noindex a page client-side. We've watched this silently nuke real pages.

A deep crawl (Screaming Frog, Sitebulb, or your own script) is how you catch orphan pages, redirect chains, canonical conflicts, and raw-versus-rendered gaps before Google does.

Layer 5: Core Web Vitals

Core Web Vitals is the part of SEO that feels most like ordinary performance engineering. There are three, all measured at the 75th percentile of real user page loads:

| Metric | Measures | "Good" threshold | |---|---|---| | LCP (Largest Contentful Paint) | Loading | ≤ 2.5 s | | INP (Interaction to Next Paint) | Responsiveness | ≤ 200 ms | | CLS (Cumulative Layout Shift) | Visual stability | ≤ 0.1 |

Note the middle one. INP replaced FID (First Input Delay) as a Core Web Vital on March 12, 2024. FID only measured the delay of the first interaction. INP measures the latency of all interactions on the page, which is a much harder and more honest bar. If your mental model still says "FID," update it.

Why bother past the ranking nudge? Because speed is a conversion feature independent of Google. Google and Deloitte's "Milliseconds Make Millions" study (2020, 30M+ sessions) found that a 0.1-second improvement in mobile load time lifted retail conversions by 8.4% and average order value by 9.2%. An improvement of that size would justify engineering time in almost any product backlog. On a website, part of it may be sitting in an oversized bundle or a slow rendering path.

You can measure it without guessing:

```bash # Field data from the Chrome UX Report via PageSpeed Insights API curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com&category=performance&strategy=mobile" ```

Lab tools (Lighthouse) tell you what could be slow. Field data (CrUX, the `loadingExperience` block in that response) tells you what real users actually feel. Optimize against the field data.

Layer 6: Structured data and content

Once the page is fast and crawlable, make it legible, to both readers and parsers. On the machine side, that means structured data.

JSON-LD is Google's recommended format for structured data: a script block that describes the entities on your page using schema.org vocabulary. It's decoupled from your markup, so it's easy to maintain and hard to accidentally break with a CSS change.

```html ```

Match the schema to the content. Use a specific `LocalBusiness` subtype (`Restaurant`, `HealthClub`, and so on) for a physical business, `Organization` when there's no storefront, and `Article` / `BlogPosting` for content like this post. Valid structured data makes you eligible for rich results (review stars, FAQs, breadcrumbs, local packs). It's widely believed to help AI answer engines cite you too, and that's plausible, but we'll be straight with you: Google doesn't document it as a guaranteed mechanism, and structured data never guarantees a rich result even when it's valid. Do it because it's cheap and correct, not because it's magic.

And it isn't only Googlebot reading this anymore. AI answer engines and LLM-backed search pull from the same clean, server-rendered content and structured markup you'd build for a rich result. The work didn't change; the audience for it did. A page that's easy for a crawler to parse is easy for a model to quote. It does not require a separate "AI SEO" project. It requires the same clear content, rendered HTML, entity information, and technical accessibility the site should already have.

Layer 7: Lead handling

This is the layer people bolt on last and it's the one that actually touches revenue. Traffic has little value when a submitted lead sits unnoticed for hours. At that point, the site is recording demand rather than converting it.

The numbers on this are brutal and old enough to be settled. From the Harvard Business Review study "The Short Life of Online Sales Leads" (2011, audit of 2,241 US companies):

- Firms that made contact within an hour were nearly 7x more likely to qualify a lead than those who waited just one more hour, and more than 60x more likely than those who waited a full day. - The average first-response time across those companies was 42 hours. - 23% never responded at all.

Earlier MIT / InsideSales research (2007, vendor-commissioned, so grain of salt) put even sharper numbers on the first few minutes, with contact odds dropping up to 100x between a 5-minute and a 30-minute response. The exact figure is arguable; the direction isn't.

A new lead starts losing value almost immediately. The response does not need to be complicated, but it does need to be fast: acknowledge the request, qualify it, route it, and put it in front of the right person. It's the exact problem our Axion Deep Labs product Site2CRM automates: capture the lead, qualify it, and route it to a human the second it lands.

Layer 8: Distribution

Publishing is not distribution. A post can be live, indexed, and technically perfect while reaching almost nobody beyond the people who already visit the site.

The maxim we keep coming back to, popularized by Derek Halpern, is to spend 20% of your time creating content and 80% distributing it. It's a rule of thumb from one practitioner, not a study, and plenty of people argue it's closer to 50/50. The point survives the quibbling: most people pour everything into creation and nothing into distribution, then blame the content.

Distribution is its own work, so systematize it: syndicate the piece, link it from relevant answers, put it in front of people who'd actually use it. And rewrite it per destination, because LinkedIn isn't X and a dev community isn't Facebook. That per-platform rewrite is the exact job our Axion Deep Labs product Made4Founders was built to do. (One gotcha for anyone cross-posting: set `rel="canonical"` on the syndicated copy back to the original on your own domain, so you get the ranking credit instead of splitting it between two URLs.)

Layer 9: Revenue attribution

Every layer above is theater if you can't answer one question: which of this produced revenue?

Rankings are a proxy. Traffic is a proxy. Even leads are a proxy. Trace the path from query to landing page, from landing page to lead, and from lead to booked revenue. That is how you learn which page paid for itself and what belongs in the next backlog.

It's also the layer that kills tool sprawl on its own. Once you can see what converts, the 33% of your stack that touches nothing measurable becomes obvious, and easy to cut.

The point

You can assemble every tool in this article in an afternoon with a credit card. That does not give you a working system. The value comes from how information moves between the tools, what gets automated, and whether revenue feeds back into the next decision.

So stop shopping for the missing tool. You don't have a tool problem. Build the pipeline instead. Drawn out, the whole thing is one loop:

``` Research (Ahrefs) | v Backlog <-----------------------------+ (ranked pages, each tied to a query) | | | v | Build & write the page | | | v | Technical audit + deep crawl | (DeepAudit AI, Screaming Frog) | | | v | Core Web Vitals pass | (PageSpeed Insights / CrUX) | | | v | Publish | | | v | Distribute (Made4Founders) | | | v | Measure what converts (GA4) | | | v | Lead ops, fast response (Site2CRM) | | | v | Revenue --------------------------------+ (which query and page paid off feeds the next backlog) ```

Every arrow is a place the work flows or leaks. The tools just sit on the boxes; the value is in the arrows.

That's the stack. The tools are just the parts. The system is the job.

Want to see where your own pipeline leaks first? Start at the audit layer. Run the free audit on your site. It loads your pages in Chromium and inspects the rendered result, it's free, and there's no signup, so the report's yours to keep. If you'd rather read it together, book a free 15-minute teardown and we'll walk through what it found, no pitch.

Here is the challenge

Run your website through DeepAudit, fix what it finds, deploy the changes, and scan it again. Keep going until every category is green, or until you can clearly explain why a remaining warning should not be changed.

The second outcome counts too.

DeepAudit renders the page in Chromium rather than judging only the initial HTML. Google also renders with headless Chromium, so this catches JavaScript-dependent problems that raw-HTML checkers miss, though it is not a reproduction of Google's full crawling and indexing system. It grades the site from 0 to 100 across nine categories: Technical, Content, On-Page SEO, Social & Schema, Security, Performance, Accessibility, AI Readiness, and Local SEO.

The public scan is free and does not require an account or a credit card. Most sites we scan come back with several categories in warning or failure territory on the first run. Getting all nine green is hard on purpose.

What a score of 100 actually means

A perfect DeepAudit score does not mean your SEO is finished. It means the pages included in that run passed the checks currently represented in the scoring model. It does not measure whether the content deserves to rank, whether the business has enough authority, or whether visitors become customers.

A site can score 100 and still say very little.

The reverse matters too. A failed check is not an instruction. It is something to investigate. The right response may be to fix the page, to accept a deliberate tradeoff, or to find that the scanner misunderstood what it saw.

One hundred is not the outcome. It means nothing in the current ruleset failed on the pages that were tested.

Start with one page, then test the site

1. Run the homepage. Scan it at axiondeepdigital.com/free-seo-audit and save the starting score. It is the fast way in. 2. Read before you change anything. Every issue comes with a plain-language explanation. Review each one on its merits. Do not alter working code just to satisfy a generic rule. 3. Fix, deploy, rescan. 4. Then run the deep scan. A clean homepage does not tell you whether a service page has the wrong canonical, an article is missing from the internal-link structure, a biography has no main heading, or a lead form breaks after JavaScript loads. The deep scan samples up to 50 pages from your sitemap and internal links. Use it before calling the site clean. 5. Verify outside the score. Check Search Console, field performance data, structured-data validators, analytics, and the important pages by hand.

The audit begins the investigation. It does not conclude it.

What usually takes the most work

The early points are the easy ones. The last fifteen are where it bites.

Mobile performance is often the hardest category to clear. DeepAudit's Lighthouse run exposes heavy images, excessive JavaScript, blocked fonts, layout movement, and third-party scripts. That is a controlled lab test. Compare it with field data in PageSpeed Insights or Search Console before you decide what real visitors are experiencing, because lab and field results can differ significantly.

Metadata is usually easier to repair. Titles become repetitive, vague, or too long to display usefully. Descriptions go missing or fail to distinguish one page from another. Those are presentation and relevance problems, not simply character-count violations. Google builds title links from several sources and may rewrite yours anyway.

Headings need context. The real question is whether the page has a clear main topic and a logical structure that people, particularly those using assistive technology, can navigate. A vague main heading, headings chosen for their visual size, or skipped levels all make that harder. Multiple H1 elements should be reviewed in context rather than treated as an automatic failure.

Indexability is where small configuration mistakes become expensive. An accidental noindex, a canonical pointing at the wrong URL, blocked resources, or an important page with no crawlable links pointing to it can keep useful content out of the index or cause Google to select a version you did not intend.

Thin and JavaScript-dependent content. Some pages do not answer the query, add original information, or give a visitor a reason to choose the business. That is not a word-count problem, it is a question of whether the page does a distinct and useful job. Other pages contain good material that appears only after JavaScript runs. Google generally renders JavaScript, but rendering is a separate, deferred stage, and some non-rendering crawlers will only ever see the initial HTML.

You will not clear all of that in one sitting. Fix what is real, document what is deliberate, and keep moving.

We found problems in our own scanner

Before we put this challenge in front of anyone, we ran DeepAudit against axiondeepdigital.com. The site now scores 100 out of 100, A-plus, with all nine categories green and a 97 mobile PageSpeed score. You do not have to take our word for it. Run our domain through the same tool and watch the result come back live.

Getting there was not only about fixing our site. Two of the blockers were false positives inside DeepAudit itself.

The first involved the inline styles Next.js injects into optimized images. Those styles are part of how the framework works, and no developer can simply strip them from every image. The tool was counting them against image-heavy sites when it should not have.

The second was a crawler timing issue. The scanner waited for complete network silence, which never arrives on sites where analytics, widgets, or background requests keep firing. Healthy pages were being flagged as failures.

We traced both failures back to the scanner, corrected the rules, added regression tests, and ran the audit again. Only then did we publish the score.

Testing your own product against your own website is a dangerous loop if the goal is only to make the number turn green. The defensible version is to document why a rule was wrong and test the correction against sites other than your own. A scanner is not right merely because it produced a polished report. The tool is part of the review. It is not the reviewer.

Why this challenge matters

Most owners judge their site by how it looks to them. It loads fast on their laptop, the writing reads well, the design is clean, so the foundation must be sound.

The audit adds the views you do not get from opening your own homepage: rendered markup, mobile lab performance, structured data, accessibility checks, security headers, and crawlability signals. That view is usually less flattering, and far more useful.

Join the challenge

Run your homepage. Save the first score. Fix what the evidence supports, then run the deep scan and check the important pages by hand.

When every category turns green, post the result and tag Axion Deep Digital. More importantly, show what you changed to get there. A perfect score is interesting. The work behind it is useful.

If you get stuck, the report will show which checks are still failing. Then decide whether each one is a real defect, an acceptable tradeoff, or something the scanner misunderstood.

Join the 100/100 SEO Challenge: axiondeepdigital.com/free-seo-audit

We built DeepAudit AI to produce a useful website audit in about a minute, without requiring an account or a sales call.

The next request was obvious. People wanted the result inside the CRM, spreadsheet, or project system where they were already working. DeepAudit AI is now publicly available on Zapier, in beta.

What the Zapier action returns

The Run SEO Audit action takes a publicly accessible URL and returns the audit as mappable fields: the score and letter grade, a plain-language summary, the top issues, the per-category scores, a link to the full report, a PDF, and how many audits remain on your key this month. A second action, Get Audit Report, retrieves an existing result by audit ID when a later step in the workflow needs it again.

DeepAudit loads the page in Chromium and lets JavaScript content render, then checks technical SEO, metadata, page structure, indexability, performance, accessibility, and structured data. You can run the same thing by hand at axiondeepdigital.com/free-seo-audit.

It is still an automated audit. It tells you where to look. It does not decide what should change.

The workflow we built first

Our first use case was lead research.

When a prospect submits a form, the Zap sends their website URL to DeepAudit. The score, top findings, report link, and PDF are written back to the lead record before we ever open it. The first conversation then starts with something specific: this site has no meta descriptions, or its content does not survive rendering, or its mobile performance is failing.

The tool does not write the pitch. It removes the manual work of copying a URL into an audit tool, waiting, and pasting the report into the CRM.

Other workflows worth building

Keep a history. Write each completed audit to Google Sheets or Airtable with the domain, date, score, and top findings. Over time that shows an agency which client sites improved and which ones slipped.

Watch for changes. Run audits on a schedule and post the result to Slack. When a score moves, someone should look at the underlying findings and work out whether the site changed, the scanner changed, or the run needs repeating. A lower score is a prompt to investigate, not proof of a regression.

Assign the work. Create a task from the findings, attach the report, and give it to whoever is responsible for reviewing it.

One thing we would not automate: sending audit findings straight to a client. Keep outbound email behind a human approval step. An audit tool can be wrong, and an automated finding should not become a confident client recommendation before someone has checked it.

Note the shape of all of this. DeepAudit is the action, not the trigger. Something else supplies the URL, whether that is a form submission, a CRM record, a spreadsheet row, or a schedule. DeepAudit returns the audit data. The rest of the Zap decides where that data belongs.

How to connect it

1. Request a free API key at axiondeepdigital.com/api-access. Enter your email, open the magic link, and the key appears. The free tier is 10 audits a month. 2. In Zapier, open the DeepAudit AI listing and connect it with that key. 3. Pick the event that supplies the website URL, add the Run SEO Audit action, and map the returned fields into the CRM, spreadsheet, Slack message, or task that should receive them.

Why it is still marked beta

The integration is usable today, but the beta label is deliberate. We are watching for failed runs, edge-case URLs, confusing field names, and places where the returned data is awkward to map into another app. If something breaks, send us the workflow, the target URL, and the error, so we can reproduce it.

The integration is most useful when the audit is not the end of the process. Run it when a lead arrives, keep the result with the lead, and give someone a clear next action. Automation should remove the copying and the routing. It should not remove the review.

We wrote at the time that we were not going to chase the last five points, because the remaining work was worth more than the score. That was the right instinct and the wrong conclusion, and it is worth showing why.

What the five points actually were

We had never looked closely at them. When we did, here is what was costing the score:

| Page | Warning | Words | |---|---|---| | /gallery | Thin content | 53 | | /reviews | Thin content, plus H1 keywords underused | 58 | | /about | Thin content | 176 | | /menus | Meta description at 203 characters | 460 |

Four of those five points were not vanity points. They were the content work we already owed the client.

A gallery with 53 words shows the food and explains nothing: not the event, not the service, not the menu behind it. An about page with 176 words does not tell a family in Pueblo who is cooking. Those were real gaps, and the scanner happened to be pointing at them.

Only the /menus meta description was a pure score fix. One line, 203 characters trimmed to 153.

So we did the work. We expanded the gallery, the reviews page, and the about page with real copy, and we shortened the meta description.

Where it landed

The deep scans, in order: 83, 95, 95, 99, 98.

Today the site is 98 out of 100, an A+, with all fifteen pages healthy and zero issues. Coverage is 100 percent on H1 tags, meta descriptions, canonicals, and schema.

We are not going to pretend the last two points were a strategy. The score went to 99 and settled at 98, and the fact that it moves a point on its own is a decent argument against treating any of this as a finish line.

The last two points are one page, and it is short on purpose

Content coverage sits at 93 percent. Fourteen of the fifteen pages clear 300 words. One does not.

It is the reviews page, at 289 words. Eleven words short.

We are leaving it there.

Pueblo Catering is a new family catering business. It does not have a wall of reviews yet, because it has not catered enough events yet. The honest version of that page says so, invites people who have already hired them to leave a review, and explains what the family works to earn every time they cook. It is a genuine empty state.

We could pad it. Eleven words is nothing. We could also fabricate a few testimonials and switch on the Review and AggregateRating schema the page is already built to support, and the score would go to 100 tomorrow.

We are not doing either. Google's guidelines disallow self-serving review markup, and inventing customer quotes for a business that is still earning its first ones is not a thing we are willing to do for two points on a report we generate ourselves.

When Nick has real reviews, they go on the page, the schema goes live, and the word count takes care of itself. Until then, the page is honest and the score is 98.

What this actually taught us

Our original argument was that the last five points were not worth chasing. That was wrong in the specifics. Four of them were real content gaps, and the audit found them.

But the underlying instinct still holds, just not where we first pointed it. The score was never the thing to protect. It was a reasonably good pointer at work that needed doing, right up until the moment it started asking us to pad a page or fake a testimonial.

That is where an audit tool stops being useful and starts being something you have to argue with. A scanner cannot tell the difference between a page that is thin because nobody wrote it and a page that is thin because there is nothing honest to say yet. Only a person can do that.

Sites drift, so we keep scanning. We have written before about how one footer link produced 48 audit warnings on our own site, run by people who do this for a living. Holding a 98 is not doing nothing.

But the growth work now sits entirely outside the score: real event photography as it comes in, the questions people actually ask before booking a caterer, how much food to order, what a taco bar includes, what changes the price, and getting those first real reviews.

A 100 on a checklist does not book a single event. A page that answers a real question for a real person in Pueblo does.

See where your own site stands

Run the free audit on your site. It loads your pages in Chromium and inspects the rendered result, it is free, and there is no signup, so the report is yours to keep.

Then argue with it. When it tells you a page is thin, read the page and decide whether the tool is right. Sometimes it is pointing at work you owe. Sometimes it is asking you to pad something that is fine. Knowing the difference is the job, and no scanner does it for you.

If you would rather read it together, book a free 15-minute teardown and we will walk through what it found, no pitch.

A caterer was getting started in Pueblo, Colorado. Before we picked a logo or built a page, we made one decision that shaped everything after it: we chose the public name Pueblo Catering and registered pueblocatering.com for fifteen dollars.

The domain was sitting there, unregistered, at the standard price. No premium markup, no auction, no broker. It matched one of the simplest ways a local customer might describe what they need: Pueblo catering.

That made it worth buying. It did not make it an SEO shortcut.

We chose clarity over cleverness

Businesses choose names for all kinds of reasons. Some are personal, some are distinctive, and some only make sense once the company is already familiar. In this case we had the freedom to consider the name and the domain together.

Pueblo Catering says the location and the service immediately, and the website uses the same words. There is very little to explain. Someone hears the company name and already knows the address.

That clarity comes with a tradeoff, and it is worth naming. A city-plus-service name is highly descriptive, which can make it harder to distinguish from competitors and harder to protect. Descriptive and geographically descriptive marks are weak, and they are difficult to register unless they acquire distinctiveness over time. Nothing stops another caterer in town from using similar language.

So a domain being available does not mean the name is clear to use. Before committing, search existing businesses, federal and state trademark records, Secretary of State filings, Google Maps, the major directories, and social handles. Then ask whether the name still works if the company expands into new cities or new services.

We traded some distinctiveness for immediate clarity. For this business, at this stage, we thought that trade was worth fifteen dollars.

The domain is relevant, but it is not authority

Here is where most "buy a keyword domain" advice goes wrong, so we will say it plainly.

Google does consider the words in a domain as one of many relevance signals. It also runs an exact-match-domain system designed specifically to stop a site from getting too much credit just because its address matches the query. Before that existed, owning bestcheapcaterer.com could float a thin, useless site to the top. So if anyone tells you a keyword domain is an SEO cheat code, they are selling you 2011.

A descriptive domain cannot rescue an unhelpful website. The business still needs useful pages, local relevance, credible evidence, links, reviews, and a site people can actually use. Buy pueblocatering.com, put up an empty page, and you have an empty page with a nice address.

So what did the fifteen dollars actually buy?

What the fifteen dollars actually bought

The name is easy to say. A caterer's best marketing is a guest at a wedding asking who did the food. "Pueblo Catering dot com" survives that conversation. The name and the address are the same phrase, so there is less to misspell or misremember.

The service and the location are obvious. Someone seeing the domain for the first time does not have to decode an unfamiliar brand before deciding whether the result is relevant to them.

The identity is consistent. The business name, the domain, the page headings, and the profiles can all use the same words.

What we bought was clarity. That was enough to justify the registration. Whether it produces more clicks or better rankings is a separate question, and one we will answer with Search Console impressions and actual leads rather than by assuming the domain caused them.

The clarity may also become limiting. A name that perfectly describes one launch market gets awkward if the business grows past it. That is a real cost, not a footnote.

Do not buy a second domain expecting free rankings

If you already have an established brand, a matching descriptive domain can still be worth owning for brand protection, offline campaigns, or preventing confusion.

But pointing a newly registered keyword domain at your main site does not create an SEO advantage. A redirect is useful for consolidating a domain that already has visitors, links, or history worth preserving. A domain registered this morning has none of that to transfer. Keep one primary domain, redirect the legitimate variants to it, and do not build duplicate copies of the site across several addresses.

Check more than availability

Start with the language customers actually use. Look at inquiries, reviews, sales calls, Search Console queries, and how competitors describe the same service. Then test combinations of location, service, and brand.

Then ask:

- Is it short enough to say out loud? - Can someone spell it after hearing it once? - Does it still work if the business grows? - Is a similar company already using the name? - Can the name be protected, or is it so descriptive that anyone can use a variation? - Has the domain previously hosted spam or unrelated content?

Favor .com. Skip hyphens and numbers, which get lost the moment someone says the address aloud. For a domain with history, inspect its archived content, its backlinks, and whether it is still indexed. Google's spam policies specifically address expired domains repurposed to manipulate rankings, so a cheap domain with a past is not automatically a bargain.

If the exact match is taken or carries a premium price, we would rather own a clean, memorable variation at the normal price than spend thousands chasing a theoretically perfect one.

The domain solved one problem

Once we owned pueblocatering.com, the naming decision was finished. The website still needed menus, service details, local proof, photography, usable forms, crawlable content, and an obvious path to request a quote.

We also checked the rendered page and the raw HTML separately. In our study of 368 small-business websites, the raw HTML available to a non-rendering crawler omitted at least one answer-critical element on one in four sites. Not every AI system retrieves a page the same way, but it shows why a phone number, a service, or a location should not depend entirely on client-side JavaScript. A perfect domain cannot help a system understand information it never receives.

So we do the unglamorous half too. Our DeepAudit scan loads the page in Chromium and inspects the rendered result rather than judging the initial HTML alone, and we compare the two when crawler visibility matters. Then we open the important pages ourselves, because an automated report is evidence, not a verdict.

The domain made Pueblo Catering easy to name and easy to find. The business still has to earn everything that happens after that.

See what your own site is worth

If you are about to start a business, spend the afternoon finding the right domain before you build. If you already have a site, the more useful question is whether it earns the visits your domain brings it.

Run the free audit on your own site. It loads your pages in Chromium and inspects the rendered result, it is free, and there is no signup. The report is yours to keep. If you would rather we look at it together, book a free 15-minute teardown and we will walk through what it found, live, no pitch.

The new report showed the same warning on 48 of the 50 URLs it checked. Forty-eight warnings looked like a sitewide mess. They were all coming from one shared component.

Our first instinct was not to start clearing warnings one at a time. When the same issue appears on almost every page, the pages are usually not the problem. Look for what they share.

One label, two different destinations

The words "DeepAudit AI" appeared in two global places.

In the navigation, the label pointed to the public DeepAudit page. In the footer, the same label pointed to an internal results screen that we had deliberately marked noindex. The navigation and the footer render on nearly every page, so that single inconsistency repeated itself across the whole crawl.

To be clear about what was and was not wrong here. There is no rule that a phrase must always point to one URL. A person's name can link to a biography in one place and an author archive in another. "Contact us" can reasonably route to a general form or to a location-specific page.

The problem was that an identical global label set the same expectation and then sent people to two functionally different places. One was the public product. The other was a utility screen we had already excluded from search, which meant we were featuring a sitewide path to a page nobody was meant to land on.

The actual code change was one line: point the footer link at the public page.

Forty-eight warnings did not need forty-eight fixes

This is the part worth keeping.

When the same warning appears across dozens of pages, they may all be inheriting it from one navigation component, footer, layout, template, or injected script. Editing 48 pages by hand would have burned a day and probably introduced new inconsistencies.

We traced the warning back to the shared footer, corrected it once, and it disappeared everywhere that component rendered.

What we cannot honestly claim

We changed more than the footer before the next full scan. We reviewed the rest of the internal links, trimmed a few page titles that had grown too long, and expanded one page that was too thin to be doing any real work.

The score came back to 100.

But because those changes shipped together, we cannot honestly assign the entire six-point recovery to that one line. We know the footer caused the 48 repeated warnings, because the warnings named the component. We did not isolate the footer change and rescan before bundling in the rest, which is exactly what we should have done, and what we do now.

The useful result was never the number. It was learning that one shared component can make a single mistake look like 48 separate problems.

A second tool disagreed, and neither was lying

Afterward we ran the same homepage through another well-known SEO tool. It returned a dozen warnings on the page that had just scored 100. Duplicate headings. Too many headings. Repeated links.

That looked like one of the tools had to be wrong. The real explanation is more interesting: they were not looking at the same version of the page.

The other tool counted elements in the initial HTML response. DeepAudit loads the page in Chromium and inspects the rendered DOM. Those are not the same document. Google encounters the initial response before it renders JavaScript, so a source-level warning should not be waved away just because the rendered page looks clean. Equally, a raw-HTML checker can report duplicates that never cause a problem for anyone.

The disagreement was evidence. We still had to decide what it meant.

The warnings pointed at an architecture question

Those duplicate headings came from a choice we make on purpose. We put a simplified copy of the important content in the initial HTML so that systems which do not execute JavaScript still receive something useful. In our study of 368 small-business websites, one in four omitted at least one answer-critical element from that raw response. We did not want to be one of them.

But it means some checkers see the fallback content and the rendered interface, and count the headings twice.

The long-term answer is not to teach every audit tool to ignore the duplicate. It is to server-render or statically generate the important content once in the initial HTML, then hydrate the interactive parts around it. That gives users, search engines, and non-rendering systems one strong base document instead of two competing versions of the page.

A warning does not always mean "delete the thing the tool found." Sometimes it means the architecture deserves another look.

What changed in how we work

Four things came out of this, and they matter more than the six points.

Group repeated warnings before fixing anything. When one rule fires across dozens of pages, check the shared navigation, footer, templates, and injected scripts before you open a single page.

Test a suspected cause in isolation. Change the one thing, rerun the scan, confirm the expected warnings disappear, and only then bundle in unrelated cleanup. We did not do this, and it cost us the ability to make a clean claim about our own story.

Record which representation the tool inspected. Raw response, rendered DOM, lab performance, field data, or the indexed version in Google. Two tools can disagree without either one being wrong, because they never examined the same artifact.

Turn the fix into a guardrail. Global navigation and footer links now get checked for destination, status code, canonical target, and indexability before deploy, so the same class of mistake cannot quietly come back.

The code fix took a minute. Making the mistake harder to repeat took longer.

Check the pattern, not just the score

Run the free audit on your own site. It loads your pages in Chromium and inspects the rendered result, and it will show you when the same finding repeats across dozens of URLs.

When that happens, do not open dozens of pages and start editing. Find what they share. The tool can show you the pattern. The investigation is still yours.

If you would rather we read the report with you, book a free 15-minute teardown and we will go through what it found, live, no pitch.

It saved time. It also produced posts that technically fit everywhere and felt native nowhere.

Shortening a post is not the same as adapting it. A shorter LinkedIn post is still a LinkedIn post, even when it fits inside X's character limit.

The mistake is starting with length

Character limits are only the most visible difference between platforms. The harder differences are how the content gets discovered, what format surrounds it, what the audience needs from it, and what they can actually do after they see it.

The same idea might need to start a discussion on LinkedIn, answer a search on YouTube, earn a save on Pinterest, or give a private community something useful without sending anyone away from the conversation.

That is not shortening. That is changing the job.

One real finding, five different jobs

We published a study comparing the rendered and raw versions of 368 small-business websites. The finding was simple: one in four lost at least one answer-critical element when JavaScript did not run.

That finding stayed the same everywhere we posted it. Almost everything around it changed.

LinkedIn: give people something to challenge. We led with the method and the most arguable result.

> We checked each site twice: once rendered in a browser, once from the initial HTML. One in four lost important content. The surprising part was not WordPress. In our sample, the broad custom-built category performed worst.

That works because the audience can inspect the claim, question the sample, and argue about what "custom" even means. The discussion is part of the post.

X: make one claim survive without the setup. There is no room to rebuild the article, so the opening post has to stand alone.

> We compared 368 rendered websites against their raw HTML. One in four lost important content when JavaScript did not run. Custom-built did not automatically mean crawler-safe.

The thread or the linked study carries the caveats.

Pinterest: build something worth saving. This one is not a caption rewrite. The study becomes a vertical graphic, "5 Things AI Crawlers May Be Missing From Your Website," covering body copy, headings, navigation, contact details, and forms. The Pin points at the full study.

The title and description help Pinterest interpret the subject, but the graphic has to carry the value before anyone opens the destination.

YouTube: demonstrate the difference. A YouTube version needs a video before it needs a description. The opening shows the same homepage twice, the full rendered page beside the nearly empty source response, then explains the test, shows the platform table, and ends with the View Source check anyone can run in thirty seconds.

The title, the thumbnail, the opening seconds, and the description all have to make the same promise. A description alone does not turn a text post into video.

Slack, Discord, and Telegram: bring the answer into the room. A public post is often built to earn a click. A private community update usually works better when the useful part is already in the message.

> Quick check for anyone running a React site: open View Source and search for your phone number, your main heading, and your nav links. If they are missing from the source, a non-rendering crawler may be receiving a much weaker version of your page.

The link becomes supporting evidence rather than the point.

Five destinations, five different jobs. None of them is the long version or the short version of another.

Why this matters most when you post least

It is tempting to treat this as a nuance for large content teams with bandwidth to spare. It is the opposite.

A small business publishing twice a week gets roughly a hundred posts a year. Repeating the same caption in ten places does not create ten experiments. It creates one experiment, copied ten times. When publishing capacity is limited, each version should be built for the place it is going rather than treated as leftover copy from somewhere else.

Pinterest and YouTube both have real search surfaces, so the language in titles and descriptions should match how people look for the topic. That does not make their ranking systems identical to Google's. It means discovery language matters in more places than your website.

The tool can build the draft. It cannot choose the job.

Made4Founders currently posts to 10 channels and generates a separate draft for each one, enforcing the mechanical requirements as it goes: character limits, required media, destination fields, formatting. That removes the tedious part, which is rebuilding the same container ten times.

It does not decide whether a finding deserves a confrontational LinkedIn post, a five-slide Pinterest graphic, a YouTube demonstration, or no post at all. We still make that call, and we still read every version before it goes out. A draft can hit the character limit, fill every required field, and still sound wrong for the person posting it.

The tool understands the container. A person has to understand the point.

Start with the job, not the length

Before moving a post to another platform, decide what it needs to do when it gets there. Should it start a discussion? Answer a search? Earn a save? Show something visually? Give an existing community a useful update?

Then rebuild the post for that job.

The idea can stay the same. The post usually should not.

The hard part was never the idea. It was everything after it. Open another dashboard, paste the caption, repair the formatting, shorten it for one platform, rewrite it for another, find the image again, check the date, switch brands, repeat.

We were also paying for several versions of what was essentially the same calendar.

So we built our own. Made4Founders started as the system we used internally to keep the work around several businesses in one place. Social scheduling turned out to be the piece we leaned on most, so we opened a limited version of it for free.

One disclosure up front: Made4Founders is our own Axion Deep Labs product. We use it at Axion Deep Digital, and we benefit if a free user eventually upgrades. That should be clear before we tell you what is in the box.

What the free plan actually includes

- 3 connected channels. X is not one of them: the X API requires a paid plan on our side, so it is blocked on free. - 15 scheduled posts a month, and 5 saved drafts. - The content calendar, in full. - 3 AI platform adaptations a month. Enough to see what the per-platform rewrite does, not enough to run a brand on. - No credit card, and nothing expires.

Analytics, the unified inbox, and the rest of the founder tools are paid.

Free posts also carry a small "via Made4Founders.com" line. That is the trade: the free tier advertises itself. You should know that before you connect an account, not after.

The free plan is built for one person keeping a small, steady schedule. It is not built for an agency posting daily across a dozen brands. If that is you, the free tier will run out fast, and it is supposed to.

Where the paid line actually falls

Starter is $49 a month and raises you to 5 platforms, 30 posts, basic analytics, and X. The "via Made4Founders.com" line is still appended at that tier.

Growth is $99 and includes all 10 currently supported destinations, 100 posts, full analytics, the unified inbox, and no attribution line.

Flat pricing, no per-seat charge, no annual contract. If the free limit is enough for you, there is no reason to upgrade, and we are not going to pretend otherwise.

Why we did not build another copy-and-paste scheduler

The first version just scheduled posts. That fixed the calendar problem and left the repetitive part completely intact.

A LinkedIn post does not become an X post because it fits in 280 characters. Pinterest needs an image and a reason to save it. YouTube wants different fields entirely. Slack and Discord are community updates, not public-feed posts.

So Made4Founders starts from one base idea and generates a separate draft for each destination you pick, handling the mechanical requirements as it goes: length, structure, platform-specific fields.

Then it shows you every version before anything is scheduled. We read all of them. The software knows the technical requirements of the destination. It does not know whether the claim is supported, or whether the post sounds like the person whose name is on it. The tool removes the formatting work. It does not get the final say.

How it compares

Buffer has a genuinely good free plan, and depending on how you work it may be the better choice. It currently gives you three channels with 10 queued posts per channel, plus drafts, a calendar, an AI assistant, and basic analytics. In some categories it is more generous than ours.

Hootsuite and SocialPilot are aimed squarely at paid social management, and both currently offer trials rather than a comparable free-forever plan.

Our difference is not that nobody else can schedule a post or run an AI rewrite. It is that this scheduler sits inside the system we already use to run several businesses, and the AI workflow starts from one real idea and builds separate drafts for the destinations we choose.

That is useful to us. It may or may not be useful to you. Plans and pricing here were checked in July 2026, and everyone's change over time, so verify before you choose.

Start without a card

Create an account, connect a supported channel, write the post, read the platform version, and pick when it goes out.

We built the scheduler because we needed it. Opening it costs us infrastructure and support, and it gives founders a low-risk way to try the larger product. That is the whole arrangement. No countdown, no claim that it replaces every tool for every business.

Start free at Made4Founders.

One disclosure, because we believe in it: Made4Founders is our Axion Deep Labs product, and we use it here at Axion Deep Digital to run our own marketing, so yes, we are recommending our own tool. We also made it free, which means you can judge it yourself without spending a cent.

That gap matters because not every crawler executes the JavaScript that builds a modern page. Google queues successful pages for rendering and runs them through Chromium. Independent testing by Vercel found that several major AI crawlers fetch a page without executing the client-side JavaScript needed to construct its content.

It is also worth being precise about which crawlers we are talking about, because the names get collapsed. OpenAI runs several: GPTBot for potential training data, OAI-SearchBot for ChatGPT search, and ChatGPT-User for certain user-triggered visits. Perplexity separates PerplexityBot, which supports its search results, from Perplexity-User. "The crawler behind ChatGPT" is not one thing.

We wanted to know how often the rendering gap hides something that actually matters on ordinary small-business websites, so we measured it.

What we tested

We attempted dual captures of 405 North American small-business websites and obtained usable results for 368, a 90.9 percent response rate. Each site was fetched twice on the same pass.

The first capture loaded the page in headless Chromium and let its JavaScript execute. The second made a direct HTTP request with a GPTBot user agent and did not execute JavaScript. We then compared the rendered DOM against the initial HTML response and flagged any answer-critical element that appeared in one and was missing or substantially reduced in the other: body copy, headings, internal links, business name, address, phone, email, structured data, and contact or booking forms.

One framing note, because this subject is easy to overclaim. This does not reproduce Google's infrastructure, and it is not a recording of what happens inside ChatGPT, Claude, or Perplexity. It measures the difference between a browser-rendered page and what a non-rendering direct fetch receives. It is not a claim that "ChatGPT cannot know you exist." Those assistants also draw on search indexes, licensed feeds, cached material, and third-party citations. The direct-crawl path exists, and this study isolates one failure mode within it.

The sample was purposive, not random. The full methodology and the open dataset are here.

One in four sites lost something important

Of the 368 analyzable sites, 92 (25.0 percent) contained at least one answer-critical element that appeared in the rendered page but was absent or substantially reduced in the initial HTML.

Body copy was the most frequently affected: on 57 sites (15.5 percent), the words explaining what the business does appeared only after JavaScript ran. Internal links were affected on 51 sites (13.9 percent), which matters because crawlable links are one of the main ways any system discovers the rest of a site and understands how it is organized.

At least one name, address, or phone element was missing from the raw response on 54 sites (14.7 percent). That does not mean the direct fetch received a blank page. It may have received the business name without the address, or the service description without the phone number. For a local business, a partial loss is enough to matter.

The platform result was not what we expected

The usual advice is that hosted builders are bad for SEO and a custom build gives you control. That is not what the platform breakdown shows, but the honest version is more careful than a reversal.

| Platform | Affected | Rate | |---|---|---| | Wix | 1 of 35 | 2.9% | | Webflow | 1 of 15 | 6.7% | | GoDaddy | 4 of 20 | 20.0% | | WordPress | 37 of 139 | 26.6% | | Squarespace | 13 of 46 | 28.3% | | Other / Custom | 34 of 107 | 31.8% |

Read the counts, not just the percentages. Wix and Webflow had the lowest observed rates, but each had exactly one affected site. The difference between 2.9 percent and 6.7 percent is mostly the size of the denominator, and neither cell is large enough to crown a platform. Six further sites sat in cells too small to report at all.

The Other / Custom category needs the same caution in reverse. It is a catch-all holding everything from hand-coded static HTML to heavily client-rendered single-page applications. Its 31.8 percent is not evidence that custom development is the problem, because a well-built server-rendered custom site can expose far more useful initial HTML than any hosted builder.

Squarespace is a builder and still sits near the top of the risk list, which is the tell. The platform label was not the mechanism. The mechanism was simply whether important content appeared in the HTML before JavaScript ran. Wix and Webflow tended to do that in this sample. Many affected WordPress, Squarespace, and custom implementations did not.

How to check your own site

You do not need a tool for the first pass. Open your homepage, right click, and choose View Page Source. Do not use Inspect for this test: Inspect shows the live DOM after the browser has run the scripts, while View Source shows the HTML that arrived before they ran. That difference is the whole point.

Search the source for your main heading, a sentence of your body copy, your phone number, your address, and your navigation links.

If you can see that information on the page but cannot find it in the source, client-side rendering is the most likely explanation. Treat that as a reason to inspect the network response and the rendering path, not as a final diagnosis: text can also be encoded differently, serialized into a data blob, or loaded in an iframe in ways a simple search will miss.

Google attempts to render successful pages and can index JavaScript-generated content when that process completes. A crawler that never executes the scripts only ever receives the initial response.

Put the important information in the initial HTML

The safest principle is to server-render or statically generate the content a person or a crawler needs to understand the business: the main copy, headings, navigation, contact details, canonical metadata, and structured data.

That usually does not mean a rebuild. JavaScript can still power forms, calculators, filters, and chat. It should enhance the page rather than be the only way its core information ever exists. Google can render JavaScript and still recommends server-side rendering, static rendering, or hydration, precisely because not every crawler has Google's rendering infrastructure.

Do not let a client-side widget be the only path to reach you.

Compare both versions of your own page

DeepAudit loads the page in Chromium, captures the rendered DOM, and compares it with the initial HTML response. It flags meaningful differences in body copy, headings, links, contact details, forms, and structured data.

A difference is not automatically a defect. It tells you which information depends on rendering, and then you decide whether that dependency is acceptable.

Run the free audit on your own site. It is free, there is no signup, and the report is yours to keep. If you would rather we read it with you, book a free 15-minute teardown and we will walk through what it found, live, no pitch.

Here is exactly where they came from, because a benchmark is worthless if you cannot see how the sample was drawn. We queried the OpenStreetMap Overpass API for businesses inside a 12-kilometer radius of the Las Cruces city center that publish a website, dropped national chains and aggregators, deduplicated the domains, and ran the surviving homepages through the scanner. That produced 60 candidate sites, of which 51 returned a complete audit. Restaurants, contractors, clinics, retailers, the kind of place a local actually searches for on a phone.

This is a purposive sample, not a census of Las Cruces and not a random one. It describes these 51 sites.

The median score was 67 out of 100. Thirty of the 51 scored below 70. None reached 90.

Every percentage below counts hard failures only. Warnings are excluded, so the real number of sites with room to improve in each category is higher than what you see here.

Las Cruces is not uniquely behind

Some context first, so nobody feels singled out. In our national study, 191 of 292 audited sites returned valid mobile Lighthouse data, and 96.9 percent of those failed at least one of the three Core Web Vitals thresholds we tested. Small business websites are in rough shape almost everywhere.

What the widespread failure rate means is narrower than it sounds. A business that fixes these issues will have a better website than many of its local competitors. Whether that produces local rankings depends on the query, the searcher's distance, the Google Business Profile, reviews, categories, and prominence, none of which this scan measured.

Accessibility failures were nearly universal

Fifty of the 51 homepages triggered at least one accessibility failure, and the category averaged below 50 out of 100.

The most common single issue was a missing visible focus indicator, on 34 of the 51 sites. A focus indicator shows a keyboard user which link, button, or form field is currently active. Without one, someone navigating with the Tab key cannot tell what will happen when they press Enter.

That is a genuine barrier for the people it affects, and it may contribute to ADA exposure for a business open to the public. Fix it because people need the site to work, not because a scanner turned red. An automated scan cannot certify a site as accessible or inaccessible either way. It shows you where a manual review should start.

It is invisible to most owners, because the site looks fine when you click around with a mouse.

llms.txt was rare, but that is not the same as AI invisibility

Thirty-seven of the 51 sites had no llms.txt file.

We are reporting that as a file-presence observation and nothing more. llms.txt is a proposed convention, not an established protocol like robots.txt. Its absence does not mean ChatGPT, Claude, or Perplexity cannot find a business, and adding one does not mean any of them will recommend it. Our later work found that most of these files are emitted automatically by a platform or plugin rather than written by the business at all.

The question that actually matters is whether the site publishes its services, location, people, and contact details in crawlable HTML, and whether those facts agree with the business's external profiles. This scan did not test whether AI assistants recommend any of these 51 businesses.

The basics were missing on a lot of them

- Main heading failed on 32 of 51 sites. Absent, empty, or otherwise failing the heading rule. A clear primary heading helps both visitors and search systems understand the page. Multiple H1s are worth reviewing in context rather than treating as an automatic defect. - No LocalBusiness structured data on 44 of 51. Organization or LocalBusiness markup makes your name, address, hours, and service area explicit rather than inferred. It does not replace a complete Google Business Profile, and it is not what the map pack runs on. - No meta description on 24 of 51. Google generates snippets from page content and may use your description when it summarizes the page better. Writing one gives you influence over that, not control. - Under 300 words on 24 of 51. That is the scanner's threshold, and it is a screening flag, not proof a page cannot rank. A short contact page can rank fine. The question is whether the page answers a distinct question and gives a visitor enough to decide.

Some of these are one-line changes. Others need real content or template work. The report should tell you which is which.

Security, speed, and prominence

Thirty-four sites returned no HSTS header, a browser security control for HTTPS sites. About half served at least one compressible resource without gzip or Brotli. Both are worth fixing on their own terms. Neither one earns a ranking.

On performance, a caveat matters more than the number. Only 10 of the 51 sites returned valid mobile performance data, and 8 of those 10 scored below 50. That is a real signal about the sites we could measure, and it is a small sample. Lighthouse is a lab test on a simulated device, not a recording of what an actual phone on an actual network in the Mesilla Valley experienced. Treat a low score as a reason to look at images, JavaScript, fonts, and server response time, then check the field data in Search Console before rebuilding anything.

Thirty-nine of the 51 scored near the bottom of the Open PageRank proxy, which is normal for small local sites with few backlinks. Open PageRank is a third-party estimate, not Google's PageRank, and it is useful for rough comparison rather than as an authority score. For most local businesses here, accurate business information, useful service pages, real reviews, and a complete Google Business Profile are higher-priority work than chasing links.

What the sample does and does not tell us

The median site in this sample had several detectable technical and usability problems, and the same categories kept recurring: accessibility, structured data, headings, metadata, security headers, and performance where we could measure it.

Fixing them gives a business a cleaner technical foundation and a better experience for the person who lands on the page. It does not guarantee a map-pack placement, and it does not come with a timeline. Google says local results are based mainly on relevance, distance, and prominence. Your website is one input to that. Your Business Profile, reviews, categories, location, and the searcher's own position are others, and none of them are things this scan looked at.

What happens to rankings and calls afterward has to be measured, query by query, after the work ships.

Check your own site

These 51 businesses were selected by the procedure at the top of this post, not hand-picked, but the sample is small and local and should not be read as a verdict on every business in the city.

Run the free audit on your own site. No signup, no credit card, and the report is yours to keep. Then open the important pages and check the findings yourself, because an automated report tells you where to look and not much more. If you would rather we read it with you, book a free 15-minute teardown and we will walk through what it found, live, no pitch.

Where they came from, since a benchmark is worthless if you cannot see how the sample was drawn: we queried the OpenStreetMap Overpass API for businesses within a 16-kilometer radius of the El Paso city center that publish a website, dropped national chains and aggregators, deduplicated the domains, and scanned the surviving homepages. That produced 60 candidates, of which 52 returned a complete audit. Restaurants, clinics, contractors, retailers, service businesses across the borderland.

This is a purposive sample, not a census of El Paso and not a random one. It describes these 52 sites. Every percentage below counts hard failures only, so the number of sites with room to improve in each category is higher than what you see here.

The median score was 68 out of 100. Twenty-seven of the 52 scored below 70. None reached 90.

The median was less interesting than the repetition. The same few findings appeared across most of the sample.

Every audited page triggered an accessibility failure

All 52 of them, and the accessibility category averaged 45 out of 100, the lowest of any category.

Missing or inadequate focus indicators showed up on 40 sites. A visible focus state is what tells a keyboard user which link, button, or field is currently active. Without it, someone navigating with the Tab key cannot tell what will happen when they press Enter.

Link-label problems showed up on 36. In those cases the purpose of a link is not clearly available from its text or its programmatic context, which makes it harder for someone using a screen reader, or tabbing through a list of links, to work out where each one goes.

These are not cosmetic warnings. They decide whether a visitor can identify controls and move through the page at all. An automated scan is also not a complete accessibility audit. It tells you where manual keyboard and screen-reader testing should start.

Only 4 of the 52 declared a Spanish version

El Paso's language profile makes this worth measuring rather than assuming. Census estimates put 65.9 percent of residents age five and older speaking a language other than English at home.

Here is what we can actually say from the scan: 4 of the 52 sites published hreflang annotations declaring an alternate language version. The other 48 declared none.

Here is what we cannot say. The scan did not check whether a Spanish version existed at a separate URL without annotations, whether the translation was complete, whether the navigation and forms stayed in Spanish, or whether anyone at the business could answer a Spanish-language inquiry. Those are the questions that actually matter, and this scan did not ask them.

hreflang helps Google understand how alternate-language pages relate to each other and which one to show. Google can often identify a page's language from its visible content without it, so a missing tag is not a hole that traffic pours out of. It is one annotation on a bilingual setup that has to exist first.

A real bilingual audit would check for separate crawlable URLs per language, translated titles, headings, navigation, forms, and confirmation messages, reciprocal hreflang, correct canonicals, a crawlable language switcher that does not force a redirect based on location, and a business actually staffed to answer in Spanish. A tag cannot compensate for a half-translated site.

That deserves its own study. We have not run it yet.

llms.txt was absent on two thirds, and that is not an AI-visibility score

Thirty-five of the 52 sites had no llms.txt file.

We are reporting that as file presence and nothing more. llms.txt is a proposed convention, not an established protocol like robots.txt, and there is no documented guarantee that ChatGPT, Claude, or Perplexity use it when recommending a local business. Our later work found most of these files are generated automatically by a platform or plugin rather than written by the business.

This scan measured whether a file existed. It did not ask a single AI assistant to recommend an El Paso restaurant, so it cannot tell you who those assistants name.

The questions worth asking are whether the site publishes its services, location, people, and contact details in crawlable HTML, and whether those facts agree with its external profiles.

The rest of the findings

- No JSON-LD structured data on 30 of 52. Organization or LocalBusiness markup makes your name, address, hours, and service area explicit rather than inferred from the page. It should describe what a visitor can already verify, and it does not replace a complete Google Business Profile. - Main heading failed on 28 of 52. Missing, empty, or otherwise failing the heading rule. Worth splitting into those subcategories before acting, because they do not mean the same thing. - Under 300 words on 30 of 52. That is the scanner's threshold and a reason to read the page, not proof it cannot rank. A short contact page can be complete. A long service page can still fail to answer the question. - No HSTS header on 27 of 52. That is a browser-security finding, not a content or ranking one, and it belongs in the security section rather than beside the SEO checks.

Some of these are one-line changes. Others need content, translation, or template work the business may not control.

What this sample tells us, and what it does not

The same categories kept recurring across 52 sites: accessibility, structured data, headings, content length, and security headers.

Fixing them produces a clearer, more usable website. It does not tell you who will rank first in El Paso, who an AI assistant will name, or who can successfully serve customers in Juárez. Google says local results turn mainly on relevance, distance, and prominence. Your website is one input. Your Business Profile, reviews, categories, location, language quality, and what happens after an inquiry arrives are others, and this scan looked at none of them.

The scan tells you where to investigate. You still have to decide what the evidence means.

Check your own site

Run the free audit on your own site. No signup, no credit card, and the report is yours to keep. Then open the important pages and verify the findings, because an automated tool can show you a pattern and not much more. It certainly cannot tell you whether your Spanish translation is trustworthy or your customer journey works.

If you would rather we read it with you, book a free 15-minute teardown and we will walk through what it found, live, no pitch.

Where they came from: we queried the OpenStreetMap Overpass API for businesses within a 16-kilometer radius of the Albuquerque city center that publish a website, dropped national chains and aggregators, deduplicated the domains, and scanned the surviving homepages. Sixty candidates, 59 complete audits. It is the largest of the city samples in this project.

This is a purposive sample, not a census of Albuquerque and not a random one. It describes these 59 sites, and every percentage counts hard failures only.

The median score was 64 out of 100, the lowest median of any city we scanned. Fourteen sites landed below 40, which is DeepAudit's critical tier, not an industry definition of a broken website. Thirty-five of the 59 scored below 70. None reached 90.

Those numbers describe performance inside our scoring model. They do not tell us who ranks, who gets traffic, or whose website produces leads.

The median mattered less than the repetition. The same findings kept appearing.

Content length and structured data

Forty-two of the 59 homepages fell below DeepAudit's content threshold, which is 300 words.

That is a screening flag, not proof a page cannot rank. A 150-word contact page can be complete. A 1,500-word service page can still be generic and say nothing a competitor does not. The threshold marks pages worth reading, and the read should ask whether the page explains what the business does, who it serves, where it operates, and what to do next.

Thirty-eight sites had no JSON-LD structured data, the highest absence rate of the cities we sampled. Organization or LocalBusiness markup makes the name, address, hours, and service area explicit instead of leaving them to be inferred. It should describe what a visitor can already verify on the page and agree with the Google Business Profile. It does not power the map pack, and it does not guarantee a local ranking. Google says local results turn mainly on relevance, distance, and prominence.

Accessibility findings were nearly universal

Fifty-eight of the 59 pages triggered at least one accessibility failure.

Thirty-seven had a missing or inadequate visible focus indicator, which is what tells a keyboard user which link, button, or field is currently active. Remove it, or make it indistinguishable from the background, and navigating the page gets hard.

This is where manual keyboard and screen-reader testing should start. An automated scan finds detectable problems. It cannot certify a website as accessible or inaccessible.

llms.txt was absent on 43, and that is not an AI-visibility score

Forty-three of the 59 sites had no llms.txt file.

That is file presence and nothing more. llms.txt is a proposed convention, not an established protocol, and there is no documented guarantee that ChatGPT, Claude, or Perplexity consult it when recommending a local business. Our later research found most of these files are generated automatically by a platform or plugin rather than written by the business, which means presence overstates deliberate adoption anyway.

This scan checked whether a file existed. It did not ask an AI assistant to recommend an Albuquerque plumber, so it cannot tell you who gets named.

Headings, metadata, and previews

The primary heading failed on 36 sites, and that number needs a caveat about our own scanner. The rule fails a page for having no H1 *or* for having more than one. Multiple H1s are not automatically an SEO defect, so this count is stricter than it should be. The honest version: 36 pages have a heading structure worth reviewing, and some of them are fine. We are fixing the rule.

Thirty-two sites had no meta description. Google generates snippets from page content and may use your description when it summarizes the page better, so writing one gives you influence over the presentation, not control of it.

Thirty-one lacked complete Open Graph metadata. That reduces your control over the title, image, and description a platform shows when someone shares the link. Some platforms will still build a preview from other page content, so the link is not "broken," it just looks like whatever the platform decides.

What this sample tells us, and what it does not

The same content, structured-data, accessibility, heading, and metadata findings recurred across 59 sites. Correcting them produces clearer pages, more explicit business information, and fewer barriers for visitors.

What the scan does not establish: that these businesses are invisible, that Albuquerque is easy to win, or that fixing a scanner's checklist moves anyone from the bottom of the market to the top. A low median in our model says the sampled pages triggered a lot of rules. It says nothing about search demand, review counts, incumbent brands, proximity, ad spend, or how hard any specific query actually is. We did not measure any of that.

The scan tells you where to look. You still have to decide what it means.

Check your own site

Run the free audit on your own site. No signup, no credit card, and the report is yours to keep.

Then verify it. When a report calls a page thin, read the page. When it flags a heading, look at the heading. When it finds no schema, compare your visible business details against your Google Business Profile before writing any markup. The tool produces evidence, and someone still has to decide what is true.

If you would rather we read it with you, book a free 15-minute teardown and we will walk through what it found, live, no pitch.

Where they came from: we queried the OpenStreetMap Overpass API for businesses within a 10-kilometer radius of the Santa Fe city center that publish a website, dropped national chains and aggregators, deduplicated the domains, and scanned the surviving homepages. Sixty candidates, 54 complete audits. This is a purposive sample, not a census of Santa Fe and not a random one. Every percentage counts hard failures only.

Santa Fe posted the highest median of any New Mexico city we scanned: 76 out of 100. Thirty-one of the 54 landed at 75 or better, which is DeepAudit's good tier.

Two things keep that from being a victory lap. The mean was 70.5, well under the median, because a handful of sites scored very badly and dragged it down. And across all 54 sites, exactly one earned an A-. None earned an A.

The higher score tells us these sites passed more of the scanner's checks. It does not tell us they are better designed, that they rank, or that they turn visitors into customers. We did not measure any of that, and a technical score is not a design score.

The highest-scoring city had the worst focus-indicator rate

Forty-four of the 54 pages failed the visible-focus check. That is 81.5 percent, the highest rate of any city in the project, and it happened in the city with the best overall scores.

Fifty-three of the 54 pages triggered at least one accessibility failure. The category averaged 50 out of 100.

A visible focus indicator is what tells someone tabbing through a page which link, button, or field will respond next. Remove it, or style it so it disappears into the design, and a person navigating without a mouse loses their place.

That is the real finding here, and it is more interesting than any citywide median: a page can pass most technical checks and still contain a serious barrier for a particular person. The score and the experience are different things.

To be precise about what this is. It is a focus-indicator rule, not a keyboard test and not a screen-reader test. A real keyboard test asks whether every control can be reached and operated, whether the focus order makes sense, and whether focus ever gets trapped in a modal. The automated finding tells you where manual testing starts. Put your mouse down and tab through your own site. You will learn more in two minutes than the score will tell you.

llms.txt was absent on 35, and that is not an AI-visibility score

Thirty-five of the 54 sites had no llms.txt file.

That is file presence and nothing more. It does not mean the AI assistants planning someone's trip are unaware the business exists. Those systems draw on crawlable page content, search indexes, maps, reviews, directories, and press coverage, none of which require this file. llms.txt is a proposed convention, not an established protocol, and our later research found most of these files are generated automatically by a platform or plugin rather than written on purpose.

We did not ask a single AI assistant to plan a trip to Santa Fe. So this post cannot tell you which businesses it would name.

The rest of the findings, kept separate

- Low Open PageRank: 35 of 54. That is a third-party proxy built from an open web-link graph, not Google's PageRank and not a ranking score. Check it against real backlinks, local citations, press mentions, and gallery or venue relationships before anyone sells you a link campaign. - Primary heading failed: 29 of 54. Our rule fails a page for having no H1 or more than one, and multiple H1s are not automatically a defect, so this count is stricter than it should be. We are fixing the rule. - Under 300 words: 27 of 54. A prompt to read the page, not proof it cannot rank. A gallery homepage may need very little text if the work, the location, the hours, and the next step are already clear. - HTML validation errors: 25 of 54. This count needs severity, and we have not classified it yet. An obsolete attribute is not the same as malformed markup that closes the `` early and stops your metadata from being read. Google does not hand out rankings for passing a validator. Fix the errors that break something.

What this sample tells us, and what it does not

Santa Fe's sampled sites scored better than the rest of the state's, and still failed one basic accessibility check at the highest rate we recorded anywhere.

Correcting these findings makes a site clearer, more accessible, and technically sounder. It does not prove the business will rank, get named by an AI assistant, or convert a traveler who was already going to spend money. We collected no ranking, review, booking, or revenue data, and it would be dishonest to imply otherwise.

For the businesses here that depend on someone researching a trip before they arrive, the website is worth inspecting well beyond its score. This scan did not measure that customer journey. It just tells you where to start looking.

Check your own site

Run the free audit on your own site. No signup, no credit card, and the report is yours to keep.

Then verify it. When it flags focus visibility, navigate your own page with the keyboard. When it calls a page thin, read the page. When it reports invalid HTML, find out which error it is and whether it actually matters.

The score is a summary. The work starts underneath it.

If you would rather we read it with you, book a free 15-minute teardown and we will walk through what it found, live, no pitch.

Where they came from: we queried the OpenStreetMap Overpass API for businesses within a 25-kilometer radius of the Houston city center that publish a website, dropped national chains and aggregators, deduplicated the domains, and scanned the surviving homepages. Sixty candidates, 53 complete audits.

This is a purposive sample, not a census of Houston and not a random one. Every percentage counts hard failures only.

Houston produced the highest median of any city we scanned: 75 out of 100. Two of the 53 scored above 90. The mean was 71.9, which is the more conservative number and the one worth remembering.

That is the headline, and it comes with an immediate qualifier. Every audited page still triggered an accessibility failure, more than half fell below the content threshold, and the structured-data and security findings did not disappear just because the median went up.

Houston scored higher, and we cannot tell you why

The scan does not explain the cause. A larger economy, a different industry mix, more agency involvement, a different platform distribution, and simply which 53 businesses happened to be in the sample could all contribute. We measured the outcome, not the mechanism.

What we can say is narrower: these sites passed more of the scanner's checks overall, while several specific categories kept failing anyway.

Visible keyboard focus was missing on 44 of 53 pages

That is the highest focus-indicator failure rate in the whole project, and it happened in the city with the best scores.

A visible focus state is what tells a sighted keyboard user which link, button, or field will respond next. Remove it, or make it indistinguishable from the design, and the page gets much harder to operate.

All 53 pages triggered at least one accessibility failure, and the category averaged exactly 50 out of 100.

This is a focus-indicator check, not a keyboard test. A real keyboard test also asks whether every control can be reached and operated, whether the focus order makes sense, and whether focus ever gets trapped. The automated finding tells you where manual testing should start, and nothing more.

We did not isolate what caused these failures. The usual suspects are removed browser outlines, low-contrast custom focus styles, and interactive components nobody ever tabbed through. We are not going to blame a CMS for it, because we did not measure that.

llms.txt was absent on 40, and that is not an AI-visibility score

Forty of the 53 sites had no llms.txt file, the highest absence rate in the set.

That is file presence and nothing more. llms.txt is a proposed convention, not an established protocol, and there is no documented guarantee that ChatGPT, Claude, or Perplexity consult it when recommending a business. Our later research found most of these files are emitted automatically by a platform or plugin rather than written deliberately.

We did not ask a single AI assistant to recommend a Houston contractor. So this post cannot tell you who they name.

The rest of the findings, kept separate

They do not mean the same thing, so they should not be one line in a paragraph.

- Content threshold: 28 of 53 pages under 300 words. A prompt to read the page, not proof it cannot rank. A short page can do its job. A long one can still say nothing. - No JSON-LD structured data: 20 of 53. Organization or LocalBusiness markup makes the business details explicit rather than inferred. It should match the visible page and the Google Business Profile, and it does not guarantee rankings. - Primary heading failed: 26 of 53. Our rule fails a page for having no H1 or more than one, and multiple H1s are not automatically a defect, so this count is stricter than it should be. We are fixing the rule. - No HSTS header: 24 of 53. A browser-security finding. It belongs in the security section, not next to the SEO checks. - Low Open PageRank: 33 of 53. That is a third-party proxy, not Google's PageRank and not a ranking score. Check it against real backlinks and referring domains before anyone sells you a link campaign.

A citywide score is not a local-search strategy

This is the part that matters most in Houston, and it is where the smaller-city framing breaks down.

Houston is not one local market. A downtown energy consultancy, a Katy dental office, a Pearland caterer, and a contractor in The Woodlands are not competing in the same result. Google's local results turn mainly on relevance, distance, and prominence, which means the real comparison is query by query and neighborhood by neighborhood.

A citywide median is descriptive. It is not strategic. It cannot tell an individual business who it actually competes with.

It also cuts against the easy conclusion. If Houston's sampled sites scored better, the honest reading is that competitors here may be more capable, not that the market is easier. Basic cleanup is probably less differentiating in Houston than in a smaller market, not more.

What this sample tells us, and what it does not

These sites scored better than the smaller-city samples and still showed repeated accessibility, content, structured-data, and security findings. Fixing those produces a clearer, safer, more usable website.

What the scan does not establish: which businesses rank, who an AI assistant names, which sites will win over the next year, or that the bar is "better than the site next door." We collected no ranking, Business Profile, review, backlink, proximity, or lead data. A higher score raises the standard for the analysis. It does not remove the work.

Check your own site

Run the free audit on your own site. No signup, no credit card, and the report is yours to keep.

Then verify it. When the report calls a page thin, read the page. When it flags focus visibility, put your mouse down and tab through the site yourself. When it finds no structured data, compare your visible business details against your Google Business Profile before writing any markup.

The scanner shows you where to investigate. It cannot tell you who wins Houston.

If you would rather we read it with you, book a free 15-minute teardown and we will walk through what it found, live, no pitch.

Where they came from: we queried the OpenStreetMap Overpass API for businesses within an 18-kilometer radius of the Denver city center that publish a website, dropped national chains and aggregators, deduplicated the domains, and scanned the surviving homepages. Sixty candidates, 56 complete audits. This is a purposive sample, not a census of Denver and not a random one. Every percentage counts hard failures only.

The median was 70 out of 100. The mean was 65.2. Nine sites scored below 40, which is DeepAudit's critical tier and not an industry definition of anything. Twenty-six of the 56 came in under 70.

The findings landed across several unrelated layers: accessibility, structured data, content length, security headers, headings, and external prominence. That matters, and we will come back to it, because our first instinct was to explain all of them with one story and the story was not supported by the data.

Every audited page triggered an accessibility failure

All 56 of them. Forty-one triggered the visible-focus rule.

A visible focus indicator is what tells someone tabbing through a page which link, button, or field will respond next. Remove it, or make it invisible against the design, and using the page without a mouse gets much harder.

This is a focus-indicator check, not a full accessibility audit and not a keyboard test. It tells you where manual keyboard and screen-reader testing should start.

It also does not tell you what caused the failure. React, WordPress, a hosted builder, and hand-written HTML can each be built accessibly or badly. Removing a focus outline is a styling decision, not a consequence of choosing a framework.

llms.txt was absent on 41, and that is not an AI-visibility score

Forty-one of the 56 sites had no llms.txt file.

That is file presence and nothing more. It does not mean these businesses are illegible to ChatGPT. AI systems draw on crawlable page content, search indexes, maps, reviews, directories, and press coverage, none of which require this file. llms.txt is a proposed convention, not an established protocol, and our later research found most of these files are emitted automatically by a platform or plugin rather than written deliberately.

There is no evidence that adding one file "puts a business in AI answers." We did not ask a single assistant to recommend a Denver business, so this post cannot tell you who gets named.

The findings we cannot pin on JavaScript

An earlier version of this post gathered the rest of the results under a heading called "the JavaScript tax," and argued that Denver's React-heavy, app-style sites were the cause. It is a tidy story. We did not measure it.

Here is what we actually collected:

- Low Open PageRank: 34 of 56. A third-party proxy built from an open web-link graph, not Google's PageRank. Nothing about it is caused by a frontend framework. - No HSTS header: 31 of 56. An HTTP security header. It has nothing to do with whether the frontend uses React. - Primary heading failed: 31 of 56. Our rule fails a page for having no H1 or more than one, and multiple H1s are not automatically a defect, so this count is stricter than it should be. We are fixing the rule. - No JSON-LD structured data: 29 of 56. Google can process structured data generated by JavaScript, so this is not a rendering verdict either. - Under 300 words: 29 of 56. And this is the one that gave the old story away. The earlier post called this "thin or client-rendered content." It is not. It is the word-count check, full stop. This scan never compared raw HTML against the rendered DOM, so it produced no client-rendering measurement at all.

Missing backlinks, a missing security header, an unclear heading, and a short page can occur on any platform, in any framework. Grouping them under one fashionable explanation made the report easier to summarize and less useful to act on.

We also never detected which sites used React, which were single-page applications, or which client-rendered their important content. Without that, the JavaScript claim was a stereotype about Denver wearing the clothes of an analysis.

The study we should run instead

The JavaScript hypothesis is worth testing. It is just not tested here.

Doing it properly means detecting the platform and rendering architecture for every site, then comparing the initial HTML against the rendered DOM, and reporting accessibility findings and content loss by architecture: static HTML, server-rendered React or Next.js, client-rendered SPA, WordPress, hosted builders, custom. With counts and intervals, not city stereotypes.

We have run that raw-versus-rendered comparison before, on 368 small-business sites nationally, where one in four lost an answer-critical element in the initial HTML. We have not run it per city, and until we do, "Denver has a JavaScript problem" is a guess.

What this sample tells us, and what it does not

Across these 56 Denver sites, accessibility, structured-data, content, security, heading, and prominence rules fired repeatedly. Fixing the real ones produces clearer, safer, more accessible websites.

The scan does not establish that Denver's small-business web fails to live up to the city's tech reputation. It does not predict rankings, AI citations, leads, or revenue. And it does not identify a single common cause, which is exactly why we stopped claiming one.

The audit gives us a list of places to investigate. The explanation still has to be earned.

Check your own site

Run the free audit on your own site. No signup, no credit card, and the report is yours to keep.

Then verify it. When it flags focus visibility, tab through your own site with the keyboard. When it finds no schema, check your visible business details against your Google Business Profile first. And if you want to know whether your content survives without JavaScript, view the page source and look for it there, because the score will not tell you.

The tool can show you what happened. It cannot invent the cause.

If you would rather we read it with you, book a free 15-minute teardown and we will walk through what it found, live, no pitch.

Where they came from: we queried the OpenStreetMap Overpass API for businesses within a 25-kilometer radius of the Phoenix city center that publish a website, dropped national chains and aggregators, deduplicated the domains, and scanned the surviving homepages. Sixty candidates, 57 complete audits. This is a purposive sample, not a census of Phoenix and not a random one. Every percentage counts hard failures only.

The median was 78 out of 100. The mean was 71.9, which is the more conservative number and the one worth remembering. No site cracked 90. Fifteen of the 57 came in under 70, and seven scored below 40, which is DeepAudit's critical tier and not an industry definition of anything.

That gap between the median and the mean is the story. A 78 median says the typical Phoenix site in this sample is in reasonable shape. The mean sits almost seven points lower because a short tail of very weak sites pulls it down. Both numbers are true, and neither one describes "Phoenix."

51 of the 57 pages triggered an accessibility failure

Accessibility was the weakest category in the sample, averaging 59.8 out of 100, and 51 of the 57 pages triggered at least one accessibility failure. Fourteen failed the visible-focus check specifically.

A visible focus indicator is what tells someone tabbing through a page which link, button, or field will respond next. Remove it, or make it invisible against the design, and using the page without a mouse gets much harder.

This is an automated check, not a full keyboard test and not a screen-reader audit. It tells you where manual testing should start, and nothing more. It also does not tell you what caused the failure. A removed browser outline, a low-contrast custom focus style, and a component nobody ever tabbed through all produce the same finding, and each is a decision rather than a property of the platform.

llms.txt was absent on 43, and that is not an AI-visibility score

Forty-three of the 57 sites had no llms.txt file, the most common single finding in the set.

That is file presence and nothing more. It does not mean these businesses are invisible to ChatGPT, Claude, or Perplexity. AI systems draw on crawlable page content, search indexes, maps, reviews, directories, and press coverage, none of which require this file. llms.txt is a proposed convention, not an established protocol, and our later research found most of these files are emitted automatically by a platform or plugin rather than written deliberately.

We did not ask a single assistant to recommend a Phoenix business, so this post cannot tell you who gets named.

The rest of the findings, kept separate

They do not mean the same thing, so they should not be one line in a paragraph.

- HTML validation failed: 39 of 57. The markup did not pass the W3C validator. Browsers are forgiving and most of these pages render fine anyway, so treat this as cleanup, not an emergency. It matters most where invalid markup breaks structured data or accessibility, which is worth checking case by case. - No HSTS header: 35 of 57. A browser-security finding. It belongs in the security section, not next to the SEO checks, and it has nothing to do with rankings. - Under 300 words: 26 of 57. A prompt to read the page, not proof it cannot rank. A short page can do its job. A long one can still say nothing. - Primary heading failed: 22 of 57. Our rule fails a page for having no H1 or more than one, and multiple H1s are not automatically a defect, so this count is stricter than it should be. We are fixing the rule. - No JSON-LD structured data: 21 of 57. Organization or LocalBusiness markup makes the business details explicit rather than inferred. It should match the visible page and the Google Business Profile, and it does not guarantee rankings.

A citywide score is not a local-search strategy

Phoenix is not one local market, and it is less one market than almost any city we have scanned. A Scottsdale medspa, a Tempe print shop, a Mesa HVAC contractor, and a Chandler accountant are not competing in the same result. Google's local rankings turn mainly on relevance, distance, and prominence, which means the real comparison is query by query and neighborhood by neighborhood.

A citywide median is descriptive. It is not strategic. It cannot tell an individual business who it actually competes with, and in a metro this large the average of 57 homepages says even less about any one of them than it would in a smaller town.

What this sample tells us, and what it does not

Across these 57 Phoenix sites, accessibility, security, structured-data, heading, and content rules fired repeatedly, while the local-SEO category was the strongest in the set. Fixing the real findings produces a clearer, safer, more usable website.

What the scan does not establish: which businesses rank, who an AI assistant names, which sites will win over the next year, or that the bar is "better than the site next door." We collected no ranking, Business Profile, review, backlink, proximity, or lead data. The median tells you where the middle of this sample sits. The seven sites in the critical tier are the ones with the most to fix, and a citywide number will never point at them.

Check your own site

Run the free audit on your own site. No signup, no credit card, and the report is yours to keep.

Then verify it. When the report calls a page thin, read the page. When it flags focus visibility, put your mouse down and tab through the site yourself. When it finds no structured data, compare your visible business details against your Google Business Profile before writing any markup.

The score is a summary. The work starts underneath it.

If you would rather we read it with you, book a free 15-minute teardown and we will walk through what it found, live, no pitch.

Where they came from: we queried the OpenStreetMap Overpass API for businesses within a 15-kilometer radius of the Tucson city center that publish a website, dropped national chains and aggregators, deduplicated the domains, and scanned the surviving homepages. Sixty candidates, 52 complete audits. This is a purposive sample, not a census of Tucson and not a random one. Every percentage counts hard failures only.

Tucson produced the most tightly clustered results of anything we have scanned. The median was 78.5 and the mean was 74.9, the closest those two numbers have ever landed for us. No site scored below 42, and none cracked 90. Fifteen of the 52 came in under 70, and for the first time in this project, not one site fell into the critical tier below 40. Phoenix, which we scanned the same week and which posted a nearly identical median, had seven.

That consistency is the finding, and it cuts both ways. There are no disasters in this sample, and there are no standouts either. Most of these Tucson sites are competent, and unfinished in the same few places.

45 of the 52 pages triggered an accessibility failure

Accessibility averaged 65.4 out of 100, higher than most cities we have scanned, and 45 of the 52 pages still triggered at least one accessibility failure. Twelve failed the visible-focus check specifically.

A visible focus indicator is what tells someone tabbing through a page which link, button, or field will respond next. Remove it, or make it invisible against the design, and using the page without a mouse gets much harder.

This is an automated check, not a full keyboard test and not a screen-reader audit. It tells you where manual testing should start. It does not tell you what caused the failure, and it does not tell you the framework is at fault, because a removed outline and a low-contrast focus style look identical to the scanner and can happen on any platform.

More than half the pages were under 300 words

This was Tucson's most common content finding: 30 of the 52 homepages came in under 300 words.

Word count is a prompt to read the page, not proof it cannot rank. A short homepage that states who you are, what you do, where you are, and how to reach you can do its job. But 300 words is a low bar, and a page that fails it is often missing the specifics a searcher and an AI assistant both use to tell you apart from the shop down the street: services in plain language, the service area you actually cover, and the details only you would know.

llms.txt was absent on 38, and that is not an AI-visibility score

Thirty-eight of the 52 sites had no llms.txt file.

That is file presence and nothing more. It does not mean these businesses are invisible to ChatGPT, Claude, or Perplexity. AI systems draw on crawlable page content, search indexes, maps, reviews, directories, and press coverage, none of which require this file. llms.txt is a proposed convention, not an established protocol, and our later research found most of these files are emitted automatically by a platform or plugin rather than written deliberately.

We did not ask a single assistant to recommend a Tucson business, so this post cannot tell you who gets named.

The rest of the findings, kept separate

They do not mean the same thing, so they should not be one line in a paragraph.

- HTML validation failed: 35 of 52. The markup did not pass the W3C validator. Most of these pages still render fine, so treat it as cleanup, not an emergency, and look first where invalid markup could break structured data or accessibility. - No HSTS header: 30 of 52. A browser-security finding, not an SEO one, and unrelated to rankings. - No JSON-LD structured data: 19 of 52. Organization or LocalBusiness markup makes the business details explicit rather than inferred. It should match the visible page and the Google Business Profile, and it does not guarantee rankings. - Primary heading failed: 18 of 52. Our rule fails a page for having no H1 or more than one, and multiple H1s are not automatically a defect, so this count is stricter than it should be. We are fixing the rule. - Missing meta description: 17 of 52. That hands the search engine control over the snippet it writes under your link. It is not a ranking factor on its own.

A citywide score is not a local-search strategy

Tucson is smaller and more centered than Phoenix, but it is still not one market. A downtown law office, a shop near the University of Arizona, an east-side auto service, and a contractor out toward Oro Valley or Marana are not competing in the same result. Google's local rankings turn mainly on relevance, distance, and prominence, which means the real comparison is query by query and neighborhood by neighborhood.

A citywide median is descriptive. It is not strategic. It cannot tell an individual business who it actually competes with.

What this sample tells us, and what it does not

Across these 52 Tucson sites, the scores were consistent and the same categories kept coming up short: accessibility, content length, security headers, structured data, and headings. The local-SEO category was the strongest in the set. Fixing the real findings produces a clearer, safer, more usable website.

What the scan does not establish: which businesses rank, who an AI assistant names, which sites will win over the next year, or that a tight distribution means the market is easy. We collected no ranking, Business Profile, review, backlink, proximity, or lead data. In a sample this evenly matched, the differentiation is unlikely to come from basic cleanup that everyone can do. It comes from the specifics, and those still have to be written.

Check your own site

Run the free audit on your own site. No signup, no credit card, and the report is yours to keep.

Then verify it. When the report calls a page thin, read the page. When it flags focus visibility, put your mouse down and tab through the site yourself. When it finds no structured data, compare your visible business details against your Google Business Profile before writing any markup.

The score is a summary. The work starts underneath it.

If you would rather we read it with you, book a free 15-minute teardown and we will walk through what it found, live, no pitch.

I audited our own site, axiondeepdigital.com, and started with a different question: not only whether the pages could rank, but whether a qualified person arriving from search had a clear, measurable path to becoming a lead.

They did not. And the first thing I had to fix was not on the site at all. It was the number I was using to make decisions.

First, we had to stop trusting the traffic

The analytics dashboard reported 901 new users over a 28-day window. I was about to prioritize the whole project around which pages got the most of them.

Then I read the raw events, and roughly 90 percent of that traffic was not human.

Three independent tells, each from a different mechanism. The page-view floor gave it away first: nearly every URL sat in a tight band around 105 to 140 views, including the Privacy Policy at 105 and the Terms page at 89. Humans produce a steep curve, where the homepage dwarfs the legal boilerplate nobody reads. A flat plateau across every page, including Terms, is a crawler walking the sitemap. Retention was about 0.3 percent: weekly cohorts of 402, 334, 216, 181 came back the following week at 1, 0, 0, 2. And sessions averaged 33 seconds with about 8 page views. Eight pages in 33 seconds is a machine.

Strip it out and the honest baseline is roughly 80 real new users in 28 days. About three humans a day.

Google Analytics excludes known bots where it can. That does not make the survivors people. Any conversion rate I had computed against 901 was understated by more than tenfold, and every "this page gets the most traffic" conclusion I was about to draw was drawn from crawler behavior.

That is the correction that had to come before anything else. You cannot optimize a funnel whose top number is fiction.

Then the real leak showed up, and it was not where I expected

With clean numbers, the audit funnel turned out to be fine. About 80 percent of people who start a scan finish it.

Here is the number that actually matters:

80 completed audits produced 2 booking clicks.

Somebody typed in their domain, waited for a real browser to render it, and read a report about what is wrong with their website. That is one of the clearest intent signals available anywhere on the site. Then almost none of them took a next step.

That is not a ranking problem. It is not a traffic problem. Every SEO instinct I had was pointed at the wrong end of the pipe.

Three problems in the path, stated as what they are

These were the hypotheses that came out of the review. They are design and measurement problems we observed, not costs we have quantified.

The offer did not match the page. Someone reading about Google Business Profile management got pushed toward the same general website scan as someone reading about review generation or lead capture. A person worried about reviews was handed a technical crawl of their HTML. The promise on the page and the promise in the offer were different promises.

Too many actions had equal weight. Several pages offered booking, auditing, contacting, quoting, and further reading with roughly equal visual priority. More than one link is not the problem. The problem was that nothing signaled which one the page was actually built for, and we were not instrumenting the choices separately, so we could not tell whether people picked a secondary path or simply did nothing.

The audit result stopped at the interesting part. The result page returned a score and a list of findings, and then ended. It did not separate verified problems from warnings needing review, did not order them around the visitor's actual goal, and did not offer one next step tied to what the scan had just found.

Renaming the audit is not the same as building a different audit

The obvious fix is to offer a review gap audit, a local visibility audit, a lead leak audit. Match the promise to the page.

That only works if the analysis behind each one actually changes.

A review gap audit needs external review counts, ratings, recency, response behavior, and competitor comparison. A local visibility audit needs the Business Profile, categories, locations, listings, and query-level visibility. A lead leak audit needs form behavior, routing, response time, and CRM data.

If all five run the same DeepAudit checks under different headings, the offer matches the page and lies about the product. That is worse than the generic version we started with, and it is the trap this whole redesign has to avoid.

Instrument one path before building five

We did not rebuild everything. We picked one route and made it measurable end to end:

Landing page, audit started, audit completed, lead captured, lead qualified or disqualified, contacted, won or lost, revenue attached.

GA4 and Tag Manager record what happens on the site. Site2CRM carries the source, the submission, the score, and the lead into the CRM. The CRM records what happened to it.

The event names matter less than the continuity: one lead should be traceable from the page that created the visit to the business outcome, without being duplicated or losing its source halfway through.

Three of our GA4 events were also miscounting, which is its own lesson. `audit_started` fires for both quick and deep scans, while `audit_completed` only fires for quick ones. Comparing them produced a fake 42 percent abandonment rate that I very nearly acted on. Instrumentation that lies to you is worse than no instrumentation, because it lies with a number attached.

What the audit actually changed

It did not surface one magic SEO fix. It showed that our traffic data needed cleaning, several offers did not match their pages, the calls to action had no hierarchy, the result page ended before the useful moment, and the events we were measuring by were partly wrong.

I would not call this a revenue success story. Not yet. We rebuilt the measurement, and we found the leak. The honest status is that we can finally tell whether the next round of changes works.

The next post on this should report whether 80 completed audits still produce 2 booking clicks. If it does not report that, assume it did not work.

See it on your own site

Run the free audit on your site. It loads your pages in Chromium and inspects the rendered result. No signup, and the report is yours.

Then go look at your own analytics and ask the harder question: how much of that traffic is a person, and what happens to the ones who are?

Those things matter. A confusing layout, an unclear offer, or a design nobody trusts will absolutely cost a business customers, and we are not going to pretend otherwise to sell a technical audit.

But the visible page is one layer. Performance, metadata, crawler access, accessibility, structured data, local business information, and lead tracking can all fail without producing a single broken thing on screen.

That is why opening your homepage on your own laptop is not an audit.

A page does not have one version

This is the part that is genuinely counterintuitive.

The server sends an initial HTML response. JavaScript may change it once it reaches the browser. Google crawls the response and may render it later. Some crawlers never run the scripts at all. A keyboard user moves through the interface differently than someone with a mouse. Search results may show a title you did not write. Analytics may be counting bots alongside people.

Each of those is a different view, and each answers a different question. A real audit compares them instead of pretending one score describes the whole site.

Here is what we check, and what each finding does and does not prove.

Mobile performance. A page can feel fast on office wifi and a new laptop, then take several seconds to become usable on a mid-range phone. In our study of 292 small business websites, 191 returned valid mobile Lighthouse data, and 96.9 percent of those failed at least one of the lab thresholds we configured.

Lighthouse is a controlled diagnostic, not real-user field data, and this does not prove any of those sites lost rankings. It tells you which pages deserve a look at field data in Search Console, and then at the images, scripts, fonts, and server response behind the number.

Titles and descriptions. Missing, duplicated, or vague metadata reduces your influence over how a page shows up in search. Google builds title links and snippets from several sources, including your tags, your headings, and prominent page text, and it may rewrite yours even when they exist.

Missing metadata does not make Google bury you. It just means you handed over the one piece of copy you could have controlled. Write a distinct title and an accurate description for every important page, then check Search Console to see what is actually being displayed.

Structured data. Valid Organization, LocalBusiness, or Person markup makes the entities on a page explicit rather than inferred. It should describe what a visitor can already verify and agree with your external profiles.

Missing schema does not make a business invisible, and valid schema does not earn a rich result or the map pack. Google says local results are driven mainly by relevance, distance, and prominence. Schema is one layer of evidence inside that system, not the lever that operates it.

Local identity. Every real location should present one accurate version of its name, address, phone, hours, categories, and page, and those should agree across the site, the Google Business Profile, and the directories that matter.

The reason is not a ranking trick. It is that conflicting information sends a customer to an old address or attaches a review to a profile nobody manages. Consistency reduces ambiguity. It does not override distance.

Accessibility. Missing form labels, invisible keyboard focus, weak contrast, and unlabeled links stop real people from operating the page. Some of those practices also make structure clearer to search systems, but we are not going to sell accessibility as a ranking shortcut, because Google does not document it as one.

Fix it because someone is trying to use your website and cannot. That is a sufficient reason. And note that an automated scan finds only part of the picture: the important pages still need a human tabbing through them.

Rendering-dependent content. Google does execute JavaScript, though rendering is deferred and can fail. Several major AI crawlers have been observed fetching pages without running the scripts at all, and even that is not uniform, since OpenAI alone operates separate agents for search, training, and user-triggered visits.

So the rule is not "AI cannot read JavaScript." It is simpler: a system cannot retrieve evidence that was absent from the version it received. Put your services, locations, people, contact details, headings, navigation, and structured data in the initial HTML, and let JavaScript enhance that rather than be the only place it exists.

Why these get missed

Not because they are invisible. Several of them are perfectly visible if you look in the right place: a slow phone, a keyboard, a search result, the page source, a crawl.

They get missed because nobody tests those conditions. The owner checks the site the way the owner uses the site, on the device the owner owns, on the connection in the owner's office. That view is real. It is just not the only one.

Use the right instrument for the question

DeepAudit loads the page in Chromium and inspects the rendered result rather than the initial HTML alone, and it checks performance, technical SEO, content, structured data, accessibility, security, and crawlability. It takes about a minute and needs no signup.

It is not Google. It is not a complete accessibility audit. It is not a conversion study, and it cannot read your page for you.

Use Search Console for indexing and search performance. Use field data for what real users experienced. Use a keyboard for accessibility. Use analytics and your CRM to find out whether visitors turn into qualified leads. Use the scan to find out where to start.

Some findings are a one-line change. Others need content, development, accessibility testing, or a decision about the platform itself. A report that treats those as the same thing is not helping you.

Fix what the evidence shows

Sometimes a site needs technical cleanup. Sometimes it needs clearer writing. Sometimes the navigation really is the problem, or the offer is, or the design is.

And sometimes the website is fine and the actual problem is the Google Business Profile, the reviews, or nobody calling the leads back.

Do not approve a redesign on a hunch. Do not approve a technical rebuild on one either. Test the layers separately, compare what they tell you, and fix the thing that is actually there.

Look behind your own site here.

I did not upload a Lighthouse report. I did not connect Search Console. I did not give it our crawler output or DeepAudit.

It still returned precise scores, named the technologies on our homepage, cited specific location URLs, drew conclusions about how Googlebot renders the site, and handed me a prioritized plan.

Several of those claims were false. But the mistakes are not really the story.

The answer looked measured when no measurement had happened.

First, the limits of this test

One conversation, one site, one afternoon. Four turns in a single thread, not four independent trials, so later answers could see earlier ones.

I also did not record the model version, the plan, or whether any browsing tool fired. That was sloppy of me, and it is the first thing I would fix if I ran this again, because without it nobody can reproduce what I saw. Take everything below as one documented incident, not a benchmark of ChatGPT.

The scores had no disclosed calculation

The first answer graded us: Technical SEO 9/10. Architecture 8.8/10. Content Depth 6.8/10. Topical Authority 6.5/10. Local SEO 8.5/10. Conversion SEO 8.7/10.

A custom rubric is not automatically wrong. We publish a proprietary score ourselves, and I will come back to that.

The problem is that nothing explained why Architecture was 8.8 rather than 7.8 or 9.2. No criteria, no weights, no evidence, no pages named, no scale. The decimal implies a calculation that never happened. It was a vibe wearing a lab coat.

Then it described a homepage it had not read

It listed eight technology brands on our homepage. Three of the eight are not on the page.

It cited four location-page URLs. Two of the four do not exist.

These are not subtle SEO judgments. They are page-level facts, trivially checkable, and it got them wrong while sounding completely certain.

The dangerous part is the mixture. The fabricated items sat beside real ones, and the real ones lent them credibility. A list that is 60 percent right reads as a list that was checked.

Two messages later, it admitted it had never measured anything

I asked for our current mobile LCP, CLS, and INP.

> I cannot provide live CrUX field values without direct access to PageSpeed Insights or the CrUX API.

Correct, and useful. It also detonates the first answer. Two turns earlier it had assigned a technical score and praised our rendering stack without ever having run a test.

A qualitative opinion without Lighthouse is fine. A *measured* conclusion without measurement is not. The later honesty exposed how little was under the earlier confidence.

Then it guessed at the vitals anyway: CLS very good, LCP decent, INP "likely your weakest."

Where we made our own mistake

We ran Lighthouse mobile and published a table comparing its numbers with those guesses. That table was wrong, and it was wrong in a way that matters, so we are fixing it here rather than quietly deleting it.

We compared a predicted INP against a measured TBT. Those are not the same metric. INP is a real-user interaction metric. TBT is a lab measurement of main-thread blocking during page load. TBT can hint at responsiveness risk. It is not INP, and treating one as the other is exactly the kind of sloppiness this article is complaining about.

We also reported Lighthouse's weighted score contributions (LCP 2/25, TBT 27/30, CLS 25/25) as if they were metric values. They are not. They are how much each metric contributed to the overall Performance score. We never recorded the raw seconds and milliseconds, so we cannot show them to you now. That is our failure, not Lighthouse's.

What survives, honestly:

- LCP scored in the lowest tier of its weighted contribution on mobile. That is a real, measured problem, and ChatGPT called it "decent." - CLS was strong, which ChatGPT predicted. It is also the safest guess available. - We could not test the INP prediction at all. Our origin does not have public CrUX field data, and the Lighthouse page-load report does not measure real interactions.

So the honest verdict is narrower than the one we originally published. ChatGPT missed a measured LCP problem. We cannot claim its ranking was "exactly inverted," because we never measured the metric it ranked worst.

"Based on the rendered structure"

The third answer opened with that phrase and went on to describe how Googlebot handles our JavaScript.

Nothing in that conversation showed it had opened the page in a browser, executed the scripts, inspected the DOM, or compared any of it against Google's rendered result.

I want to be careful here, because our earlier version of this post said "ChatGPT cannot render anything," and that is no longer true of the product. ChatGPT can search the web, cite sources, and in some modes drive a visual browser. A custom agent can be wired to Lighthouse, Search Console, or a crawler.

So the rule is not "an LLM can never inspect a site." The rule is that the answer has to say what it actually did in this run. Was the page fetched? Was JavaScript executed? Which URLs were opened? Which claim came from which tool?

Without that provenance, "based on the rendered structure" is just a convincing phrase.

The priorities ignored the thing we could measure

The last answer recommended a topical cluster, portfolio case studies, and better internal semantic links.

None of that is bad advice. It is also interchangeable with the advice you would give any agency site on earth, and it never mentioned the one problem an actual measurement had surfaced.

A priority list should show its work: the evidence, the affected pages, the confidence, the expected impact, the effort, and how you will know it worked. Otherwise a familiar recommendation sounds specific while remaining generic.

I will resist the temptation to say "a real list starts with fix mobile LCP." We had one lab run, no field data, and no evidence connecting that number to a lost ranking or a lost lead. It deserved investigation and a place on the list. Whether it outranked everything else is a claim I have not earned either.

The standard has to apply to us too

We give our own site a 96/100. ChatGPT gave itself a 9/10 for our technical SEO. Both are proprietary composites.

The difference I want to claim is that ours traces to versioned, documented checks against evidence collected from a real browser. The difference I am *not* entitled to claim is that ours is therefore true. Our scanner has produced false positives on our own site, and an over-strict heading rule of ours inflated a number in several published studies before we caught it.

An automated tool that skips the measurement is not better than a language model that skips the measurement. It just fails more quietly.

What an LLM is actually good for here

It is not the measurement instrument. It is the layer that helps a person understand measurements that actually happened.

Give it a Lighthouse report and it will explain it well. Give it a crawl export and it will find the contradictions. Give it your initial HTML and your rendered DOM and it will tell you what changed between them. Give it verified findings and it will draft the fix.

Ask it for a number it never collected and it will produce one, because producing plausible text is what it does.

The tools that answer the measurement questions are the boring ones: PageSpeed Insights for the lab run and field data when your origin qualifies for it, Search Console's URL Inspection for what Google actually crawled and rendered, a browser crawler for the source-versus-rendered comparison, and a person for whether the page is any good.

The test I should have run

One site and one thread cannot tell you how often this happens.

The real experiment is controlled pages with known defects: a missing H1, an H1 injected by JavaScript, a broken bundle, a conflicting canonical, a slow hero, absent structured data, a city page that does not exist, and a clean control. Run each through an untooled model, a search-enabled one, an agent with a browser, and a real auditor. Then score every claim for correctness and support.

That answers the only question worth asking: does the diagnosis change when the site changes?

I suspect it often would not. I have not proven it, and I am not going to write the conclusion before I run the test.

The rule we use now

We stopped asking whether AI wrote the audit. We ask whether each conclusion traces to evidence.

A performance number cites the run that produced it. A missing element names the URL and which representation was inspected. A rendering claim states how the page was rendered. A priority explains why it beat the alternatives.

And when the evidence is not there, the correct answer is not a decimal score. It is: I do not know yet, and here is the test that would tell us.

Run the audit if you want the browser-collected version. Then check it, because that rule applies to our tool too.

The first version looked like it worked. The prose was clean, the grammar was right, the length matched what we asked for.

Then I diffed the output against the original.

A product name was gone. A city had become "the area." Two internal links had vanished. A service description had been compressed until it no longer described the service.

The rewrite was easier to read and less true.

The problem was not that an AI touched the content. The problem was that we were measuring fluency and never checking fidelity.

Google does not penalize content for being AI-assisted

Let us get this out of the way, because the usual version of this article gets it wrong.

Google's guidance is about whether content is accurate, useful, original, and made for people. Using AI in an editorial process is not itself a ranking problem. Mass-producing pages with automation and no added value violates its scaled-content-abuse policy, but a human can write a generic, useless page just as easily.

The production method is not the standard. The finished page is.

Our rewriter failed that standard for a boring reason: it changed information we needed to keep.

Specificity went first

Say a page states that DeepAudit audits JavaScript-rendered sites for businesses in Las Cruces.

A generic rewrite turns that into something about helping local companies improve their online presence. Smoother. Also, the reader no longer knows which product, what kind of sites, where you work, or what makes any of it different.

I am not going to claim that deleting one instance of a city name makes you "invisible to entity-based ranking." That is keyword superstition, and I have seen it in enough SEO decks to be tired of it. Pronouns are fine. Repetition is annoying. Exact-match phrasing often makes a page sound like it was written for a crawler.

The rule is narrower and more defensible:

Do not generalize a passage until it stops saying what the business actually does.

"SEO tool" and "JavaScript SEO scanner for React applications" are not the same claim. The first names a category with thousands of entrants. The second names a function and an audience. That is worth protecting because it is *accurate*, not because a keyword tool put it in a spreadsheet.

The links were an architecture bug, not a writing bug

Our early workflow handed the model the article and asked for a rewritten version. That gave it authority over the words *and* the document structure. When it rewrote the linked sentence, the hyperlink sometimes went with it.

In hindsight that is entirely predictable. We asked a text model to regenerate a structured document from memory, and it did exactly that.

The fix was not another sentence in the prompt.

We stopped letting the model regenerate the links at all. The application parses the article first. Links, URLs, citations, headings, code blocks, and protected facts stay in the application layer. The model rewrites approved text spans, and the system reinserts them into the existing structure.

It can propose better anchor wording. It cannot silently delete a destination, because it never holds the destination.

That is the whole lesson, really: reduce what the model is allowed to change, and you stop needing a validator to catch what it broke.

Structured data has to agree with the page, not match it word for word

A second failure showed up when a rewrite removed a visible fact while the JSON-LD still declared it.

Structured data should describe the page and correspond to what a visitor can actually see. But the prose does not have to echo the schema verbatim. A page can say "projects begin at $2,500" while the markup expresses the same pricing in machine-readable form. Those agree.

The break happens when the rewrite deletes or contradicts the underlying fact. So the validation compares facts, not strings.

And I want to be careful here: valid schema does not guarantee a rich result or a ranking benefit. It just needs to be true.

Three layers, not one rule

Our first instinct was to reject any rewrite that lost a protected phrase. That is too blunt. Some of those losses are improvements.

So the contract has three layers now.

Hard invariants. Cannot change without explicit approval: link destinations, names of people and businesses and products and places, prices, quantities, dates, credentials, technical specs, contact details, direct quotes, citations, legal qualifiers, and any fact the structured data declares.

Structural invariants. Must survive, though wording or position can move: internal links, the question each section answers, the heading hierarchy, required lists and tables and code, the primary call to action.

Soft targets. Fair game when the rewrite genuinely improves the piece: sentence length, repetition, transitions, tone, paragraph order, examples, anchor phrasing.

A changed price is rejected automatically. A different anchor phrase goes to a human. A redundant fourth mention of the city can just go.

A prompt is not a validator

We still tell the model what to preserve. We simply stopped believing it.

Every rewrite is diffed against the original afterward: are the URLs still there, did a number or date change, did a named product or person or place disappear, did it invent a new factual claim, does the visible content still support the schema, did the conclusion change, did the CTA survive.

A failed check does not mean the output is garbage. It determines what happens next: reject, retry with the specific failed constraint, restore the element programmatically, or send it to a person.

The thing I am not going to claim

The honest version of this post has to include what I cannot prove.

During one client audit we found a rewritten paragraph that had replaced several named services and locations with generic filler, and the page's search performance had declined over a period that also contained multiple other content changes. Other things shipped. Competitors moved. Google updated.

I cannot isolate the rewrite as the cause of that decline, so I am not going to tell you it was. What I can verify is that the new version conveyed materially less information than the one it replaced. That is a good enough reason to fix it. The article does not need a ranking drop to justify itself, and reaching for one would be exactly the kind of unearned causal story this blog has been cutting for weeks.

What I still owe you

I have not measured this system yet, which is the real gap.

The test set is straightforward to build: representative passages carrying internal links, named companies, locations, dates, prices, technical terms, quotations, legal qualifiers, and schema-backed facts. Run each version of the rewriter across it and report link-destination retention, named-entity retention, numeric and date accuracy, contradiction rate, unsupported-claim rate, human readability, and the share accepted with no manual correction.

Then I can tell you whether moving the links out of the model actually fixed anything, instead of asserting that it did.

That is the next post, and I would rather promise it than fake it.

What we check before publishing

Compare the rewrite against the original, directly. Inspect every changed fact. Confirm every link and destination. Check names, places, products, dates, prices, credentials. Ask whether specific service language went generic. Confirm the visible facts still agree with the structured data. Read it as a customer rather than a keyword counter. Reject claims the source did not support. Keep changes only where they fix an identifiable problem. Record who approved it.

The goal was never to keep AI away from the article. It is to know exactly what changed, and why.

The lesson

AI did not secretly drain some invisible substance called "SEO" out of our content.

We handed a probabilistic writing model more authority than it needed and then graded it on the wrong thing. It optimized what we measured. Fluency went up. Fidelity was never checked.

We fixed it by keeping the document structure outside the model, defining what could not move, validating every rewrite against the original, and leaving a person responsible for the call.

The best rewrite is not the one AI barely touched. It is the smallest set of changes that improves the piece without damaging its facts, its purpose, or its structure.

---

Before you publish an AI-assisted rewrite, diff it against the original and walk the checklist above. That is the step that catches this.

Afterward, a technical audit will confirm that the links, headings, schema, and rendered content actually survived deployment. It cannot tell you what the rewriter took out, so do not ask it to.

Of those, 191 returned a valid mobile verdict. Here is the whole result, with denominators, because the denominators are the part people drop when they quote it.

| Finding | Count | Rate | |---|---|---| | Failed at least one configured threshold | 185 of 191 | 96.9% | | Passed LCP, FCP, and CLS | 6 of 191 | 3.1% | | Mobile LCP over 4 seconds | 165 of 191 | 86.4% | | Mobile FCP over 3 seconds | 139 of 192 | 72.4% | | Passed the CLS threshold | 165 of 193 | 85.5% | | Failed axe-core's link-name rule | 191 of 191 | 100% |

Median mobile LCP across the valid tests: 10.5 seconds.

That is the number to remember. Not a threshold pass rate, but the fact that on a median small-business B2B site, the largest thing on the page took more than ten seconds to show up on a phone.

These are Lighthouse lab results, not Core Web Vitals

The original title of this article said "96.9% Fail Core Web Vitals." That was wrong, and since this is the page most likely to be cited, it needs correcting at the top rather than in a footnote.

Google's Core Web Vitals are LCP, INP, and CLS, measured from real users in the field.

We measured LCP, FCP, and CLS in a single Lighthouse lab run per site. FCP is not a Core Web Vital. We never captured INP. We have no field data at all.

So the accurate claim is: *96.9 percent of the sites returning a valid mobile lab test failed at least one threshold we configured.* That is still a serious finding. It is a different finding from the one the old headline advertised.

Where the sites came from, and what that limits

The 292 domains came from a ZoomInfo B2B prospect list in our sales pipeline, weighted toward construction, trades, and small professional services.

Purposive, not random. We did not go hunting for bad sites, which removes one bias, but this is a snapshot of one pipeline and not an estimate for the small-business web.

Each site was measured once. Lighthouse varies with server load, caching, and test conditions. We did not repeat the runs, so treat the exact percentage as a snapshot rather than a population constant. A site at 2.49 seconds and a site at 2.51 seconds land on opposite sides of a threshold, and we have not quantified how many sat that close to the line.

How the pages were captured

Each page opened in Chromium via Puppeteer, and the scanner inspected the rendered DOM after a bounded wait.

That is one browser stage of page processing. It is not Googlebot. Google runs its own crawl, render queue, indexing, and ranking systems, and no third-party audit reproduces them. We used to say we render "the way Googlebot does," and that was marketing, not engineering.

The study ran the rule set as it existed in April 2026, roughly 60 checks. The current system is larger, which means a scan today will not reproduce this study exactly. If we want a longitudinal comparison, we have to version the rules, the Chromium build, and the Lighthouse version and hold them still. We had not done that. That is a real gap in the methodology and we are naming it rather than claiming the method is "frozen."

LCP: the most common failure, and the cause is not in this dataset

165 of 191 valid tests exceeded four seconds, median 10.5.

Now the part where the earlier version of this article overreached. It listed causes "in order of frequency": oversized hero images, three synchronous scripts in the head, fonts blocking text. The dataset has 41 columns and none of them record any of that. No LCP element type, no image bytes, no script counts, no font-display values. Those were educated guesses presented as measurements, and in a research post that is not acceptable.

What we can say is how to actually diagnose it. LCP is a composite. Split it:

- Server response time - Delay before the LCP resource is even discovered - Time spent downloading it - Render delay after it has arrived

One page we did inspect by hand used a 2400x1600 PNG at 3.2 MB as its hero, and that image became the LCP element. For that page, image delivery was obviously where the work was. We are not going to extrapolate a six-second 4G download time from it, because transfer time depends on throughput, latency, caching, and contention we did not record.

Framework helpers make the fix easier, not automatic. Next.js can generate responsive widths and modern formats, though its image API has moved on since this study and WebP, not AVIF, is the default output. Which image deserves priority is a question about your page, and only a trace answers it.

Third-party scripts and fonts: real issues, wrong prescriptions

We did encounter pages loading several early third-party scripts during manual review. We did not record that as a dataset column, so we will not give you a population statistic for it.

And "defer every third-party script" is bad advice. Some scripts have consent, ordering, attribution, or security requirements, and moving them breaks things quietly. Inventory the requests, find which ones block parsing or eat the main thread, delete what nobody can justify, and move the rest as late as their actual function allows. Then regression-test consent and attribution, because that is what breaks.

Fonts are the same story. `font-display: swap` shows fallback text quickly, which helps FCP. It can also *cause* layout shift when the fallback and final fonts have different metrics. It is a tradeoff, not a free win, and the three-line CSS fix hides a decision about subsetting, weights, WOFF2, preload, and fallback metrics.

FCP: 139 of 192, and it is not "worse than LCP"

The old version claimed FCP was worse than LCP. Our own table says otherwise: LCP failed on 86.4 percent, FCP on 72.4 percent.

FCP is when the browser paints any content. Not meaningful content, not useful content, any. It does not tell you the page is ready, and it does not identify a cause: navigation, redirects, TTFB, blocking CSS, fonts, and script execution all live inside it.

One pattern we saw by hand was an empty shell that built the whole page client-side after fetching its data. For a public marketing page, putting the main content in the initial response removes a long chain of things that all have to succeed before anything appears. For an authenticated app, a different architecture is fine. The URL's job decides, not a slogan about React.

Link names: 191 of 191

Every single page with valid accessibility data had at least one link that failed axe-core's link-name rule.

That means the link's purpose was not programmatically available. A screen reader user gets something useless.

```html

```

An `aria-label` is *one* fix. Visible text, visually hidden text, `aria-labelledby`, or a real alt on a linked image may all be better depending on the component. And passing axe is not the goal. A link labeled "Social icon" passes the rule and still tells the user nothing.

Icon-only social links were a recurring example in our manual review. We did not classify every failure, so we are not going to tell you they were "usually" the cause, and we are not going to blame developers for not reading component-library docs. The library ships an SVG. Naming the link is the application's job.

Run axe-core in CI. It catches programmatically detectable regressions. It does not establish WCAG conformance, and it does not replace tabbing through the page yourself.

CLS passed most often, and that is all we know

165 of 193 passed. That does not mean developers "internalized" CLS, which is a claim about people we never studied.

It means serious load-time shift was less common in this lab test than poor LCP or FCP. Field CLS can be worse, because shifts happen after load through ads, embeds, late content, and app transitions. When CLS is bad, use layout-shift attribution to find the actual element. Do not guess from the score.

What is actually reproducible

The 292-row anonymized dataset with 41 documented columns is public under CC BY 4.0. Open data, not open source: the audit code is not in that release.

You can recalculate every number in this post and disagree with our thresholds. You cannot re-crawl the original 292 domains, because they are anonymized, and we did not package the browser traces, the per-violation records, or the exact environment.

The calculations are reproducible. The crawl is not. That is the honest boundary, and it is smaller than "anyone can rerun this."

There is no four-keyword fix

The old ending said every finding was fixable in an afternoon by a developer who knew four keywords: `priority`, `defer`, `font-display: swap`, `aria-label`.

That paragraph was the most confident and least true thing in the article. Those four terms do not touch slow servers, bad caching, client rendering, render-blocking CSS, main-thread work, field INP, post-load CLS, or a genuinely misleading accessible name. And link labels do not make a site slow; that sentence only existed because it completed a rhythm.

What the study found is narrower and still worth your time: poor simulated mobile loading and missing accessible link names were close to universal in this sample. No single cause, no single fix.

For each page that matters: compare the initial HTML against the rendered DOM, run repeatable lab tests, check field data if you have enough traffic to have any, find the actual LCP element, split its delay into server, discovery, download, and render, inventory your third-party scripts, test the font tradeoff, run axe in CI, tab through the page, and measure again after you ship.

The scanner finds the condition. The trace finds the cause. The second measurement tells you whether you fixed it.

Run the audit on your own site, then go argue with it.

So we built an RSS feed into our Next.js static site and pointed HackerNoon at it. Four files, roughly 50 lines. Here is what we changed, and the one detail that silently breaks the import.

What an RSS feed actually buys you

Import, not copy-paste. HackerNoon, Medium, and Dev.to can pull articles from a feed. You publish once on your own domain and import from there.

A canonical you control. You can declare the canonical URL in the feed and in the imported article, so the syndicated copy points back to the original. Whether a platform honors that is up to the platform, so after an import goes live, open the imported page, view source, and check that the rel=canonical is pointing at your URL. Do not assume.

One source of truth. The feed is generated from the same data as the blog, so nothing drifts.

That is the honest list. We are not going to tell you what the syndicated copies did for our rankings, because we have not measured it, and a backlink count is not a ranking.

The architecture

The site is Next.js with static export. No server, no runtime API routes. Everything is pre-rendered at build time and served from a CDN.

The blog posts live in a TypeScript array in one data file. Each post has a slug, title, description, date, author, tags, and the full content as a markdown string. Publishing means adding an object to the array and pushing.

For the feed, we added a route handler at /feed.xml that emits valid RSS 2.0. Because the site is a static export, Next.js pre-renders that route into a static XML file at build time.

The feed carries both a short description and the full article body in the content:encoded element. We convert the markdown to basic HTML inline: headings, bold, links, paragraphs. Nothing clever. It only has to be readable after import.

The four files

src/app/feed.xml/route.ts. The route handler. It loops the posts, converts markdown to HTML, and returns RSS 2.0 with the dc, content, and atom namespaces, served as application/rss+xml.

layout.tsx. A link rel="alternate" type="application/rss+xml" tag in the head so browsers and crawlers can discover the feed.

sitemap.ts. Updated to list individual blog post URLs. It had only listed the /blog index.

robots.txt. A line pointing at /feed.xml.

The gotcha

HackerNoon has an RSS import in the story editor. You paste the feed URL, it lists your articles, you select the ones to import, and they land in your drafts. Publishing still goes through their editorial review.

The importer needs the full article body in content:encoded. Our first attempt only shipped the short description in the standard description element, and the importer reported that it found no articles. It did not say why. Adding the full HTML body inside content:encoded, wrapped in CDATA, fixed it on the next build.

If an RSS importer tells you your feed is empty and you can see the items in the XML yourself, check content:encoded first.

Build it yourself

Create a route handler at src/app/feed.xml/route.ts that exports a GET function. Loop your posts, build the XML, return it as a Response with content type application/rss+xml. Include the content:encoded namespace and put the full article HTML inside a CDATA block. Add the link rel="alternate" tag to your root layout head, add post URLs to the sitemap, and add the feed line to robots.txt.

Build, deploy, then fetch the feed URL and read the XML with your own eyes before you point a platform at it. Half the import failures we have seen were visible in the raw feed.

Our feed is live at axiondeepdigital.com/feed.xml. If you want a second opinion on the rest of the site, we run a free audit that loads the page in Chromium and runs 60+ checks across nine categories. It does not check for an RSS feed, which is a gap we know about.

It also listed three things as mistakes that are not mistakes. That is the more damaging error, because it sends people off to fix problems they do not have, and it is the reason we are rewriting this instead of updating it.

Below: five problems we can actually document, with numbers where we have them, and three non-problems that the SEO industry keeps charging money to fix.

First, what we are counting

Where we cite a number in this post it comes from one of two datasets we published.

The 292-site study scanned 292 business sites; 191 returned a valid mobile verdict. These are Lighthouse lab measurements, and the sample came from a B2B prospect list, so it is purposive, not random. It tells you about that cohort. It does not tell you the odds that your site fails.

The 368-site AI-visibility study compared the rendered DOM against the raw HTML on 368 analyzable sites.

Anywhere we do not have a denominator, we say so instead of inventing one.

Problem 1: The page takes too long to show anything on a phone

This is the big one, and it is the only one on this list where we have a strong number.

Across the 191 sites with a valid mobile verdict, the median mobile LCP was 10.5 seconds, and 165 of 191 were over Google's 4 second "poor" threshold. Ten and a half seconds is not a slow page. It is a blank screen long enough for a person to leave.

The fix is not "compress your hero image." LCP is a composite of four delays: server response time, the delay before the browser discovers the LCP resource, the time to download it, and the render delay after it arrives. Find your LCP element in the Chrome DevTools performance panel, get the phase breakdown, and fix the largest phase. We wrote the full diagnostic in how to fix LCP on mobile.

Caveat we owe you: those are lab measurements. Google evaluates Core Web Vitals on field data at the 75th percentile of real loads. A bad lab number is a strong signal to go look, not a verdict.

Problem 2: Links and controls with no accessible name

In the 292-site cohort, 191 of 191 sites failed the accessible-link-name rule. That is not a typo. Every single site with a valid verdict had at least one link that announces as nothing useful to a screen reader: an icon with no label, a bare "click here," an image link with an empty alt.

Fix it because people cannot use the site. That is the whole reason. We are not going to tell you that accessibility work lifts your rankings, because Google has not said that and we have not measured it. An earlier version of this post claimed Google "factors accessibility signals into rankings." It does not, and we should not have written that.

The most common cause is a stylesheet that removes focus outlines globally. Use focus-visible instead of removing the outline, and give every icon-only control a real accessible name.

Problem 3: The content only exists after JavaScript runs

In the 368-site study, 92 of 368 sites (25 percent) lost at least one answer-critical element between the rendered DOM and the raw HTML. Body text on 57, links on 51, name-address-phone on 54.

Any crawler that does not execute JavaScript sees an empty shell on those pages. Google renders, on a queue, eventually. Plenty of other crawlers do not, and the behavior varies by crawler. The check takes thirty seconds: fetch your homepage with curl, or view source rather than inspect element, and look for your own phone number and your own headline in the raw response. If they are not there, they are not there for anyone who is not running a browser.

Problem 4: Your business identity is not stated in machine-readable form

Organization or LocalBusiness JSON-LD with your real name, address, phone, hours, and links to your real profiles. Served in the initial HTML, not injected by client-side script.

What this does is narrow: it removes the guesswork. A machine does not have to infer that the number in your footer is a phone rather than a fax. It does not earn you a rich result on its own, it does not earn you the map pack, and it is not lead generation. Do not mark up reviews of your own business, which Google's structured data policy excludes as self-serving. Details in what structured data actually does.

Problem 5: Pages nothing links to

A page with no internal links pointing at it and no sitemap entry can sit unindexed indefinitely. We did this to ourselves: we shipped six city landing pages that nothing on the site linked to and then wondered why they did not rank. They were not penalized. They were undiscovered.

Publish a sitemap, reference it from robots.txt, and then do the thing that actually matters, which is linking to the page from somewhere a human would plausibly click. A sitemap is a hint. An internal link is a path.

Three things that are not mistakes

Multiple H1 tags. Not an SEO failure. Google has said explicitly that multiple H1s are fine and that it can figure out page structure regardless. Our own audit tool used to flag this as an error. That rule was wrong, it inflated our own failure counts, and we downgraded it to a warning.

A missing meta description. Google generates a snippet from the page content anyway, and it rewrites the description you wrote most of the time regardless. Writing one is worth doing, because occasionally you get to control the snippet. Not writing one does not get you buried. An earlier version of this post said Google would auto-generate "whatever random text it finds," implying harm. Google's snippet generation is not random and its absence is not a penalty.

Word count. There is no minimum. There is no 800-word rule, no 300-word rule, no rule at all. A 60-word homepage is not a ranking violation. It is a prompt to go read the page and ask whether it answers what a visitor came to find out, which is a content question and not a technical one. We have used a 300-word threshold in our own audits as a flag to prompt a human review, and we should have been clearer that it is a prompt, not a verdict.

Things worth doing that we are not going to oversell

Open Graph tags control the card that appears when your link is shared. That is their job. They are not a ranking factor and we have not measured a click-through effect, so we will just say: without them the platform picks something for you, and you will not like what it picks.

Valid HTML is a code health signal. Google tolerates broken markup and has for twenty years, so forty validation errors will not sink your rankings. Forty validation errors do tell you something about the state of the codebase, which is a different and still useful thing to know.

Check your own site

Our free audit loads your page in Chromium and inspects the rendered DOM across 60-plus checks in 9 categories. It takes about 60 seconds and requires no signup. It will show you the numbers. What it will not do is tell you your business is failing because of a missing meta description.

We want to make a narrow version of that argument, because the broad version gets oversold.

What we can measure

We scanned 292 business websites drawn from a B2B prospect list. 191 returned a valid mobile result. 185 of those 191 failed at least one Lighthouse lab threshold. 165 had a lab Largest Contentful Paint over four seconds, and the median across the cohort was 10.5 seconds.

Two caveats that we will repeat every time we cite this. These are lab measurements. Google's Core Web Vitals come from field data collected from real users, and one of them, Interaction to Next Paint, we never measured at all. And the sample was purposive, not random, so it describes that cohort. It does not give you a probability about your site.

In a separate crawl we analyzed 368 sites. On 92 of them, an element that matters for answering a basic question about the business was present in the rendered page and absent from the raw HTML: body text on 57 sites, links on 51, and business name, address, or phone on 54. Systems that read the raw response rather than running the page see less of those businesses than a person does.

What that does and does not tell you

It tells you that slow mobile rendering and rendering-dependent content are common conditions in this population. It does not tell you what they cost. We did not hold revenue data, Search Console data, or field performance for any of those sites, so we cannot say that a ten-second Largest Contentful Paint lost anyone a customer. It certainly did not help. That is as far as the data goes, and we would rather stop there than invent the rest.

What the page owes the rest of the stack

Ads, email, and organic search all deposit a person on a page with an intent and a limited amount of patience. What the page owes them is fairly narrow.

It has to render the thing they came for. The content should be present and readable without waiting on a chain of scripts. Diagnosing that is web development work, not copywriting.

It has to be legible to clients that do not run JavaScript. Some crawlers render and some do not, and the behavior varies by crawler. If your services, your address, and your phone number only exist after hydration, you are betting on that behavior going your way.

It has to state what the business is. Structured data, an accurate business name, current services, and correct contact details are not SEO tricks. They are the machine-readable version of facts your operations team already owns.

It has to record what happened. If a session cannot be traced to a form fill, a call, or a CRM record, then no channel that fed it can be evaluated honestly. That is what lead capture is for, and it is a measurement problem before it is a conversion problem.

Where to start

Start with a diagnostic, not a fix list. Find your actual Largest Contentful Paint element on mobile, then split the delay into time to first byte, resource discovery, download, and render. That tells you which team owns the problem. Optimizing images while your server takes 1.8 seconds to respond is wasted work.

Then look at what a non-rendering client sees. Fetch your own page without JavaScript and read what comes back. If your services, your address, and your phone number are missing from it, you have found a real condition worth fixing. Whether fixing it is a template change or a platform migration depends on how the site was built, and we are not going to pretend that is always small.

The question worth taking to leadership

For the demand we want, are we being considered, and can we connect that visibility to qualified revenue?

Marketing cannot answer that alone. Engineering owns rendering and performance. Operations owns the accuracy of the business information. Subject-matter experts own whether the claims are true. Sales and the CRM own whether attention becomes revenue. Leadership's contribution is making sure those are measured together instead of separately, and that no single team is graded on an outcome it cannot reach.

If you want a baseline, run a free audit. It loads the page in Chromium, inspects the rendered DOM, and reports 60 or more checks across nine categories. It reports conditions, not dollars.

That distinction is the point of this post, and it is the one most audit tools blur. A scan can tell you that your mobile Largest Contentful Paint is nine seconds, that your services page carries no structured data, and that your phone number is absent from the raw HTML. It cannot tell you that any of that cost you a customer, because it never saw a customer.

What an audit actually inspects

Our free audit loads your page in Chromium and inspects the rendered DOM. It does not parse the raw HTML response, and it is not Googlebot. Google crawls, queues, renders, and indexes on its own schedule, and no third-party tool reproduces that pipeline. What we can honestly say is that we look at the page after JavaScript has run, which is closer to what a person sees than a raw fetch is.

It runs 60 or more checks across nine categories: technical, content, on-page, social, security, performance, accessibility, AI readiness, and locality. A deep scan crawls up to 50 pages. It waits for network activity to settle, with a 20-second ceiling. It does not scroll and it does not click, which is deliberate, because Google Search does not interact with your page either.

Why raw-HTML tools miss things

Most free scanners request your URL, take the HTML response, and parse it. On a server-rendered site that is fine. On a site built with React, Vue, Svelte, or a modern site builder, the response can be close to empty and the real content arrives only after JavaScript runs.

This is measurable. We crawled 405 sites and analyzed 368. On 92 of them, something answer-critical was present in the rendered page and absent from the raw HTML: body text on 57 sites, links on 51, and business name, address, or phone on 54. A tool reading only the raw response would have reported thin or missing content on those 92 sites.

That is one in four of the sites we analyzed. It is not a majority, and we are not going to describe it as one.

The conditions we see most often

We will only give you numbers we actually have.

In our 292-site study, 191 sites returned a valid mobile result. Of those, 185 failed at least one Lighthouse lab threshold, 165 had a lab Largest Contentful Paint over four seconds, and the median was 10.5 seconds. The Lighthouse link-name rule, which flags links a screen reader cannot announce, failed on all 191.

Those are lab measurements from a purposive sample of B2B prospects. They are not field data, they do not tell you your odds, and Core Web Vitals is a different measurement taken from real users. We publish the denominators so you can judge the claim for yourself.

Why we will not tell you what it is costing you

Most tools in this category want to hand you a dollar figure. We will not, because proving cost requires four things a scan does not have.

Search Console. Impressions, queries, and average position tell you whether you are being seen at all, and for which searches.

Field performance data. Real users, on real devices, over real networks, rather than one lab run from a data center.

Analytics. What visitors did after they arrived, where they left, and which pages preceded a conversion.

A before and after. Fix the condition, wait, and compare. Without that, a real improvement and a seasonal swing look identical.

An audit is the cheapest of those four and the only one you can run on a site you do not own. It tells you where to point the other three. It does not replace them.

What to do with the report

Read it as a list of conditions, ranked by how much work it would take to address each one, and not as a list of leaks. Some items are genuinely small: a missing title tag, a page with no description, images without alt text. Others look small in a report and are not. Changing how a site renders, restructuring templates, or replacing a page builder is real engineering work, and we are not going to call it an afternoon fix.

Then route the conditions to the people who own them. Rendering and performance belong to engineering. Business name, hours, and service accuracy belong to operations. Whether the claims on the page are true belongs to whoever does the work. Whether a visit becomes pipeline belongs to sales and the CRM.

Above all of them sits one question: for the demand we want, are we being considered, and can we connect that visibility to qualified revenue?

Run a free audit to get the baseline. Then go get the data the audit cannot see. If you want help reading the results, book a call and we will walk through them with you.

We build with React and Next.js. That is our bias, and you should read the rest of this with it in mind. It is also why we want to be careful here, because the easy version of this article is a sales pitch wearing a lab coat.

What WordPress is actually good at

WordPress began as a blogging tool and grew into a general content management system. Its strength is the ecosystem and the editing experience.

Non-developers can publish. If your team needs to add a page, swap an image, or push a post without opening a code editor or waiting on a developer, WordPress does that out of the box. This is not a small thing. It is the single most common reason businesses stay on it, and it is a good reason.

The ecosystem already solved your problem. Events, forms, memberships, e-commerce through WooCommerce, redirects, sitemaps. Someone has built it. For a business with ordinary requirements and a limited build budget, that shortens the path to launch.

It renders on the server by default. A standard WordPress theme sends complete HTML in the first response. That matters more than most people realize, and we will come back to it.

The cost is that someone has to own it. Core updates, plugin updates, security patches, hosting, and the occasional plugin that breaks another plugin. That work does not disappear if you ignore it. It just accrues.

What React and Next.js are actually good at

React is a library for building interfaces. Next.js is a framework on top of it that adds routing, server rendering, static generation, and API routes.

You control the output. Every meta tag, every heading, every piece of structured data is something you wrote on purpose. Nothing is generated by a plugin you have not read.

Static output is cheap and hard to break. Next.js can build your site to static HTML at deploy time and serve it from a CDN. There is no PHP process, no database, and no admin login at runtime, which removes an entire category of attacks and an entire category of maintenance.

Custom behavior is not a fight. Interactive tools, unusual layouts, direct API integrations, and custom lead capture flows are ordinary work in a codebase and awkward work inside a page builder.

The cost is that you need a developer. There is no drag and drop path. Content edits either go through a developer, or you add a headless CMS, which adds a moving part back.

The performance question, honestly

The usual version of this section lists Lighthouse ranges for a "typical WordPress site" and a "typical React site." We are not going to do that, because we have not measured it, and neither has anyone who publishes those ranges without a dataset attached.

Here is what we did measure. In our 292-site study, 191 sites returned a valid mobile verdict and 185 of those 191 failed at least one Lighthouse threshold. The median mobile Largest Contentful Paint was 10.5 seconds. Those are lab measurements taken from a purposive B2B prospect list, not a random sample of the web, and the dataset does not record which platform each site was running. So we cannot tell you that WordPress sites are slow and React sites are fast. Our data does not know.

What we can tell you is mechanical, and you can verify it on your own site in ten minutes.

A default WordPress page ships the theme stylesheet, the theme JavaScript, and the assets of every active plugin, whether or not the current page uses them. Page builders add markup depth and inline styles. None of that is fatal. A well-tuned WordPress site behind a page cache and a CDN can be genuinely fast, and plenty of them are.

A statically exported Next.js page ships prebuilt HTML plus the JavaScript that page actually needs. That is a better starting position. It is not a guarantee. A React application that renders everything in the browser can be slower than the WordPress site it replaced, and we have watched that happen.

On ranking: Google has said page experience signals, including Core Web Vitals, are used in ranking. They are one input among many, and they do not override relevance. "The faster site ranks higher" is not a rule of the universe. Fix speed because slow pages are unpleasant to use and people leave. That is reason enough.

The SEO question, including the part that goes against us

This is where the standard version of this article overreaches, so here is the finding that argues against our own preferred stack.

In our AI visibility study, we crawled 405 business sites and analyzed 368 of them, comparing the fully rendered page against the raw HTML that a non-rendering crawler receives. 92 of the 368 lost at least one answer-critical element, meaning body text, links, or contact details present on screen but absent from the raw response.

Broken out by platform, by count:

- Wix: 1 of 35 - Webflow: 1 of 15 - GoDaddy: 4 of 20 - Squarespace: 13 of 46 - WordPress: 37 of 139 - Other and custom builds: 34 of 107

Custom builds were the worst group in that study. The hosted builders were the best. If your prior was "custom code is better for SEO because you control the output," our own data says the control cuts both ways.

The mechanism is not mysterious. WordPress and the hosted builders send HTML from the server, so the content is in the response by default. A custom build is only as good as the rendering strategy someone chose. A Next.js site that is statically generated or server-rendered puts the content in the raw HTML, and it is excellent. A client-rendered React application ships an empty shell and fills it in with JavaScript, and to any crawler that does not execute that JavaScript, the page is close to blank. A large share of those 34 failures look like exactly that.

The framework does not save you. The rendering strategy does.

So read the number correctly. It says custom is worst in practice, not worst in potential, and those are different claims. The builders have a high floor: they server-render by default, so the median site is safe without anyone thinking about it. You also cannot climb past their ceiling. Custom has the lowest floor and the highest ceiling. An unguarded client-rendered app that ships an empty shell is the worst outcome in our data. A server-rendered or statically generated custom build is the best outcome available to anyone, because you own the rendering path instead of inheriting it.

We are not asking you to take that on faith. This site is custom Next.js. It scores 100 out of 100 on our own deep scan and 10 out of 10 on AI readiness, and you can run both yourself. No builder can be instructed to do that.

The honest decision rule: choose custom when you will actually do the work, and prove it with a scan. Choose a builder when you will not, because a high floor beats a ceiling you never climb. If you take one technical thing from this article, take this: view the source of your own homepage, not the inspector, the actual raw source, and confirm your headline and your phone number are in it.

Cost

We are not going to publish dollar ranges here, because any range we invent would be a guess dressed up as research. What we can give you is the shape of the spending.

WordPress spends steadily: hosting that runs PHP and a database, plugin and theme licenses that renew annually, the labor to apply updates and patches, the occasional hours lost to a plugin conflict, and a rebuild when the theme or builder ages out.

Custom spends up front: a larger initial build, then dependency updates, then a developer any time the structure changes. Static hosting is cheap or free at small-business traffic levels, and there is nothing to patch on a schedule.

We walk through the full model, with the assumptions written down, in WordPress vs custom React: the real cost. Get three quotes before you believe anyone's numbers, including ours.

The question that actually decides it

Who maintains this site in eighteen months?

If the answer is "our marketing coordinator, weekly, without a developer," you want WordPress or a builder, and you want someone to tune it properly. If the answer is "our developer, or an agency on retainer, and the content changes rarely," custom code is a better fit and a lower ongoing burden.

Most platform arguments are really this question with the labels filed off.

When WordPress is the right call

Your team edits content often and cannot wait on a developer. You need plugin functionality that would be expensive to rebuild. You are running a content-heavy site with hundreds of pages. Your build budget is small and you need to be live soon.

When React and Next.js are the right call

The site is largely stable and structural changes are rare. You want the smallest possible ongoing maintenance surface. You need custom interactivity, direct API work, or lead capture wired into the architecture rather than bolted on. You want to remove the plugin and admin panel attack surface entirely.

Either way, the rendering strategy is not optional. If you go custom, pre-render.

What we did not measure

We have not measured platform-segmented performance. We have not measured conversion rate by platform. We have not measured rankings by platform. Anyone who tells you a platform choice determines your rankings is filling in a blank they did not measure either.

Where to start

Run your current site through our free SEO audit and look at what it reports before you decide anything. If you want a second opinion on the tradeoff, book a consultation and we will tell you when staying put is the right answer, which happens more often than an agency blog usually admits.

What is actually different

Google shows AI-generated summaries above the results for many queries. Assistants like ChatGPT, Perplexity, and Copilot answer questions directly, and some of them cite sources and link out. That is real, and it is visible to anyone.

What follows from it is less clear than the industry pretends. A summary that answers the question can reduce clicks for that query. It can also send a click that would never have happened. We have seen confident percentages for the size of that effect, and we have not seen a methodology behind them that we would defend in public, so we are not going to repeat them.

"The ChatGPT crawler" is not one thing

This matters because people make rendering and robots.txt decisions based on a single imagined bot.

OpenAI documents several distinct user agents with different jobs. GPTBot collects data for model training. OAI-SearchBot builds the index behind ChatGPT search. ChatGPT-User fetches a page because a user, in a live conversation, asked about it. Other vendors run their own separate agents on the same pattern.

Blocking one does not block the others. Those agents differ in how they handle JavaScript, and the honest position is that this varies by crawler and changes without announcement. Anyone who tells you flatly that AI crawlers do not run JavaScript is describing some of them, not all of them, and probably not this month.

llms.txt is a proposal, not a protocol

llms.txt is a proposed convention: a markdown file at the root of your domain describing your site for language models. It has a spec and it has advocates. It does not have adoption commitments from the major AI vendors.

So, plainly: not having llms.txt does not make your business invisible to ChatGPT. Adding llms.txt does not put you into AI answers. Anyone selling either claim is selling you a file that takes ten minutes to write.

We publish one on this domain. It costs almost nothing, it might matter later, and we have no evidence it has done anything for us so far. That is the entire honest case for it.

The one thing we measured

Assistants that read the live web still have to get your content out of an HTTP response. If the content only appears after JavaScript runs, a crawler that does not render sees a page with nothing in it.

We ran 405 business websites through our crawler and got 368 analyzable results. We compared the rendered DOM to the raw HTML the server returned. In 92 of those 368 sites, at least one answer-critical element was present after rendering and absent from the raw HTML. Body text was missing in 57 cases, links in 51, and name, address, or phone details in 54.

Those sites were not selected at random, so this is not a probability that applies to your site. It is a defect we found often enough that checking for it is worth ten minutes of your time. View the page source, not the DOM inspector, and search it for a sentence you can see on the screen. If the sentence is not in the source, your content depends on the crawler choosing to render, and not all of them do.

By platform, the counts were: WordPress 37 of 139, Other or custom builds 34 of 107, Squarespace 13 of 46, GoDaddy 4 of 20, Wix 1 of 35, Webflow 1 of 15. One affected site out of 35 is not a platform verdict, so we are not going to declare a winner or a loser here.

Where AI answers actually come from

An assistant answering a question about a local business is not reading only your website. Depending on the system and the question, it may be drawing on a search index, map listings, review platforms, business directories, press coverage, and its own training data. Some of that data is years old. Some of it is other people's descriptions of you.

The practical consequence is that your website is one input among several, and the ones you do not control can contradict it. If your address is wrong in three directories, no amount of schema on your homepage settles the argument.

What we do not know

We do not know how any assistant weights its sources. We do not know whether structured data influences AI citation, though we add it anyway because it has separate, documented uses in search. We do not know how often the AI systems recrawl. We cannot show you that any change we have made to a site caused it to appear in an AI answer, and we have not seen anyone else demonstrate that causal link either.

Anybody offering you an "AI SEO" service with a guaranteed mechanism is describing a system they have not been shown.

What is worth doing anyway

The useful list is short, and every item on it was already worth doing before AI answers existed.

Put your content in the HTML. If a crawler has to run your JavaScript to learn what you sell, you are depending on a step that some crawlers skip.

Make the factual claims about your business easy to extract and identical everywhere. Name, address, phone, hours, services, service area. Same on your site, your Google Business Profile, and every directory that lists you.

Answer real questions in plain language on pages that exist for that purpose. Systems that summarize text reward text that is already clear.

Be present in the sources these systems read. Reviews, directories, and press are not website work, and they are where a large share of the material about you actually lives.

Keep your own measurement. Search Console still tells you what Google does with your pages. Nothing equivalent exists for assistants yet, so treat any dashboard claiming to measure your "AI visibility" as an estimate, including ours.

The honest status

We have measured one specific, real AI-visibility failure and we have written about it. On the rest of it we are working from the same public statements and the same guesswork as everyone else, and we will keep saying so until somebody publishes something better. When we can show that a change we made caused an AI system to cite a client, we will publish that too, along with the method.

We made that up. Not the sentiment, the arithmetic. It was built by stacking three conversion statistics from different studies, different industries, and different decades, applying them multiplicatively to a hypothetical business, and printing the result as if it were a forecast. Nobody should do that, including us, and if a vendor hands you a number like it, ask which study, which year, and which sample.

Here is what the evidence actually supports, with sources, and here is what it does not.

What is genuinely documented

Google and Deloitte, "Milliseconds Make Millions" (2020). Deloitte instrumented mobile site data from 37 brands across retail, travel, luxury, and lead generation in Europe and the US over four weeks, and isolated speed against funnel outcomes. For a 0.1 second improvement in mobile site speed they observed:

- Retail conversions up 8.4 percent, average order value up 9.2 percent - Travel conversions up 10.1 percent, average order value up 1.9 percent - Luxury page views per session up 8.6 percent - Lead generation bounce rate improved 8.3 percent

Read the caveats with the numbers. This is observational, not a randomized experiment. Speed was correlated with outcomes across large brands with real traffic volume. It is the best-sourced speed-to-revenue evidence in public, and it still does not license you to promise an individual small business a specific dollar recovery.

Google and SOASTA (2017). A machine-learning model built on real mobile e-commerce data found that the probability of a bounce increases by 32 percent as load time goes from 1 to 3 seconds, by 90 percent from 1 to 5 seconds, and by 123 percent from 1 to 10 seconds.

Note what that sentence says. It is a relative increase in the probability of a bounce, from a predictive model. It is not "you lose 90 percent of your visitors at five seconds," and the old version of this post came uncomfortably close to implying that.

Our own 292-site study. 191 of 292 sites returned a valid mobile verdict. The median mobile LCP was 10.5 seconds, and 165 of 191 were over 4 seconds. That is a lab measurement on a purposive B2B sample, so it does not give you the odds that your own site is slow. It does tell you that a ten-second mobile page is unremarkable in the wild, which is the part most business owners do not believe until they see their own trace.

What we deleted, and why

The following claims appeared in the previous version of this post and are now gone.

| Claim we printed | Problem | |---|---| | "A one-second delay reduces conversions by 7 percent" | Unsourced. Traces back to a vendor blog citation chain with no accessible primary study. | | "A five-second site has a 90 percent higher bounce rate" | Misstates the SOASTA finding, which is about bounce probability, not bounce rate. | | "A 100ms delay reduces conversion rates by up to 7 percent" | Attributed to nobody. We could not find the primary source. | | "A one-second improvement can increase conversions 27 percent on mobile" | Same. | | "Walmart found conversions increased 2 percent per second" | Real, from a 2012 conference talk, about a 2012 web. We are not going to lean on it. | | "You could recover 1,200 to 2,700 dollars a month" | Fabricated by stacking the above. |

We are keeping the correction visible rather than silently editing, because the whole point of this post is that unsourced numbers are how the speed conversation got dishonest in the first place.

Speed and rankings, stated carefully

Google has confirmed that page experience, including Core Web Vitals, is used as a signal in ranking. Google has also said, repeatedly and in public, that it is a small signal and that relevance matters far more. A fast page about nothing does not outrank a slow page that answers the question.

The three current Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift, measured on field data at the 75th percentile of real page loads. Lighthouse gives you a lab number on a single simulated load. First Contentful Paint is not a Core Web Vital. If a tool tells you that you "failed Core Web Vitals" based on one Lighthouse run, it is telling you something, but it is not telling you that.

So the ranking argument for speed is real and modest. The user argument for speed is the strong one. A ten-second blank screen on a phone loses people, and you do not need a ranking algorithm to explain why.

Diagnose before you spend

The most expensive mistake in this whole area is buying a fix for a problem you have not located. LCP is a composite of four delays, and every real fix belongs to exactly one of them:

1. Server response time. Hosting, redirects, cold starts, server-rendering work. 2. Resource load delay. The gap before the browser even discovers the LCP resource. A discovery problem, not a bytes problem. 3. Resource load duration. How long the file takes to download. This is the only phase image compression touches. 4. Render delay. Blocked rendering, hydration, and JavaScript animations that keep the element from painting after it has already arrived.

Chrome DevTools gives you this breakdown. Record a load with mobile throttling, click the LCP marker, read the phases. Google itself warns against assuming the answer is image compression, and we have seen sites where the hero was already small and the entire ten seconds lived in server time and a fade-in animation. Compressing that hero would have accomplished nothing.

Full walkthrough: how to fix LCP on mobile.

What we have not measured

We have never run a controlled before-and-after on a client site measuring revenue against a speed change. No holdout group, no randomization, no attribution model. Neither has any agency that has quoted you a dollar figure. If we ever do run one, we will publish it, including if it comes back flat.

What we do measure is the technical number, and we will tell you honestly when the technical number is bad and honestly when we do not know what it is worth to you.

Where to start

Run your own page through our free audit, or straight through Chrome DevTools, and get your LCP and your phase breakdown. Then check Google Search Console for the field Core Web Vitals of your real visitors, which is the only data that reflects the people actually trying to use your site.

If the numbers are bad and you want help, book a call. We will show you the trace before we quote you anything.

We cannot support that number, so we cut it. Nobody has measured "the average business website." The benchmarks in circulation come from vendors summarizing their own customer bases, which are not a random sample of the web and are not a sample of your site. A number you cannot trace is not a baseline. It is decoration.

Here is what we can show you instead, because it is our own site and we can check it.

The only conversion numbers in this post we can actually stand behind

In July 2026 we audited our own Google Analytics property. Two things came out of it.

Roughly 90 percent of our recorded traffic was bots. After filtering, real human traffic to axiondeepdigital.com was around three people per day, not the several hundred per month the dashboard implied.

And of the visitors who did engage, 80 completed a free SEO audit on our site. Those 80 completions produced 2 clicks on the booking link.

We are the case study. We built the audit tool, we wrote the copy, we run the funnel, and the step from "this person just spent 60 seconds getting a report from us" to "this person asked to talk to us" is where our own site loses almost everyone. No widget was missing. The path was.

What we removed from this post

An earlier version of this article said that responding to a lead within five minutes makes you 21 times more likely to qualify it, and implied that figure came from Harvard Business Review. It does not. The 21x number traces to a separate lead response study and we should not have attached HBR's name to it.

The same version claimed exit intent popups convert at 2 to 4 percent. We have no source for that and we deleted it.

We are leaving those corrections here on purpose. If you have quoted this post, quote the corrected version.

The claim about response time we will still make

Harvard Business Review published "The Short Life of Online Sales Leads" in 2011, based on 2,241 US companies. Firms that made contact within an hour of an inquiry were about seven times more likely to have a qualifying conversation with a decision maker than firms that waited even one hour longer. The average first response time across the sample was 42 hours. Twenty three percent of companies never responded at all.

That study is old and it is not about your industry specifically. It is still real, published, and checkable, which is more than can be said for most numbers in this category. Response time is the one lever in lead capture where we can point at evidence rather than at a feeling.

Why one contact form under-captures

We are not going to tell you a percentage of visitors your contact form is losing, because we do not know it and neither does anyone selling you a replacement for it. We can tell you the mechanics of why a single form is a narrow instrument.

It only catches decided people. A form that says "contact us for a quote" is available to visitors who have already chosen to enter a sales conversation. Visitors who are still comparing options have no move available to them other than leaving.

Every required field is a decision. Name, email, phone, company, budget, "how did you hear about us." We are not claiming a fixed percentage lost per field. We are saying each field is another moment where a person can decide this is not worth it, and you will never see the ones who decided that.

"Contact us" is a request, not an offer. It asks for personal information and promises nothing specific back. "Get a free audit of your site in 60 seconds" states what the visitor receives. That is a real difference in what you are proposing, whatever it does to your numbers.

Capture is not follow up. A submitted form that lands in an unwatched inbox has been captured and lost in the same motion. See the response time evidence above.

Instrument the path before you add anything to it

This is the part most lead capture advice skips, and it is the part that actually changed our own behavior.

Traffic, leads, and revenue are three different measurements. Most sites cannot connect them at all. They have a traffic number from analytics, a lead count from an inbox, and a revenue number from accounting, and no shared identifier joining any of them. When leads are low, there is nothing to look at, so the default move is to install another tool and hope.

Do the boring thing first. Make each step of the path emit an event you can count:

1. Landing page view, with bot traffic filtered out 2. Form or tool started 3. Form or tool completed 4. Contact information captured 5. Lead qualified by a human 6. Revenue closed, tied back to the source

Then check the honesty of your own instrumentation before you interpret it. Our audit funnel appeared to be collapsing between "started" and "completed" until we looked closely. The two events were fired under conditions that made them incomparable. Actual completion was around 80 percent, which is fine. The real drop was one step further down, at booking, and we had not been counting it.

An instrumentation bug will happily tell you to fix the wrong thing for months.

The mechanisms, honestly described

Once you can see the path, the tools become choices rather than acts of faith.

Chat. A chat agent changes when a visitor can get an answer, and it changes response time, which is the lever with actual evidence behind it. We use one. We are not going to tell you it will multiply your leads, because we have not run that experiment on your site or on a representative sample of sites.

A free tool as the offer. Our free SEO audit gives visitors a report on their own site in about a minute. It works as an offer because the value is specific and immediate. Note carefully that it works for us as an offer and still fails us at the next step, which is why the previous section exists.

Booking instead of forms. For consulting work, a booking link removes the round of email that a form introduces. One click, pick a time. That is a shorter path, which is a claim about the path, not a promise about the outcome.

CRM sync. Every capture should land in one system automatically. This is not a growth tactic. It is bookkeeping. Without it, step 4 above cannot be counted.

What to measure once it is wired up

Completion rate per mechanism. Of the people who start your form, tool, or chat, how many finish?

Handoff rate between steps. Ours is the interesting one: audit completed to booking clicked. If a step loses almost everyone, that step is the work.

Time to first human response. Measured, not estimated. Submit a test lead on your own site on a Friday evening and time it.

Lead to customer rate. A large number of unqualified leads is not a result.

Start with one thing

If you cannot connect traffic to leads at all, instrument the path. That is the first job and it is unglamorous.

If you can see the path and one step is bleeding, fix that step. Do not add a widget to a step that is already working.

If your response time is measured in days, that is where the evidence says to spend your attention.

We are doing exactly this on our own site right now. The booking step is the leak. We have not fixed it yet, and when we do, we will report whether it moved anything.

Run a free audit if you want the technical picture of your site, or book a consultation if you want us to look at the path with you.

Then we ran a study that contradicted us, so we are rewriting it.

The finding that changed our mind

In our AI visibility study, we crawled 405 business websites, analyzed 368 of them, and compared the fully rendered page against the raw HTML that a non-rendering crawler receives. 92 of the 368 lost at least one answer-critical element: body text, links, or contact details that a human sees on screen but that never appear in the raw response.

Broken out by platform, as counts:

- Wix: 1 of 35 - Webflow: 1 of 15 - GoDaddy: 4 of 20 - Squarespace: 13 of 46 - WordPress: 37 of 139 - Other and custom builds: 34 of 107

Custom builds were the worst-performing group in that study. The hosted builders were the best. Squarespace landed in the middle, roughly where WordPress did.

That is the opposite of the article we originally published, and it is the most useful thing we can tell you, so we are leading with it rather than burying it.

Why custom builds lost

The mechanism is not a mystery, and it is not an argument against custom code as such. It is an argument against one specific way of building custom sites.

A hosted builder like Squarespace or Wix sends HTML from its servers. Whatever is on the page is in the response. A custom build sends whatever the developer decided it should send. If that developer built a client-rendered React application, the browser receives a mostly empty document and JavaScript that fills it in afterward. A crawler that executes JavaScript will see the content. A crawler that does not will see close to nothing. Many crawlers, including several that feed AI answer systems, do not.

So "custom" is not a quality tier. It is a blank check, and the check can be written badly. A statically generated or server-rendered Next.js site puts every word in the raw HTML and is genuinely excellent on this measure. A single-page React application that renders in the browser is worse than the Squarespace site it replaced. Both get called "custom code" in a sales meeting.

If you take one action from this article, view the raw source of your own homepage, not the browser inspector, the actual source, and search it for your headline and your phone number. If they are not there, your platform is not the problem. Your rendering strategy is.

What Squarespace is genuinely good at

Speed to live. Template, content, domain, done. For a business that needs a presence this month, that has real value, and paying an agency to spend six weeks reproducing it is a poor use of money.

Nobody has to maintain it. No plugin updates, no PHP version bumps, no patch schedule, no attack surface you are responsible for. That work does not land on your desk, and it does not land on a retainer.

Non-developers can edit it. This is the row that quietly decides most of these decisions. If your team changes content weekly, a builder removes a developer from the loop permanently.

It serves real HTML. Per our own numbers above, this is not nothing.

Where Squarespace actually constrains you

Now the honest limits, with the sales copy removed.

Structured data. Squarespace generates some schema automatically. Adding your own JSON-LD for FAQ, HowTo, Product, or a detailed LocalBusiness graph means working through code injection, and you do not control the surrounding markup. This is a real constraint. It is not a ranking penalty, and structured data does not earn you rankings, it makes you eligible for certain result formats.

HTML output. You do not choose the DOM order or the heading hierarchy. For most sites this does not matter. For a large content site with a deliberate information architecture, it starts to.

Page weight. A builder ships its platform runtime on every page, including code for features your page does not use. A hand-built static page ships less. That is a real difference and you can measure it on your own site with any Lighthouse run. What we will not do is tell you it costs you customers, because we have not measured that and neither has anyone else who says it.

Custom functionality. A pricing calculator, a bespoke booking flow, a product configurator, a direct API integration, an AI chat integration wired into your data. These are ordinary work in a codebase and awkward or impossible inside a builder.

Portability. You own your content, not your build. Leaving means rebuilding. Weigh that at the start, not at the end.

The cost comparison, done honestly

The original version of this post ran a three-year total cost table with confident numbers in it. Those numbers were invented. We are keeping the structure and throwing out the figures.

The model has five rows: the initial build, the monthly platform fee for the three years, any paid add-ons or integrations, hosting for the custom option, and developer hours for changes. Fill them in with real quotes.

The shape it produces is consistent. Squarespace costs less over three years. It costs less over five. The custom build is not cheaper, and any article telling you it is has hidden a rebuild assumption or a lost-revenue estimate in the arithmetic.

What you buy with the difference is control, ownership, a smaller runtime, and the ability to build things the builder cannot build. If you do not need those things, you are buying something you will not use.

When to actually leave Squarespace

Not because it is Squarespace. Leave when you hit a wall you can name.

You need functionality the platform does not support and cannot be made to support. You have hit a real performance ceiling that you have measured, not assumed. You need structured data or markup control the platform will not give you. You are paying for a stack of add-ons that a single build would replace. You are building a product experience rather than publishing a brochure.

If none of those is true, stay. A well-built Squarespace site outperforms a badly-built React site, and our own data says so.

What we did not measure

We have not measured conversion rate by platform. We have not measured rankings by platform. We have not measured revenue before and after a migration, for a client or in a study. We measured one thing, whether the content survives into raw HTML, and on that one thing the hosted builders beat the custom builds.

Anyone who tells you a platform choice determines your rankings is filling in a blank they did not measure either.

Where to start

Run your current site, Squarespace or otherwise, through our free SEO audit and look at what it reports. Then, if you want a second opinion, book a consultation or contact us. Part of our job on a web development call is telling people that a rebuild will not fix their problem. We do it more often than you would expect.

We are going to build that model with you. Before we do, one thing has to be said plainly, because the original version of this post did not say it.

The numbers in this article are assumptions, not measurements. We did not survey vendors. We did not audit a sample of invoices. Nobody has published a credible total cost of ownership study for small business websites, ours included. What follows is a spreadsheet you can fill in with your own quotes. Every figure we use as an example is labeled as an assumption, and you should replace all of them.

We also build with React and Next.js, which means we have a commercial interest in how this comes out. Read accordingly, and check our arithmetic.

The line items nobody puts in the quote

Whatever platform you pick, the real cost has more rows than the proposal does. Here is the full set.

WordPress line items

1. Initial build or theme customization, paid once, repeated at each redesign. 2. Hosting that runs PHP and a database. Cheap shared hosting and managed WordPress hosting are different products at different prices. 3. Plugin and theme licenses, renewed annually, one renewal date per vendor. 4. Update and patch labor. Core, plugins, and themes ship updates continuously. Somebody applies them, and when a security advisory lands, somebody applies it that day. 5. Conflict debugging. Plugins are written by different people. Sometimes an update to one breaks another. 6. Performance work. Caching configuration, image handling, database cleanup, script auditing. 7. The redesign cycle. Themes and page builders age. At some point the cheapest path forward is to rebuild.

Custom React and Next.js line items

1. Initial build. This is the big one and it is bigger than the WordPress equivalent. 2. Hosting. Static output on a CDN platform is inexpensive at small business traffic, and free tiers cover a lot of sites. 3. Dependency updates. A few hours a year on a well-built project. 4. Developer time for any structural change, including content changes if you did not add a CMS. 5. A headless CMS subscription, if your team needs to edit content without a developer. Leave this out and you have moved a cost, not removed it.

Note that item 5. It is the row most React advocates quietly drop, and it is where the "no maintenance" story goes soft.

The model

Three-year cost equals the initial build, plus 36 months of hosting, plus 3 years of licenses, plus the annual maintenance hours multiplied by your developer's rate, plus a rebuild if one falls inside the window.

That is the whole model. It is not complicated. What makes it useless in most articles is that the inputs are invented, so let us invent them out loud.

A worked example, with the assumptions stated

Assume a ten-page business site, one location, a contact form, a blog that gets a post or two a month, and no e-commerce. Assume the following, all of which are guesses that you should overwrite with real quotes:

- Your developer or agency bills at a single blended hourly rate. - Managed hosting for the WordPress build, not the cheapest shared plan. - Roughly half a dozen paid plugins on annual renewal. - Someone applies WordPress updates monthly and responds to security advisories out of band. - The WordPress theme or builder needs a significant rebuild inside the three-year window. This is the single largest swing factor in the entire model. - The custom build is statically generated, deployed to a CDN, with no runtime server. - Content edits on the custom build go through a developer, because we did not budget a headless CMS.

Fill those seven rows in and the picture that usually emerges is this: WordPress is cheaper to start and more expensive to keep, custom is more expensive to start and cheaper to keep, and the crossover point depends almost entirely on two variables. Those two variables are your maintenance labor rate and whether a rebuild lands inside your window.

That is the honest output of this model. It is not a number. It is a shape.

Where the model breaks

If nobody maintains the WordPress site, the maintenance cost is zero. Plenty of businesses simply do not do the updates. The cost does not vanish, it converts into risk, and risk does not show up in a spreadsheet until the day it does. We are not going to pretend we can price that for you.

If your team needs to edit content, custom code gets more expensive fast. Every text change that costs a developer twenty minutes is a real line item. Over three years, a marketing team that publishes weekly can spend more on developer time than the WordPress licenses ever cost.

Agency rates vary by a factor of five. Any total we published would be a fiction about your market.

The redesign assumption dominates everything. Assume no rebuild in three years and the two paths land close together. Assume a rebuild and WordPress looks expensive. That single assumption, not the platform, drives the conclusion. Be suspicious of anyone who buries it, and be suspicious of the earlier version of this post, which did exactly that.

The claim we are removing

An earlier version of this article included an "opportunity cost nobody calculates" section. It argued that if your WordPress site scores poorly on Lighthouse and a competitor's React site scores well, the competitor outranks you and takes your customers.

We are cutting that section, because we cannot support it. We have never measured a ranking change or a revenue change attributable to a platform migration, for a client or in a study. Google has said page experience signals are used in ranking, but they are one input among many and they do not outrank relevance. Presenting an unmeasured revenue loss as a cost line was the least defensible thing in the original post.

There is also a finding that runs the other way, and it belongs here rather than in a footnote. In our AI visibility study, 368 sites were analyzed and 92 lost at least one answer-critical element between the rendered page and the raw HTML. By platform, WordPress was 37 of 139, and other or custom builds were 34 of 107. Wix was 1 of 35 and Webflow was 1 of 15. Custom builds were the worst-performing group, mostly because a client-rendered React application serves an empty shell to any crawler that does not run JavaScript. If you buy custom code and the team does not pre-render, you can pay more and end up less visible. That is a cost too.

So read the number correctly. It says custom is worst in practice, not worst in potential, and those are different claims. The builders have a high floor: they server-render by default, so the median site is safe without anyone thinking about it. You also cannot climb past their ceiling. Custom has the lowest floor and the highest ceiling. An unguarded client-rendered app that ships an empty shell is the worst outcome in our data. A server-rendered or statically generated custom build is the best outcome available to anyone, because you own the rendering path instead of inheriting it.

We are not asking you to take that on faith. This site is custom Next.js. It scores 100 out of 100 on our own deep scan and 10 out of 10 on AI readiness, and you can run both yourself. No builder can be instructed to do that.

The honest decision rule: choose custom when you will actually do the work, and prove it with a scan. Choose a builder when you will not, because a high floor beats a ceiling you never climb.

What each platform is really buying you

WordPress buys you editorial independence and a large hiring pool, and charges you in ongoing maintenance and attack surface.

Custom React and Next.js buys you control, a small maintenance surface, and no plugin update treadmill, and charges you up front and every time you need to change something structural.

Neither is a moral position. They are different payment schedules for different constraints.

When WordPress is still the right call

Your team publishes often and needs a visual editor. You need WooCommerce and its inventory and shipping ecosystem. Your budget is small and you need to be live now. In those cases WordPress is not a compromise, it is the correct engineering decision, and we will tell you so.

Do this before you spend anything

Run your current site through our free SEO audit and see what is actually wrong with it. A surprising number of sites we look at do not need a rebuild. They need a caching layer, compressed images, and someone to fix the template.

Then take the line items above, put your own quotes in them, and do the arithmetic yourself. If you want us to check your math, including the scenario where you keep what you have, book a consultation. We do not need this to come out in favor of a rebuild.

The result we have to lead with

In our AI visibility study, we crawled 405 business websites, analyzed 368, and compared the fully rendered page against the raw HTML a non-rendering crawler receives. 92 of the 368 lost at least one answer-critical element, meaning body text, links, or contact details that appear on screen but never appear in the raw response.

Here are the counts by platform:

- Wix: 1 of 35 - Webflow: 1 of 15 - GoDaddy: 4 of 20 - Squarespace: 13 of 46 - WordPress: 37 of 139 - Other and custom builds: 34 of 107

Wix had exactly one affected site out of thirty-five. It was, alongside Webflow, the best-performing platform in the study. Custom builds were the worst group in practice, at 34 of 107.

We are an agency that builds custom React and Next.js sites. That result does not flatter us and we are publishing it anyway, because the alternative is writing a sales argument and calling it analysis.

Floor and ceiling

The wrong conclusion to draw is "so use Wix." That is the same overclaim as the original post, pointed the other way. Here is what the numbers actually support.

Wix has a high floor. It renders on its servers. Whatever is on the page is in the response, and that happens whether or not anyone at your company has ever heard the word crawler. It is not doing anything clever. It is doing the boring thing correctly, by default, for everyone, and the boring thing is what mattered. The ceiling arrives with the floor: you inherit the rendering path instead of choosing it, and you cannot go above what the platform does.

Custom has the lowest floor and the highest ceiling. A custom build sends whatever the developer decided it should send. A large share of them are client-rendered React applications, where the browser gets a nearly empty document and JavaScript assembles the page afterward. Crawlers that execute JavaScript see it. Crawlers that do not, including several that feed AI answer engines, see almost nothing. That is the worst outcome in our data. But a statically generated or server-rendered Next.js build puts every word in the raw HTML, and that is the best outcome available, because the rendering path was a decision rather than an inheritance. Our own site is custom Next.js and scores 100 out of 100 on DeepAudit and 10 out of 10 on AI readiness. No builder can be told to do that.

The custom bucket is a catch-all. Those 107 sites include hand-rolled static HTML and heavy single-page applications, filed under one label. It averages the best and worst architectures on the web together. That is why it looks bad, and it is why it cannot be read as a verdict on custom development.

The platform did not decide this. The rendering strategy did. Choose custom when someone is actually going to do the work, meaning server rendering or static generation, tested rather than assumed. Choose a builder when nobody will, because a high floor beats a ceiling you never climb.

Check yours before you argue with any of this. View the raw source of your homepage, not the browser inspector, the actual source, and search it for your headline and your phone number.

What Wix is genuinely good at

Speed to live. Hours, not weeks. For a new business that needs a presence now, that is worth real money, and paying an agency to spend six weeks reproducing it is a poor use of capital.

Non-developers can edit it. No ticket, no retainer, no waiting. This is the row that quietly decides most platform arguments.

Nothing to patch. No plugin updates, no PHP versions, no security advisories landing on your desk on a Friday.

Bundled infrastructure. Hosting, SSL, domain, analytics, in one bill.

It serves real HTML. As above. That is a technical compliment and it is earned.

Where Wix actually constrains you

These are real limits. We are stating them without inflating them into revenue loss.

Structured data. Wix generates some schema automatically. Adding custom JSON-LD for FAQ, HowTo, Product, or a detailed LocalBusiness graph is limited. Structured data does not earn rankings. It makes you eligible for certain result formats, and if you want that eligibility, you need control over the markup.

Markup and DOM control. You do not decide the heading hierarchy or element order. For a brochure site this is irrelevant. For a large content site with a deliberate architecture, it becomes a ceiling.

Page weight. Wix ships its platform runtime on every page, including code for features your page does not use. A hand-built static page ships less. You can measure this on your own site with a single Lighthouse run, and you should, because it is one of the few things in this article you can check in five minutes rather than take on faith.

Custom functionality. A pricing calculator, an unusual booking flow, a product configurator, a direct integration with your CRM, an AI chat wired into your own data. Velo gives you some room, inside a sandbox. A codebase gives you all of it.

Portability. You own your content, not your build. Leaving means rebuilding. Decide how much that matters before you start, not after.

The claims we removed

The original version of this post said Wix sites "consistently score 25 to 55" on Lighthouse Performance while custom sites score 90 to 100. We did not have platform-segmented performance data then and we do not have it now. Those ranges were not measured. They are gone.

It also said a slow Wix site means "you are losing the majority of your mobile visitors," and that most clients "see measurable improvements in rankings and lead volume within the first 60 days." We have not measured either of those. They are gone too.

What we have measured on performance is this: across the 292 sites in our small business study, 191 returned a valid mobile verdict and 185 of them failed at least one Lighthouse threshold. The median mobile Largest Contentful Paint was 10.5 seconds. Those are lab numbers from a purposive B2B prospect list, and the dataset does not record what platform any of those sites ran on. So it tells you the small business web is slow. It does not tell you Wix is why.

When it is actually time to leave Wix

Not because it is Wix. Leave when you hit a wall you can name.

You need functionality the platform cannot support, and cannot be made to support. You have measured a performance ceiling rather than assumed one. You need markup or schema control the platform will not give you. You are stacking paid apps to fill gaps that one build would close. You are building a product experience, not publishing a brochure.

And leave only if the replacement will be built properly. A custom site that is pre-rendered and tested is the best thing you can have. A custom site that renders in the browser is worse than the Wix site you left, and you will have paid for the privilege. If nobody is going to own that decision, staying on Wix is a legitimate engineering choice, and we will say so on a call.

What we did not measure

We have not measured conversion by platform. We have not measured rankings by platform. We have not measured revenue before and after a migration. We measured one thing, whether the content survives into raw HTML, and Wix won it as a group. We did not measure how many of the custom builds were pre-rendered, which is the variable that separates the top of that study from the bottom.

Anyone who tells you your platform choice determines your rankings is filling in a blank they did not measure either, including the version of us that wrote this post the first time.

Where to start

Run your site through our free SEO audit and read what it actually says. If it comes back healthy, you have your answer and it did not cost you anything. If it does not, book a consultation and we will tell you which problems are the platform and which are the content, because those are usually different problems with different price tags.

We are an agency. That means we have an obvious interest in how this article ends, so we are going to do something unusual with it and not end it in our favor. The honest answer is that for a large share of small business websites, a good freelancer is the correct hire, and the agency premium buys things you may not need.

Here are the actual tradeoffs.

What a freelancer gives you

Lower cost, because there is less overhead. No office, no account manager, no project manager, no bench to keep busy. You are paying for the person doing the work and very little else.

Direct communication. You talk to the person writing the code. Questions get answered by the person who knows the answer. For a well-defined project, this is faster and clearer than any process an agency can put around it.

Deep, narrow expertise. A freelancer who has spent five years in one stack often knows it better than a generalist team does. If your project sits squarely inside that stack, you are getting more skill per dollar, not less.

They can usually start sooner. Agencies schedule around a pipeline. A freelancer with a gap can start next week.

What a freelancer costs you

One person is one point of failure. Illness, a better offer, or a disappearance leaves you with a partial codebase and the job of finding someone who can read it. This is the single largest risk and it is not hypothetical.

Narrow skill range. A website is design, UX, copy, performance, technical SEO, and sometimes lead capture plumbing. Most freelancers are strong in two or three of those. The rest gets whatever attention is left. You can solve this by hiring two freelancers, which is a real option people rarely consider.

Scope changes get uncomfortable. Fixed-bid work plus expanding scope means either a renegotiation or quiet corner-cutting. Neither is fun. Hourly work with a cap handles this better than a fixed bid does.

Support later is not guaranteed. The person who built your site may be booked when you need a change in six months. Ask up front what their availability policy is, and get it in writing.

What an agency gives you

Continuity. If one person leaves, someone else picks it up. Your site does not depend on one person's health or interest level.

Multiple disciplines on the same project. Design, development, SEO, and strategy in the same conversation rather than stitched together after the fact.

Process. Defined stages, documented deliverables, a way to handle scope changes that does not depend on goodwill. Process is genuinely valuable on a complex build and genuinely wasted on a simple one.

Parallel work on complex builds. Several people can work at once. On a large project this compresses the timeline. On a five-page site it mostly adds coordination cost.

What an agency costs you

More money, for the same code. The overhead is real and you pay for it. If you do not need the team, you are subsidizing it.

Distance from the developer. At larger agencies, your feedback goes through a project manager. Detail gets lost in translation. Ask who you will actually be talking to, and ask before you sign.

Templates at custom prices. Some agencies apply the same starter to every client and bill it as bespoke. Ask to see source code from two previous builds, not screenshots.

You may not be the priority. If you are the smallest account, your deadlines are the flexible ones.

The thing neither will tell you

The platform argument and the vendor argument are the same argument in different clothes, and both come down to one question: who maintains this in eighteen months?

If the answer is nobody, buy the simplest thing that works and stop paying for control you will never exercise. That is not a pitch for us. It is frequently a pitch against us.

When a freelancer is the right call

The scope is clear and unlikely to move. The site is largely a brochure: pages, contact, a blog. You can manage a project and read a proposal. You have a plan for what happens if the freelancer becomes unavailable, such as owning the repository from day one. Your budget is tight enough that agency overhead would come out of the build itself, which is the worst possible trade.

In that situation, hiring an agency does not buy you a better website. It buys you a more expensive one.

When an agency is the right call

The website is a primary revenue channel and downtime or drift has a cost you can name. You need design, development, SEO, and strategy to agree with each other. The build involves systems that must keep working after launch, such as booking, CRM sync, or AI chat. You want a named party accountable for the thing in a year, and you are willing to pay for that.

Ask both of them these questions

The answers separate the good from the plausible faster than any portfolio does.

Can I see the source code of two sites you have built? Who owns the repository, and can I have admin access to it from day one? Who is writing the actual code, and will I speak to them? What happens if that person leaves mid-project? Is the site pre-rendered, or does it render in the browser? How do you handle scope changes? What is your policy on availability for changes after launch?

That fifth question matters more than it sounds, and it is the one almost nobody asks.

In our AI visibility study, 92 of 368 sites lost answer-critical content between the rendered page and the raw HTML. Custom builds were the worst-performing group in practice, at 34 of 107, while hosted builders like Wix came in at 1 of 35. The reason is not that custom work is bad. It is that custom work has the lowest floor and the highest ceiling. A client-rendered application ships a nearly empty document and lets JavaScript fill it in, which is the worst outcome available. A statically generated or server-rendered build puts every word in the raw HTML, which is the best outcome available, better than any builder can be told to produce. Both are sold as "custom code," and the price does not tell you which one you are getting.

Whoever you hire, freelancer or agency, make them answer that question in plain language, and ask them to show you the raw HTML of a site they have shipped. A good freelancer will do this happily. So will a good agency. Anyone who cannot is selling you the lower floor.

Start by knowing what you actually need

Before you brief anyone, get clear on what the site has to do for the business. Not how it should look. What it should do.

If you are not sure where the gaps are, run your current site through our free SEO audit. It is free, it does not ask for an email, and you can hand the report to any freelancer or agency you are considering, including ones that are not us. If you want to talk the scope through, book a consultation. If the right answer is a freelancer, we will say so.

The short version: for a lot of small businesses, doing SEO yourself is the correct call, and hiring anyone would be a waste. There is a real point where that stops being true. This post is about where that point is.

When DIY is the right answer

Do it yourself if most of these describe you.

You are a local business serving one city, and the queries you care about are your service plus your town. Local results turn on relevance, distance, and prominence. A claimed and accurate Google Business Profile, real photos, and real reviews do more for you than anything we would sell you, and none of that requires us.

Your competition is light. If the businesses ranking above you have five-page sites and no blog, the bar is low enough to clear on your own.

You have time and you find the work tolerable. Somebody has to write the pages, and the person who knows the work is you. We can edit and structure your knowledge. We cannot supply it.

Your site is on a mainstream platform that is doing the technical work for you. WordPress with a maintained theme, Squarespace, Shopify, or a modern site builder handles sitemaps, canonical tags, and basic markup without you touching anything.

Money is tight and the site is not obviously broken. Our SEO engagements start at $450 a month. If that number would hurt, keep it. A year of your own consistent content will beat a few months of a retainer you cancel.

What DIY handles fine

Title tags and descriptions. Descriptions do not decide whether you get indexed, and Google will rewrite them when it wants to, but they affect whether someone clicks. That is worth twenty minutes.

Google Business Profile. Free, and the most direct lever a local business has.

Content. Nobody in our office knows your trade better than you do. Writing the answer to a question a customer actually asked you last week is real SEO work.

Google Search Console. Free, and it is the only place that tells you what Google is actually doing with your pages. Learning to read the Performance report and URL Inspection is a couple of hours and it will save you from most of the nonsense sold to small businesses.

When DIY stops working

The honest signals, in the order they usually show up.

You cannot tell whether Google can even read the page. If your site renders content with JavaScript, the HTML your server returns may not contain the text you can see on screen. We measured this on 368 business websites: 92 of them dropped at least one answer-critical element between the rendered page and the raw HTML. This class of problem is invisible from the front end and it is the single most common thing we find that a business owner could not have found alone.

You are ranking, and you are ranking thirtieth. That is not a checklist problem. That is a competition problem, and closing it takes content depth, links, and time. Check the Performance report in Search Console before you assume anything is broken, because "not indexed" and "indexed and losing" need completely different work.

You are about to migrate, redesign, or replatform. This is where sites lose years of traffic in an afternoon, and it is worth paying somebody who has done it before.

You have multiple locations, thousands of pages, or a stack nobody in the building understands. Complexity is the thing agencies are actually for.

Your time is worth more elsewhere. If SEO is eating ten hours a week that you would otherwise spend selling, the calculation is not about SEO at all.

What we are not going to tell you

We are not going to quote you what other agencies charge. We see the same numbers you do in the same blog posts, we cannot verify any of them, and repeating them would just be adding a citation to a rumor.

We are not going to tell you that an audit score below some threshold means you need to hire someone. Our tool checks 60+ factors across 9 categories and returns a score. That score is a checklist result. It is not a diagnosis, it does not predict revenue, and we have watched a site score in the high nineties and generate nothing.

We are not going to claim professional SEO produces results DIY cannot. On the technical side, that is often true. On content, it frequently is not, because the expertise lives with you.

Our actual prices

So you can do the math rather than guess at it. SEO starts at $450 a month. A site build starts at $750 for a single-page starter, or $2,500 for a full 5-page build. Lead capture starts at $299 a month. Project work outside a retainer is $100 an hour, standard rate. Everything gets scoped on a call before anyone commits to anything.

What we will not do is promise a payback period. We do not know your margins, your close rate, or your market, and neither does anyone else quoting you a return.

A reasonable next step

Run a free audit. It is free, it does not ask for an email, and it will hand you a list of what is technically wrong.

Then split that list in two. The items you understand and can fix, fix. That is DIY, and it is the right call. The items you read and cannot parse, particularly anything about rendering, indexing, or canonicals, are the ones worth a conversation, with us or with anyone competent.

If it turns out you do not need us, that is a fine outcome and we would rather you hear it now than in month four of a retainer.

The conclusion people usually draw is that SEO does not work. The more useful conclusion is that traffic, leads, and revenue are three different measurements, and almost nobody has wired them together well enough to know which one is actually failing.

Start by checking whether the traffic is real

In July 2026 we audited the Google Analytics property for our own site. Around 90 percent of the recorded traffic was bots. Once we filtered them out, real human traffic to axiondeepdigital.com was roughly three people per day.

We had been looking at a number in the hundreds per month and treating it as an audience. Most of it was crawlers, scanners, and automated tooling.

We are an SEO shop. We build audit software. We still spent months reading a traffic number that was mostly not people. If you are staring at a healthy traffic graph and an empty inbox, the first question is not "why are these visitors not converting." It is "how many of these visitors are visitors."

Check your analytics for bot filtering. Compare sessions against server logs if you can get them. A large gap is informative on its own.

Then check whether the path is instrumented

Suppose the humans are real. The next thing most sites cannot answer is where those humans stop.

Here is ours, and it is not flattering. Eighty people completed a free SEO audit on our site. Two of them clicked the booking link.

Look at what that rules out. It is not a traffic problem, because those 80 people arrived. It is not an engagement problem, because they finished a multi step tool that takes about a minute and hands them a report. It is not a technical problem, because our own deep scan gives the site a perfect score. The failure is concentrated in one specific handoff: the moment a person who just got value from us is invited to talk to us.

We only know that because we counted each step separately. Before we did, we had a traffic number and a quiet inbox, which is exactly the state most people describe on the call.

There is a second lesson buried in that funnel. For a while our numbers appeared to show a collapse between audit started and audit completed. It was an instrumentation artifact. The two events were not comparable, and real completion was around 80 percent. We nearly spent effort optimizing a step that was working.

An analytics bug will send you to fix the wrong thing for months, cheerfully.

What ranking actually promised

When you rank for a query, you have made one narrow promise: this page is a plausible answer to that search. Google forwarded the person. Nothing about that transaction obligated the person to contact you.

So the honest question is what a visitor can even do on the page after they read it. Not "what percentage bounce," because we do not know that for your site and neither does a benchmark. Just: what is available to them, and how far away is it.

Is there a next step visible without scrolling? On many business homepages the only route to a conversation is a "Contact" link in the footer.

Does the page answer the question the person searched? If someone searched for pricing and the page says "contact us for a quote," the page did not answer. Sites that publish real ranges, real examples, and real constraints give the visitor something to act on. We cannot promise you that publishing prices increases leads. We can tell you that withholding the answer guarantees the person has to go somewhere else to get it.

How much does the form ask for? We are not going to quote you a conversion penalty per field, because the numbers in circulation are not traceable to a study anyone can read. What we will say is that every required field is another moment a person can quit, and you never see the ones who did.

Is there any path other than the form? One capture mechanism means one kind of visitor gets captured: the one who was already decided.

The one number here with a source

Harvard Business Review published "The Short Life of Online Sales Leads" in 2011, covering 2,241 US companies. Companies that made contact within an hour of an inquiry were about seven times more likely to have a qualifying conversation with a decision maker than those that waited an hour longer. Average first response across the sample was 42 hours. Twenty three percent never responded at all.

If your leads are arriving and going cold in an inbox, that is a measurable, fixable failure with actual published evidence behind it. Most of the other advice in this category does not have that.

What we cut from this post

An earlier version of this article described a landscaping company with 1,200 monthly visitors and two leads, and claimed that a page loading in 1.5 seconds converts almost twice as well as one loading in 5 seconds, and that each extra form field costs roughly 10 percent of your conversion rate.

We cannot substantiate any of those figures, so they are gone. We are not replacing them with different invented numbers. The version of this argument that survives contact with evidence is the one built on our own funnel, which is above, and on the HBR study, which is published.

SEO and conversion are one job

The heading structure that tells a crawler what a page is about is the same structure a person scans. The copy that ranks is the copy that has to persuade. The speed that keeps you in the index is the speed that keeps an impatient person on the page. Splitting them across two vendors with two goals is how sites end up ranking well and converting badly.

But the first work is not a redesign and it is not another widget. It is counting. Landing page, tool or form started, completed, contact captured, lead qualified, revenue closed. Six numbers. Most sites have one of them.

Get the six. Then you will know whether you have a traffic problem, a page problem, or a follow up problem, instead of guessing.

We wrote about the same failure from the technical side in 98 Lighthouse Score, Zero Leads, and about finding the specific drop off point in Your Website Has a Lead Leak.

Run your site through our free audit for the technical picture, or book a call and we will look at the path with you.

Structured data does not generate leads. It does not earn you the map pack. It does not make Google rank you higher. What it does is narrow and real: it states the facts about your page in a format a machine can read without inferring anything, and it can make a page eligible for a search feature that Google supports. Eligible. Not entitled.

We are rewriting this because we found ourselves recommending schema types to clients that Google had already stopped showing.

What structured data actually is

Schema.org vocabulary, expressed as JSON-LD in your page, that says in plain key-value terms: this is an Organization, its name is X, its address is Y, this page is an Article published on this date by this author, this is a Product with this price and this availability.

Without it, a search engine or a language model has to infer those facts from your prose and your HTML layout. Sometimes it infers correctly. Sometimes it decides your phone number is a fax number, or that the author of your article is the name in your cookie banner. Structured data removes the inference step. That is the entire mechanism. It is a strong and unglamorous benefit and it is enough of a reason to do the work.

What it does not do

It does not earn the map pack. Google's local ranking comes down to relevance, distance, and prominence. Your Google Business Profile drives that surface, not the JSON-LD on your website. We have said otherwise in the past and that was not correct.

It does not get you a star rating in search. Google's structured data policy excludes self-serving review content, meaning reviews about your own business that live on your own site. Marking up an AggregateRating you assigned to yourself is not a growth hack, it is a policy violation, and it is also just a lie printed in machine-readable form. We have a house rule against it and we do not run one on our own site.

FAQ markup no longer produces an FAQ rich result for you. In August 2023 Google restricted FAQ rich results to well known, authoritative government and health sites. In 2026 Google dropped the FAQ appearance entirely. HowTo rich results were deprecated in the same 2023 change. An earlier version of this post called FAQ schema "absurdly powerful" and told you to mark up your sales objections. That advice is dead. It was accurate when it was written and it is not accurate now, which is the ordinary condition of SEO advice and a good argument for dating everything you read.

It does not guarantee any feature at all. Google's own documentation says that valid structured data makes a page eligible for a rich result and that Google does not guarantee the feature will appear. Eligibility is a gate, not a promise.

What it can do, with the evidence stated plainly

Google publishes case studies on its structured data documentation. Rotten Tomatoes added structured data to 100,000 pages and reported a 25 percent higher click-through rate on pages with markup than on those without. Nestle reported an 82 percent higher click-through rate on pages that appeared as rich results.

Read those carefully. They are vendor-reported before-and-after numbers published by the platform that benefits from adoption, not controlled experiments, and they come from very large publishers with content types that Google supports rich results for. They are evidence that rich results can lift click-through when you qualify for one. They are not evidence that adding LocalBusiness schema to a five-page plumbing site will lift anything, because there is no rich result for that site to win.

That is the question to ask before you write a single line of JSON-LD: does Google currently support a visible feature for this content type? If yes, markup makes you eligible for it. If no, the markup is still worth adding for machine-readable clarity, and you should expect no visible change in the search results whatsoever. Anyone who tells you differently is selling schema.

The types that still map to a supported feature

Check Google's search gallery for the current list before you build anything, because it changes. As of this writing, the types that reliably matter for a small business are:

Organization or LocalBusiness. Name, address, phone, hours, sameAs links to your real profiles. This is your identity record. It is what makes your business a resolvable entity rather than a string of text, and it is what keeps a machine from guessing.

Product, with real offers. If you sell things, price and availability are eligible for product rich results.

Article and BreadcrumbList. Modest, but supported, and they clarify authorship and site structure.

Event, JobPosting, Recipe, Video. Supported, if you actually have that content.

Everything else you can mark up, and most of it will produce no visible feature. That is fine. Add it for accuracy, not for a payoff.

Structured data and AI answers

Some AI systems parse JSON-LD. Some do not. The honest position is that we do not have a controlled measurement showing that adding schema causes an assistant to recommend a business, and neither does anyone else who is confidently telling you it does.

What we can say from our own work is narrower and better supported. In our 368-site study, 92 of 368 sites lost at least one answer-critical element (body text, links, or name-address-phone) between the rendered DOM and the raw HTML. A crawler that does not execute JavaScript sees nothing on those pages. If your facts only exist after hydration, structured data in the initial HTML is one of the few things a non-rendering crawler can still read. That is a real, checkable reason to serve JSON-LD server-side. It is not the same claim as "schema makes ChatGPT recommend you."

How to do it without wasting a week

1. Write Organization or LocalBusiness JSON-LD for your homepage. Real name, real address, real phone, real hours, real sameAs profile links. 2. Serve it in the initial HTML, not injected by client-side JavaScript. 3. Run the page through Google's Rich Results Test and the Schema Markup Validator. The first tells you what feature you are eligible for. The second tells you whether the syntax is valid at all. They are different tools and you want both. 4. Make sure the marked-up facts match what a human reads on the page. Mismatch is a manual action risk and, again, it is just false. 5. Do not mark up reviews of yourself.

Our DeepAudit AI checks for structured data as part of its 60-plus checks across 9 categories and will tell you what is present and what is malformed. It will not tell you that schema is going to make your phone ring, because it will not.

The honest bottom line

Structured data makes your facts explicit and makes you eligible for the features Google currently supports. Both of those are worth an afternoon. Neither of them is lead generation. If your leads are not coming, the problem is almost never your JSON-LD, and we would rather tell you that than sell you the markup.

Run the free audit and see what your site actually declares about itself.

We say this as the shop that puts performance scores in its own marketing, and we have the receipts against ourselves.

Our own site is the example

Our deep scan gives axiondeepdigital.com a perfect score. We built the scanner, so treat that for exactly what it is: our tool confirming that our site conforms to the rules our tool checks. That is the honest description of what any score is.

Here is the number that is not self congratulatory. Eighty people completed a free SEO audit on our site. Two of them clicked the booking link.

Nothing in a Lighthouse report, and nothing in our own scanner, would have told us that. The page rendered fast. The markup was valid. Accessibility passed. The score has no opinion about whether a person who just received a useful report decides to start a conversation with us, because that is not what a score measures.

A score is a precondition. It is not an outcome.

What a score can and cannot see

Lighthouse measures load performance, accessibility rule compliance, best practice checks, and a set of SEO hygiene items. Those are real things and they are worth getting right.

Here is the category of thing no score of any kind will report:

Whether there is a next step visible without scrolling. A hero section can have a beautiful headline, a subheadline, and a background image, and no button. That page passes every audit we own.

Whether the headline is about the visitor or about you. "Transforming Businesses Through Strategic Advisory" is a valid H1. It is well formed, correctly nested, keyword bearing, and it tells a person nothing about what happens to them if they hire you.

Whether anyone has any reason to believe you. No testimonials, no client work, no case studies, no named references. For services where trust is the product, this is the whole purchase decision, and it is invisible to every technical checker in existence.

Whether there is more than one way to start a conversation. One contact form is one path. It captures the visitor who was already decided and nobody else.

Whether the copy was written for a person. Body text can be keyword complete, correctly structured, and completely unpersuasive. Crawlers do not notice. People do, and then they leave, quickly, on a very fast page.

What we removed from this post

An earlier version of this article described a client site and claimed the changes took it from zero leads per month to 15 to 20 leads per month within 60 days, with about 40 percent of those leads arriving through a chat widget.

We cannot show you the data behind those numbers, so we deleted them. We are not swapping in different figures. If we ever publish a lead lift number, it will come with the property, the date range, and the definition of a lead attached.

What survives is the premise, which was always the honest part: a perfect technical score and an empty pipeline can coexist, and they routinely do.

The claim we will still make about speed

Speed is worth having. It is the floor. A slow page loses people who never see your offer, and a page that loses people before it renders cannot convert them.

That is different from saying speed produces leads. It does not. It removes one reason to leave.

Our own scanner reports lab performance, and we are careful in the research about what that does and does not mean. Lab measurements are not field data. A high lab score does not guarantee good real world performance, and good real world performance does not guarantee anyone fills out your form.

What to do instead of celebrating a number

Count the path. Landing page view, tool or form started, completed, contact captured, lead qualified, revenue closed. Six counts.

Then look for the step that loses almost everyone. On our site it is the booking click, and it is not close. That is a copy and offer problem sitting at one specific transition, and no amount of additional performance work will touch it.

The other thing worth doing is checking that your counts are real. Two of our own numbers were wrong before we looked hard at them. Roughly 90 percent of our recorded traffic turned out to be bots, and a step in our audit funnel appeared to be collapsing when it was actually completing at around 80 percent. The apparent problem was an instrumentation artifact. We would have spent weeks optimizing a step that was fine.

Where this leaves us

We have a perfect score on our own audit, a genuinely working audit tool, an honest technical foundation, and a booking step that converts almost nobody.

We are fixing the booking step. We do not yet know whether it will work. When we have run it long enough to say something true, we will publish the number, including if it does not move.

That is the state of it. A score is not an outcome, and we are living proof.

For the same argument from the traffic side, see Organic Traffic but No Leads. To find the specific step where your own site loses people, see Your Website Has a Lead Leak.

Run your site through our free audit to see the technical picture, and then go count your funnel, because the audit will not do that part for you.

1. Our entire site was invisible to crawlers

Next.js has a file called loading.tsx. Drop it into the app directory and it shows a loading state while the page hydrates. It also wraps all page content in a Suspense boundary in the static HTML export.

The consequence was that the HTML we shipped contained a spinner and not much else. Homepage, service pages, blog posts, all of them. We spent days on heading hierarchy, anchor text, and meta descriptions while the crawlable HTML was empty.

The fix was deleting one file. The lesson is that we should never have been reading our source code to answer a question about our output. We now build the site, open the generated HTML, count the words, and check for the spinner before anything ships.

2. Analytics reported a healthy tag and collected nothing

Google's tag assistant told us the tag was installed. Two weeks later we had zero events. Not low traffic. Zero.

The cause was Google Consent Mode v2. Our cookie banner defaulted analytics_storage to denied and only granted it when someone clicked Accept. Most people click nothing.

The tag test checks whether the script is present. It does not check whether consent mode is suppressing collection. We fixed the default, and we now open the Realtime report after every deploy instead of trusting a green checkmark. We are not lawyers and consent obligations depend on where your users are, so get that part right on its own terms. The measurement lesson stands regardless: a tag that loads is not a tag that reports.

3. Five H1 tags, and we were wrong about why that mattered

Our homepage had an H1 in a server-rendered article, another in a client component, and more inside service cards. Our own audit tool flagged it as an error, and this post originally said Google would not know which heading mattered.

That claim was wrong and we have since corrected the tool. Multiple H1 tags are not an SEO failure. Google has said as much. Our rule was too strict, it was inflating the error count on our own reports, and it is now a warning.

There was a real problem underneath, and it was duller than the one we invented: our headings did not describe the page. The document structure was an accident of how the components were assembled rather than a description of the content. Fixing that is worth doing because it makes the page comprehensible to a person using a screen reader, and because it forced us to decide what each page was actually about.

4. Every link on the site said "Learn more"

Twelve service cards, twelve identical anchors, twelve different destinations. Anchor text is one of the ways a link describes its target, so we replaced them with anchors that name the destination. It took twenty minutes.

We cannot show you that it moved a ranking. We can tell you the site is easier to use, and that we no longer have twelve links claiming to be about nothing in particular.

5. Client components erased our server-rendered content

A single usePathname() call turns a component into a client component. Ours were client components for no better reason than highlighting the active nav item, and that pulled our content shell and footer out of the static HTML.

We moved the pathname logic into a small client child and left the parents on the server. The HTML then contained content instead of empty divs waiting for hydration.

This is the same failure as number one, wearing a different hat, and it is the one we now check for first on any React site. It is also the failure we later went and measured across other people's sites: of 368 business websites we analyzed, 92 lost at least one answer-critical element between the rendered page and the raw HTML. We did not find that pattern because we are clever. We found it because we shipped it.

6. Our privacy page listed the wrong analytics ID

We changed Google Analytics properties and updated the tag, but the measurement ID was also hardcoded in the text of our privacy policy. Anyone checking what we track would have found a different ID than the one running.

Not an SEO issue. It is a document claiming something untrue about our own site, on the page whose entire job is being accurate.

7. Our sitemap dates were fiction

Our sitemap generated lastmod values with new Date() at build time, on a CI server with a clock that was slightly off, which meant the dates described a build, not a change to the content. Google treats lastmod as a hint and ignores it when it looks unreliable, which ours did. We hardcoded real dates. We do not claim this changed anything. We would rather our sitemap not assert things that are false.

8. Seventy-eight images with no metadata

Compressed, WebP, correctly sized, and carrying no IPTC or XMP fields at all. We wrote exiftool scripts and tagged all seventy-eight with titles, descriptions, keywords, author, and copyright. It took an hour.

Honest accounting: image metadata has documented uses in image licensing and it establishes provenance if someone reuses your work. We added it for those reasons. We cannot show that it changed a ranking, and we are not going to imply that it did.

9. The old brand name was still in five places

We built from a template and rebranded. Five instances of the old name survived, along with two old email addresses and a hero section still carrying template copy, all of it hiding in secondary pages, JSON-LD, and error states. Find and replace across the whole codebase, then do it again.

The part that took longest to accept

We fixed all of it. One of the three sites now scores 98 on Lighthouse. It generated no leads.

A technically clean site does not rank on being clean. Nothing on the list above creates demand for what you sell, provides evidence that you can do the work, or gets your name in front of anyone. Our three sites had none of those three things. They were correct and unwanted, and correctness is not a substitute.

What the list above does is remove the reasons a page cannot compete. Crawlability, content that exists in the HTML, accurate data, comprehensible structure. Get them wrong and nothing else you do can work. Get them right and you have earned the ability to start, which is not the same as having started.

Where we are now: the technical failures are fixed and documented, and the slower work of having something worth finding is still in front of us. We built DeepAudit to catch the mistakes in this post, because we made every one of them. It will find them on your site in about sixty seconds, free, without an email address. It will not tell you whether anyone wants what you sell. We had to learn that part the other way.

There are 168 hours in a week. A team working Monday to Friday, nine to five, covers 40 of them. That leaves 128 hours with nobody watching the site. 128 divided by 168 is 76.2 percent.

That is the whole derivation. It is a division problem. We did not measure it, we did not sample anything, and the tidy 77 percent we have been printing is our own rounding, in our favor, by about a point.

So: the 77% problem is a framing device. It is a way of pointing out that a website runs continuously while a staff does not. It is not a research finding, it does not come from a study, and it says nothing whatsoever about your business. Treat it as a sentence that makes an obvious thing visible, and nothing more.

What we do not know

We do not know what share of your traffic arrives outside business hours. We have never measured that across a representative sample of sites, and we are not going to tell you that "most" business traffic is after hours, because we cannot support it.

We also cannot tell you what an unanswered evening visitor costs you. Any dollar figure in this category is invented. We have seen the ones other people publish and we cannot trace a single one of them to a defensible method.

You can find the real answer for your own site in about ten minutes. Open your analytics, pull the hour of day distribution for the last 90 days, and look. That number is yours, it is real, and it beats any benchmark we could hand you.

What we deleted from this post

An earlier version of this article contained a worked example. A site with 1,000 monthly visitors, 8 percent engagement during staffed hours, 40 percent of engaged visitors sharing contact details, arriving at about 7 leads per month, then the same site with an AI chat agent producing about 42 leads per month. Six times more leads, same traffic.

Every input in that calculation was made up. There was no source for the engagement rates, no source for the share rates, and no experiment behind the conclusion. We deleted the whole section and we are not replacing it with a better looking set of invented numbers.

The same version attributed a "21 times more likely to qualify a lead if you respond within five minutes" figure to Harvard Business Review. That figure is not from the HBR article. We attached the wrong name to it and we have removed it.

The one after-hours claim we can support

Harvard Business Review published "The Short Life of Online Sales Leads" in 2011, based on 2,241 US companies.

The findings we will quote from it:

- Companies that made contact within an hour of an inquiry were about seven times more likely to have a qualifying conversation with a decision maker than companies that waited an hour longer. - The average first response time across the sample was 42 hours. - Twenty three percent of the companies never responded at all.

That study is from 2011, it is US only, and it is not specific to your industry. Those are real limitations and we are stating them. It is still a published study with a stated sample, which puts it ahead of essentially everything else written about response time on the internet, including the version of this post you may have read before.

Notice what the study is actually about. It is not about chatbots and it is not about after hours coverage. It is about elapsed time between an inquiry and a human conversation. A form submitted at 7pm on a Friday and opened at 9am on a Monday has burned 62 hours before anyone said a word. That is the mechanism, and it is worth taking seriously on its own terms without dressing it up.

What to actually do

Measure your own hours. Pull the traffic by hour of day. If a meaningful share arrives outside your coverage window, you now know that as a fact about your site rather than as a slogan about the web.

Time your own response. Submit a test inquiry through your own form at 8pm on a Friday. Note when a human replies. Most businesses have never done this and are wrong about the answer.

Then decide. Options ranked by cost, not by how much we would like to sell you:

1. An automatic acknowledgement that sets an expectation and confirms the message arrived. Cheap, does not pretend to be a person. 2. Routing that puts inquiries where someone will actually see them, rather than into an unwatched inbox. 3. A chat agent that can answer common questions and capture contact details when nobody is at a desk. We use one. It changes response time, which is the lever the HBR study is about. It is not a guarantee of more leads and we will not pretend otherwise. 4. Staffed coverage, if the volume justifies it.

The honest summary

Your website is available more hours than your staff. That is arithmetic and you already knew it.

Whether that gap costs you anything depends on when your visitors arrive and how long you take to reply, and both of those are measurements you can take today about your own business. The published evidence says slow replies cost qualifying conversations. It does not say a chat widget will multiply your leads, and neither will we.

Go pull the hourly distribution. Then come back and we can talk about what, if anything, it is worth doing about it.

Book a call if you want help reading it, or run a free audit if you want the technical picture of the site first.

The instinct is to buy more traffic. The better move is to find out where the people you already have are stopping, which requires counting each step of the path separately. Most sites do not, which is why the leak is usually described as a mystery rather than as a location.

We ran this on ourselves in July 2026. Here is what we found, and then here is how to run it on yours.

Our leak, stated plainly

Two things came out of auditing our own analytics.

Roughly 90 percent of our recorded traffic was bots. After filtering, real human traffic to axiondeepdigital.com was about three people per day, not the several hundred per month the dashboard was reporting. The audience we thought we had was mostly crawlers.

Eighty people completed a free SEO audit on our site. Two clicked the booking link.

That second number is the leak, and it is precise. Those 80 people arrived, engaged, spent about a minute in a multi step tool, and received a real report about their own website. Then almost none of them took the next step. The failure is not traffic and it is not engagement. It is one specific handoff, from "we just gave you something useful" to "would you like to talk to us."

There is a third finding worth stating because it nearly sent us in the wrong direction. For a while our funnel looked like it was collapsing between audit started and audit completed. It was not. The two events were being fired under conditions that made them incomparable, and real completion was around 80 percent, which is healthy. We were about to optimize a step that was already working.

Before you trust a funnel, verify that the funnel is measuring what you think it is.

Leak 1: A single point of capture

The only route from visitor to lead is a "Contact Us" form in the navigation.

Someone reads your blog post, finds it useful, and wants to know more. The available move is to leave the page they are on, find the contact page, and fill in name, email, phone, company, message, and how they heard about you. That is several clicks and several fields away from where their interest actually existed.

We are not going to quote you a percentage lost. We do not know it. We will point out that a single form captures a single kind of visitor: the one who had already decided.

How to find it. Count the pages on your site that offer any way to start a conversation. If the answer is one or two, this applies to you.

How to fix it. Give the visitor something to do on the page they are already on. A lightweight form, a contextual call to action, or a chat option. The mechanism matters less than the distance.

Leak 2: The response time gap

The form works. The submission arrives. Nobody replies for two days.

This one hides from analytics, because the capture event fired correctly. The lead was captured. It just went cold in an inbox afterwards.

This is also the only leak in this list with published evidence behind it. Harvard Business Review's "The Short Life of Online Sales Leads" (2011, 2,241 US companies) found that companies contacting an inquiry within an hour were about seven times more likely to have a qualifying conversation with a decision maker than those that waited an hour longer. The average first response across the sample was 42 hours, and 23 percent of companies never responded at all.

How to find it. Submit a test inquiry through your own form on a Friday evening. Time it. Do not estimate it.

How to fix it. Reduce elapsed time to first human contact. An automatic acknowledgement is the floor. Routing to somewhere a person actually looks is better. A chat agent that can answer and capture out of hours is a real option, and we use one. None of that is a promise of more leads. It is a change to the one variable the evidence is about.

Leak 3: The CRM gap

Leads arrive and never make it into the system of record.

The form emails a notification. A rep sees it, intends to enter it after the current call, and does not. Or enters it with a typo. Or the integration that was supposed to handle it broke weeks ago and failed silently, which is what integrations do.

How to find it. Compare last month's form submission count in your form tool against new contact records in your CRM for the same period. Then open your integration logs and look for failures. This takes twenty minutes and the result is usually unpleasant.

How to fix it. Direct sync, with no human transcription step. This is not a growth tactic, it is bookkeeping. If it is broken, you cannot count step four of your funnel, which means you cannot find any of the other leaks either.

Leak 4: The traffic is not where the capture is

Your highest traffic pages have no way to convert on them.

A blog post ranks, brings in visitors month after month, and offers them nothing except a link to another blog post.

How to find it. Open analytics, list your top ten pages by traffic, and check each one for a form, a chat option, or a specific call to action. Count how many have none.

How to fix it. Put a relevant next step on the pages people actually land on. Relevant is the operative word. A post about CRM automation should not offer a generic "contact us" banner.

Leak 5: The form nobody reaches or finishes

The form exists. It is three screens down, past the testimonials and the feature grid. Or it is at the top and asks for twelve fields including budget range.

How to find it. Open your own site on a phone and time how long it takes to reach the form from the landing page. Then look at your form analytics: how many people start it, and how many finish. A large gap between those two is the form telling you something.

How to fix it. Move it up. Cut fields to what you actually need to start a conversation, which is usually a name and an email. Ask for the rest once a human is involved.

Run the audit on yourself

Thirty minutes, five checks, no tooling required:

1. Coverage. How many pages offer any way to start a conversation? 2. Response time. Test submission on a Friday evening. Measure the real reply time. 3. CRM match. Submissions last month versus new CRM records last month. Account for every one. 4. Traffic versus capture. Top ten pages by traffic. How many have a next step? 5. Form friction. Count the required fields. Then count how many you would actually use on the first call.

And before any of it: check whether your traffic is human. Ours mostly was not, and we build SEO software for a living.

What honest advice looks like here

Traffic, leads, and revenue are three different measurements. Most sites cannot connect them, which is why the diagnosis defaults to "we need more traffic" and the treatment defaults to buying some.

The useful work is to instrument the path, one countable event at a time: landing page, form or tool started, completed, contact captured, lead qualified, revenue closed. Once those six numbers exist, the leak stops being a theory and becomes a location.

Ours is at the booking step. We are working on it. We will report whether it moved, including if it does not.

Run a free audit for the technical side of your site, or book a call and we will go through the six numbers with you.

The first job is not to fix anything. The first job is to find out which of three very different problems you have. Google may not have the page in its index at all. Google may have it and be unable to read the part that matters. Or Google may have it, read it fine, and decide something else answers the query better. Those three failures look identical from where you are standing, and the fixes have almost nothing in common.

Work through this in order. Do not skip to step four because it sounds more interesting than step one.

A correction first

An earlier version of this post gave three reasons that were wrong, and we would rather say so than quietly edit them out.

We said a missing meta description means Google buries you. It does not. Google generates snippets from page content when it wants to, and frequently overrides the description you wrote anyway. Write good descriptions because they affect click-through, not because their absence removes you from search.

We said multiple H1 tags are an SEO failure. They are not. Our own audit tool used to flag this as an error and we have since downgraded it to a warning, because we could not defend the rule.

We said content under 300 words cannot rank. There is no minimum word count. Word count is a prompt to go read the page, not a verdict on it.

None of those three things will get you indexed, and none of them explain a site that is missing from search.

1. Is the page in the index at all

Everything else is guesswork until you know this.

Open Google Search Console, verify your domain if you have not, and use the URL Inspection tool on the exact page you care about. It will tell you one of two things: the URL is on Google, or it is not. If it is not on Google, Search Console will usually tell you why, and that reason is the only thing you should be working on.

A site: search is a rough proxy people use because it takes five seconds, but it is not authoritative and it will mislead you. Use URL Inspection.

If Google has never crawled the site, submit a sitemap in Search Console and request indexing for your key pages. Indexing is not guaranteed and it is not instant. Google decides what is worth storing.

2. Is something telling Google to stay out

This is more common than it should be, and it is almost always an accident left over from a staging environment.

Check your robots.txt file at yourdomain.com/robots.txt. A line reading "Disallow: /" under "User-agent: *" tells crawlers to skip the entire site. Check the page source for a robots meta tag set to noindex. Check whether the page has a canonical tag pointing at some other URL, which tells Google to index that URL instead of this one. Check that the page is not behind a login or an HTTP password.

Search Console's URL Inspection reports all of these directly, which is why step one comes first.

3. Is the content actually in the HTML Google receives

This is the one people miss, and it is the reason we care about it enough to have measured it.

If your important content is rendered by JavaScript in the browser, the raw HTML your server returns may be close to empty. Google does render JavaScript, but rendering is a separate, queued, resource-limited stage. Other systems that read the web, including several AI crawlers, may not render at all.

We looked at this across 368 analyzable business websites. In 92 of the 368, at least one answer-critical element present in the rendered page was absent from the raw HTML. Missing body text in 57, missing links in 51, missing name, address, or phone details in 54. That sample was not random, so treat it as a real pattern worth checking on your site rather than a probability that applies to you personally.

To check yours: view the page source, which shows the HTML as delivered, not the DOM inspector, which shows the page after JavaScript has run. Search that source for a sentence you can see on the screen. If the sentence is not there, your content depends on rendering, and you are relying on the most fragile part of the pipeline. Search Console's URL Inspection also has a "View crawled page" panel that shows what Googlebot actually got.

4. Does the page answer the query you want it to rank for

Google ranks pages against a specific query. A homepage that lists a logo, a tagline, and a phone number is not competing for anything, because it does not say what you do, who you do it for, or where.

The check is not a word count. Read the page and ask whether someone typing the query would consider it a complete answer. If your target query is a service in a city, does the page name the service and the city, describe the work, and say what happens next. If you cannot find the query anywhere in the meaning of the page, the page is not a candidate for it.

5. Are you actually ranking, just not where you can see it

Open the Performance report in Search Console and filter to the query. If you have impressions and an average position of 30, you are not invisible. You are indexed, eligible, and losing. That is a competition problem, not a technical one, and it is a completely different project from steps one through three.

This distinction matters because the fix for "not indexed" takes hours and the fix for "ranked 30th" takes months.

6. Do you have any signals of prominence

Google needs some reason to prefer your page over the ones already ranking. Links from other sites are one signal Google has consistently described as important. For local queries, Google says results are based on relevance, distance, and prominence, so a claimed and accurate Google Business Profile is table stakes.

We are not going to tell you how many links you need, because nobody credible can. We will say that a new site with no links, no reviews, and no mentions anywhere else on the web has given Google nothing to work with.

7. Is the query simply out of reach right now

A five-page site launched last month is not going to take a head term away from competitors with a decade of content and links. That is not a technical failure. It is arithmetic.

The workable move is to compete for queries that match what you can credibly claim. A specific service, in a specific place, with a page that genuinely covers it. Lower volume, less competition, and the people searching are closer to a decision.

What one fix will not do

No single item on this list produces rankings. Getting indexed makes you eligible. Getting the content into the HTML makes you readable. Answering the query makes you relevant. Prominence makes you preferable. You need all of them, and the first three are the only ones you can finish this week.

If you want a starting inventory of what is broken, run a free audit. It loads your page in Chromium, inspects the rendered DOM, and checks 60+ factors across 9 categories. It will not tell you whether you will rank. It will tell you what is standing in the way, and it will not charge you or ask for an email to do it.

Here is what we can tell you honestly: our prices, the arithmetic that sits under any SEO price, and the things we refuse to promise about what you get back.

Our prices

- SEO: from $450 a month - Website build: from $750 - Lead capture: from $299 a month - SEO and lead capture bundled: from $529 a month - Project work outside a retainer: $100 an hour, standard rate

Every engagement gets scoped on a call before either side commits. These are starting numbers, not a quote, and the reason they are starting numbers is that the work varies enormously depending on what state your site is in.

The arithmetic under every SEO price

SEO is people doing work. There is no version of it where the cost is not hours times a rate, whatever the invoice is dressed up as.

For reference, from our own delivery: a technical audit done properly and written up so a client can act on it is four to six hours. A substantial piece of content, counting research, writing, editing, and on-page work, is eight to twelve hours. A single link placement can be a dozen emails across two weeks and still come to nothing.

Now apply that to a $99 a month offer. At our standard rate, $99 buys one hour. You are not getting an audit, a piece of content, and link building for one hour of anyone's time. Something else is being sold to you, and it is usually one of three things: automated backlinks from sites nobody reads, a white-label dashboard with your logo on it and no human behind it, or bulk generated content nobody wanted.

We are not going to give you a percentage of cheap SEO providers who are scams, because we have not audited a sample and neither has anyone quoting you a figure. We will say the hours do not add up, and ask anyone selling at that price to explain who does the work and for how long.

What our $450 a month buys

Concretely, so you can compare it against your own math.

- A technical audit each quarter, prioritized, with the fixes named - Two pieces of content a month, written against queries with commercial intent rather than traffic for its own sake - On-page work across your existing pages: titles, descriptions, headings, structured data, internal links - A monthly Search Console review reporting impressions, clicks, and position movement, including when they do not move - Google Business Profile management if you are a local business

What it does not buy: an aggressive link program, a high-volume content operation, or paid media. At this level, we are removing the technical reasons your pages cannot compete, and then giving them something to compete with. That is the whole scope, and it takes months, not weeks.

What more money actually buys

Not a different mechanism. More hours, more often, and specialists instead of generalists doing every part of it. More content per month, faster turnaround on technical work, a real link outreach program instead of an opportunistic one.

The reason we are not printing an industry price table is that we would be inventing it. We do not know what a mid-market agency in your city charges, what their team looks like, or how many accounts their lead strategist is carrying. Neither does the blog post that told you $2,500 to $5,000.

What you can do is ask any agency the two questions that make the price legible. How many hours a month go into my account, and who specifically does them. If nobody will answer that, the number on the proposal does not mean anything.

What we will not tell you

We will not tell you your payback period. Doing that requires knowing your average deal size, your close rate on inbound leads, and how much of your future traffic converts, and we do not know any of those before we work with you. Anyone who quotes you a return on SEO before they have seen your numbers is quoting you a number they made up.

We will not tell you SEO always pays for itself. It does not. It fails when there is no search demand for what you sell, when the queries are owned by competitors you cannot displace on this budget, and when the site converts nothing that lands on it. We have watched a site score 98 on Lighthouse and produce zero leads. Technical quality was never the constraint there.

We will not tell you that any one channel is the biggest ranking signal, or that a single link moves you a specific number of positions. Google describes links as important. Nobody outside Google can quantify it, and the numbers you see quoted are estimates from third-party tools, not measurements of Google.

How to decide what to spend

Start from what you can sustain for twelve months, not what you can afford for three. SEO compounds or it does nothing, and a retainer cancelled in month four is money burned. If $450 a month is a stretch, do it yourself for a year and spend nothing. We wrote an honest comparison of DIY and hiring someone, including the cases where hiring us is the wrong call.

Before you spend anything, find out what state your site is in. Run a free audit. It loads your site in Chromium, inspects the rendered DOM, and checks 60+ factors across 9 categories. No signup, no email. If the report is mostly green, your problem is probably competition or demand, and no amount of technical work will fix either. That is worth knowing before you write a check to anybody, including us.

If you want the numbers applied to your actual situation, book a call. We will tell you what we would do, what it costs, and whether we think it will work.

We opened Lighthouse on a client site last year and the mobile run came back with an LCP of 7.3 seconds and a performance score of 61. That is a real trace of one page, on one throttled run, in one lab. It is not a measurement of what that client's actual visitors experienced, and we want to be precise about that distinction up front, because most LCP advice on the internet is a fix presented without a diagnosis.

For scale: in our 292-site study, 191 sites returned a valid mobile verdict and the median mobile LCP was 10.5 seconds. 165 of those 191 were over 4 seconds. A 7.3 second LCP is not an outlier. It is the middle of the pack.

What LCP actually measures

LCP is the time from navigation start to the moment the largest visible element in the viewport finishes rendering. Usually that is a hero image, an H1, or a block of body text. Google's published thresholds are under 2.5 seconds (good), 2.5 to 4.0 seconds (needs improvement), and over 4.0 seconds (poor).

Two corrections to what this blog has said before. First, Google's thresholds are defined against field data at the 75th percentile of real page loads. Lighthouse gives you a lab number from a single simulated load. They are related, not interchangeable. Second, an earlier version of this post said that anything over 4 seconds is "actively hurting your rankings." That was an overstatement. Google has confirmed that page experience signals including Core Web Vitals are used in ranking, and Google has repeatedly said they are a small input that does not override relevance. Fix LCP because a seven second blank screen loses people, not because you have been promised a rankings jump.

The only diagnostic that matters: split the number

Google breaks LCP into four sub-parts. Every real fix belongs to exactly one of them. If you cannot say which part of the number your change is supposed to move, do not ship the change.

1. Time to first byte. How long the server takes to start responding. This is hosting, redirects, cold starts, and server-side rendering work. 2. Resource load delay. The gap between the first byte arriving and the browser starting to fetch the LCP resource. This is a discovery problem. The browser could not find out about the image until it parsed something else first. 3. Resource load duration. How long the LCP resource takes to download once the fetch begins. This is bytes, format, and connection. 4. Element render delay. The gap between the resource finishing and the element actually painting. This is blocked rendering, hydration, and animation.

Chrome DevTools gives you this breakdown directly. Open the Performance panel, enable mobile CPU and network throttling, record a load, and click the LCP marker in the Timings track. It names the LCP element and shows the phase breakdown. The Chrome web-vitals library reports the same four attribution fields in the field.

Google itself warns against assuming the answer is image compression. On plenty of pages the LCP element is text, or the image is already small and the delay is entirely server time and render blocking. Compressing a hero image that was never the bottleneck buys you nothing and costs you a day.

What each part looked like on the 7.3 second page

Here is the honest version of the trace. We did not ship these four changes one at a time with a clean measurement between each, so we cannot attribute a specific number of seconds to any single fix. Anyone who hands you a per-fix breakdown from a single Lighthouse pass is reporting run-to-run variance as science. What we can say is which phase each problem lived in.

Resource load delay: the hero image was lazy loaded. In Next.js, images are lazy by default. The hero was waiting in the queue behind everything else on the page, which meant the browser did not even start fetching the LCP element until late. The fix is to tell the browser this image is the important one.

In Next.js 16, the priority prop is deprecated. It was replaced by clearer controls, because "priority" was doing three different things at once. Current guidance:

loading="eager" start loading immediately, do not lazy load fetchPriority="high" hint that this resource outranks others in the queue preload inject a preload link so the fetch starts from the document head

Use loading eager and fetchPriority high for a hero that is already in the initial HTML. Reach for preload only when the browser genuinely cannot discover the resource early, for example when the image URL is computed by client JavaScript. If you are on an older Next.js, the priority prop still works and does roughly the same thing.

Preloading is not free. A preload is an instruction to jump the queue, and the queue is finite. Preload the wrong resource and you have taken bandwidth away from the right one. We have watched a site preload three fonts, a video poster, and a background texture, and then wonder why the hero image got slower. One preload for the LCP element. That is usually the whole budget.

Also set sizes. Without it, the browser has to assume the image will display at full viewport width and it will pull a larger candidate from the srcset than a 375px phone needs. That is a resource load duration problem, not a discovery problem, and it is a different fix even though it lives on the same tag.

Element render delay: fonts were blocking text paint. The site loaded a Google Font through a plain link tag. The default font-display behavior blocks text rendering for up to about three seconds while the font loads. If your LCP element contains text, it cannot paint during that block.

The fix is font-display swap, which renders text immediately in a fallback and swaps when the custom font arrives. In Next.js the next/font module does this by default and self hosts the file. In plain CSS, add font-display swap to the font-face rule and preload the woff2. Accept the tradeoff honestly: swap trades a blank screen for a visible font change. That change is a layout shift risk, so pair it with a fallback whose metrics are close to the real font.

Element render delay again: the animation was the LCP. This was the one that surprised us. The hero used a JavaScript animation library to fade in on mount. The server sent the image in the HTML, React hydrated, the animation set the hero opacity to zero, and then faded it back to one. The browser does not count an element as painted until it is actually visible. LCP was measuring the end of a fade, not the arrival of an image.

Do not animate the LCP element on initial load. Animate below the fold, or trigger on scroll into view, or let the element paint and animate something else. This is worth checking on any site built with a motion library, because nothing in Lighthouse tells you that your own animation is the metric you are failing.

Time to first byte and render blocking scripts. Three third-party tags were loading synchronously in the head. Synchronous scripts in the head block parsing, which delays everything downstream including the discovery of your hero image. Defer them, load them after interactive, or move them out of the head. In Next.js the Script component takes a strategy of afterInteractive or lazyOnload. In plain HTML, add defer.

The result, stated for what it is

After the change set, the same Lighthouse mobile run reported LCP 1.8 seconds and performance 97, up from 7.3 seconds and 61. That is a lab result on one page. We did not run a controlled experiment, we did not measure the revenue effect, and we have no field data from before the change to compare against. What we can say is that the page went from a seven second blank screen to a fast one on a throttled mobile profile, and that the visual design did not change at all.

What we did not measure

We did not measure conversions, bounce rate, or rankings before and after. We did not collect field Core Web Vitals from real users. We did not isolate the contribution of each individual fix. If you see a post claiming that a specific font change delivered exactly 1.4 seconds, ask how many runs they averaged.

Do this in order

1. Find the LCP element. Do not skip this. It is frequently not the image you assumed. 2. Get the four phase numbers from DevTools or from field attribution data. 3. Fix the largest phase first, and only the largest phase. 4. Re-measure with the same throttling profile, several runs, and compare medians.

Our DeepAudit AI tool loads your page in Chromium on a mobile profile and reports LCP along with the rest of the rendered DOM inspection. It will tell you the number. It will not tell you which of the four phases owns it, so run the DevTools trace yourself before you start changing code.

If mobile performance is a real problem for your business, book a call and we will walk the trace with you.

This is the checklist we run on client sites. It is ordered by how often it changes the number, not by how clever it is. We have removed several claims that earlier versions of this post made without evidence, and we flag those as we go.

1. Serve a modern format, and know which one you are actually serving

WebP and AVIF are both broadly supported. AVIF usually produces smaller files than WebP at a similar perceptual quality, and it is slower to encode.

An earlier version of this post printed a size table (PNG 1.4 MB, JPEG 380 KB, WebP 190 KB, AVIF 110 KB) and called them all "the same visual quality." We are removing that. Those numbers came from one image, and "same visual quality" was an assertion, not a test. Compression quality is content dependent. A photograph with soft gradients and a screenshot with hard text edges fall apart at completely different quality settings. Do not trust a quality number you read on a blog, including this one. Encode your actual hero at two or three settings, look at them side by side at the size they will be displayed, and pick.

If you are on Next.js, know your default. The image component optimizes to WebP out of the box. AVIF is not on by default. You have to enable it in next.config by adding image/avif to the formats array, and you should measure build and request time after you do, because AVIF encoding is expensive.

On plain HTML, use the picture element with source elements for avif and webp and a jpeg or png fallback in the img tag. Browsers take the first format they support.

2. Set the sizes attribute

This is the single most common cause of oversized image downloads on phones. Without sizes, the browser has to guess how wide the image will display, and it guesses generously. A phone rendering the image at 375 CSS pixels can end up downloading the 1920 wide candidate from your srcset.

The sizes attribute is a promise you make to the browser about layout width at each breakpoint. Something like: 100vw up to 768px, 50vw up to 1200px, otherwise 1200px. The browser then picks the smallest srcset candidate that still covers the device pixel ratio. If your sizes value lies about the layout, the browser will pick the wrong file, so check it against the real CSS.

3. Set width and height on every image

Layout shift from images is caused by the browser not knowing the aspect ratio before the file arrives. Setting the width and height attributes (the HTML attributes, not CSS) lets the browser reserve the space immediately. The Next.js image component requires them. On plain HTML you have to audit every img tag.

This is the cheapest fix on the list and it is almost always worth doing.

4. Lazy load below the fold, load the hero eagerly

Native lazy loading needs no JavaScript. Add loading lazy to images below the fold. Leave the LCP image out of it.

For the hero, do the opposite: loading eager plus fetchPriority high. In Next.js 16 the priority prop is deprecated. It has been replaced by explicit controls, because the old prop bundled several behaviors together. Use loading eager and fetchPriority high for a hero that already exists in the server-rendered HTML. Use the preload option only when the browser cannot discover the resource early on its own, for example when the URL is computed in client JavaScript.

A warning that most image posts leave out: preloading is not free. A preload tells the browser to jump the queue, and the queue has a fixed width. Preload three fonts, a video poster, and a background texture and you have taken bandwidth away from the image that is actually your LCP element. Budget roughly one preload, for the LCP resource, and verify in a network waterfall that it arrived earlier and nothing else arrived later.

5. Generate a real srcset

Ship several widths of the same image and let the browser choose. A set of 640, 1024, and 1920 covers most of the range without sending a 4K file to a phone. Next.js generates these for you. On other stacks, Sharp, cwebp, or a hosted pipeline will do batch resizing. Build it into the pipeline so no one has to remember.

6. Write alt text for the person who cannot see the image

Alt text exists so that screen reader users know what the image conveys. Google also uses it as context for image search. Both of those are true and only the first one is the reason.

Good alt text describes what the image shows in the context of the page: "Chef plating a margherita pizza at Giuseppe's in Las Cruces." Bad alt text is a filename, an empty string on an informative image, or a keyword list. If the image is purely decorative, use an empty alt attribute so screen readers skip it. An empty alt on a decorative image is correct. A missing alt attribute is not the same thing and is not correct.

7. Compress before it reaches your pipeline

A CDN image service will happily resize a 10 MB source file, and the first visitor who triggers that transform pays for it. Compress at the source. Squoosh for one-offs, Sharp for automation, ImageOptim for a folder.

Treat file size targets as a smell test, not a rule. If a hero is over 500 KB after compression, something is wrong, usually a PNG that should have been a photo format or an image exported at 3x the size it displays.

8. Use a CDN for delivery

Images served from your origin hit your server on every cache miss. A CDN caches at the edge and serves from a location near the user. Cloudflare Images, Cloudinary, Imgix, and Vercel image optimization all do this. If you are on AWS Amplify, CloudFront is already underneath, and Next.js image optimization works without extra setup, though remote sources need to be listed in the remotePatterns config.

We are not going to tell you a CDN will make your site "twice as fast." It reduces latency and origin load. Measure it.

9. Use SVG for logos, icons, and diagrams

Vector, scales cleanly, usually tiny. Inline the critical ones to save a request. Do not use SVG for photographs or complex gradients, because the file size grows past what a raster format would have cost.

10. Audit what you actually ship

Chrome DevTools, Network tab, filter by Img, sort by size. Anything over 500 KB deserves an explanation. Our free SEO audit loads your page in Chromium and inspects the rendered DOM, including image formats, dimensions, and alt coverage.

What we are not claiming

An earlier version of this post ended with a list of promised outcomes: 60 to 80 percent smaller page weight, 2 to 4 seconds faster LCP, 5 to 15 Lighthouse points, better image search rankings. We made those numbers up. They were plausible, they were not measured, and we should not have printed them.

What we can say honestly is this. Images are often the largest byte category on a page. Oversized images can be a component of a slow LCP, and they are frequently not the whole story, because LCP is a composite of server time, discovery delay, download time, and render delay. Fixing images fixes the download component. If your LCP problem lives in server time or in a JavaScript animation, a perfectly compressed hero image will change nothing at all. Measure first. Our post on how to fix LCP on mobile walks the split.

If you want us to run the image pipeline work, see website speed optimization, or run the free audit first and see what your own numbers say.

That gap is real and worth closing. What follows is our attempt to make the case for it without overstating it.

An honest correction first

An earlier version of this post argued that a well-built website belongs on the asset side of your ledger. We are walking that back, because it is not an accounting fact. Whether website spend is expensed or capitalized as an intangible depends on your jurisdiction, your accounting policy, and what the spend actually bought. Design and content work is typically expensed. Some development cost can be capitalized. A blog post is not the place to settle that, and we are not your accountants.

The defensible version of the claim is narrower and more useful: leadership under-measures this channel relative to how it measures other acquisition spend. A paid campaign gets a cost per click, a cost per lead, and a weekly readout. The website gets a redesign every few years and a subjective opinion about the hero image.

What we can actually show

We scanned 292 business websites drawn from a B2B prospect list. 191 of them returned a valid mobile result. 185 of those 191 failed at least one Lighthouse lab threshold, 165 had a lab Largest Contentful Paint over four seconds, and the median mobile Largest Contentful Paint across the cohort was 10.5 seconds.

Two things about those numbers. They are lab measurements, so they are not the same thing as Google's Core Web Vitals, which are collected from real users in the field. And the sample was purposive rather than random, so it describes that cohort of B2B prospects. It does not give you a probability about your own site. What it does establish is that slow mobile rendering is common enough in this population to be worth checking rather than assuming.

In a separate study we crawled 405 sites and analyzed 368. On 92 of those 368, an answer-critical element that was present in the rendered page was missing from the raw HTML: body text on 57 sites, links on 51, and business name, address, or phone on 54. Any system that reads the raw response instead of running the page sees a thinner version of those businesses than a visitor does.

What we did not measure

We did not measure revenue. We do not know what any of those conditions cost those companies, because we did not have their analytics, their Search Console data, or a before and after. Nobody who has only scanned a site from the outside can tell you what it is costing you. If a tool hands you a dollar figure from a scan alone, it is guessing.

The board-level question that survives

For the demand we want, are we being considered, and can we connect that visibility to qualified revenue?

That question is answerable, but not by one team. It needs impressions and queries from Search Console, field performance data from real users, analytics on what happens after the click, and a CRM that records whether those sessions turned into pipeline. Marketing is usually asked the question and controls almost none of the inputs. Engineering owns rendering and performance. Operations owns the accuracy of the business information. Subject-matter experts own whether the claims on the page are true. Sales and the CRM own whether attention becomes revenue.

If nobody in the room can assemble those four inputs, the problem is not which line of the budget the website sits on. The problem is that four teams each hold one quarter of the answer and no one has been asked to put it together.

Where we stand

We build sites, and we measure them with the same tool we give away. Our free audit loads the page in Chromium and inspects the rendered DOM rather than parsing the raw HTML response, and it runs 60 or more checks across nine categories. It reports conditions. It does not report dollars, because it cannot see them.

Run a free audit if you want a baseline. Then go get the field data, because that is the half an audit cannot see.

That turned out to be harder to get than we expected, and it is the whole reason DeepAudit exists.

What we tried first

We ran prospects through the audit tools that were already on the market. They were slow, partial, or expensive, and often all three. Some covered technical SEO and skipped content. Some covered content and ignored security headers. Very few would crawl a whole site at a price we could justify for a prospect who had not paid us anything yet.

Then we hit the problem that actually decided it. The reports did not match what we saw when we opened the same site in a browser. Pages that looked fine were flagged for missing headings. Problems we could see with our own eyes went unmentioned. When we chased the disagreements down, the cause was usually the same. The tool had read the HTML the server sent. We had been looking at the page the browser built after JavaScript ran.

Those are two different documents, and neither one is automatically the real page. We wrote that argument out in full in Raw HTML and the rendered DOM tell different stories, so we will not repeat it here. The short version is that a tool which only ever inspects one stage will make confident statements about the other stage that are not true.

What we built

DeepAudit AI loads the page in Chromium with Puppeteer, waits on a network-idle condition, and inspects the rendered DOM. It runs 60+ checks across nine scoring categories: technical, content, on-page, social, security, performance, accessibility, AI readiness, and locality. A deep scan crawls up to 50 pages. There is no account and no sales call attached to it.

It does not scroll and it does not click. That is a deliberate limit. Google Search does not interact with pages either, so a tool that scrolls and clicks can assemble a version of the page that Google will never build, and then hand you a clean report on content that is not in the index. We would rather be limited the same way our target is limited.

If you want the engineering, that is a separate post: how we built it with Puppeteer and Chromium.

What changed for us

The sales call changed. We stopped saying "your technical SEO could be stronger" and started saying "this page returns a 404 from your own footer, here is the URL." One of those is a conversation. The other is a brochure.

Scoping changed too. A proposal is much easier to write when a crawl has already told you which templates are broken and how many pages sit on each one. We were guessing at scope before. Now we are reading it off a report.

What we found once we started scanning at volume

The first batches were prospect sites we were about to call. A marketing agency had 196 words on its homepage. An SEO agency had no structured data on its own site. One company had internal pages, including services and contact, that timed out during the crawl.

Once we had scanned enough sites to say something with a denominator, we published it. In our 292-site scan, 191 sites returned a valid mobile verdict, and 185 of those 191 failed at least one mobile Lighthouse threshold. The median mobile LCP was 10.5 seconds.

Two limits on that number, because they matter. Those are Lighthouse lab measurements of LCP, FCP, and CLS, which are not the same thing as Google's field Core Web Vitals. And the sample came from a B2B prospect list, so it is purposive, not random. It tells you what we found in that list. It does not tell you the odds for your site.

What DeepAudit is not

It is not Googlebot. No third-party tool is. It loads the page in Chromium and inspects the rendered DOM, which is a useful approximation and nothing more. The only view that tells you what Google actually built is the URL Inspection tool in Search Console.

It also gets things wrong. Our external link checker has counted blocked crawlers as broken links, including on our own site. Our old H1 rule treated multiple H1 tags as a failure, which is not an SEO failure, and that rule inflated failure counts in numbers we had already published. We keep a running account of where our own scanner produces false readings in four ways an audit gives you a false reading, because a tool that cannot name its own failure modes is asking you to trust the score instead of the evidence.

We built DeepAudit because we needed the evidence. We left it free because the fastest way to find out whether a finding is real is to let the person who owns the site go look.

Of those, 191 returned a valid mobile verdict. 185 of them failed at least one threshold. Six passed all three.

That is the 96.9 percent. Here is what it does and does not mean, because the number has been quoted more carefully than it was originally written.

What we actually measured

One mobile Lighthouse run per site, checking LCP, FCP, and CLS.

| Result | Count | Rate | |---|---|---| | Failed at least one threshold | 185 of 191 | 96.9% | | Passed all three | 6 of 191 | 3.1% | | Mobile LCP over 4 seconds | 165 of 191 | 86.4% | | Mobile FCP over 3 seconds | 139 of 192 | 72.4% | | Passed the CLS threshold | 165 of 193 | 85.5% | | Failed the axe-core link-name rule | 191 of 191 | 100% |

The median mobile LCP across the valid tests was 10.5 seconds. That is the number that should have led this article from the beginning. Not a percentage of a threshold, but how long the largest thing on the page actually took to appear on a phone.

What the number is not

This is where the original version of this post overstated its own research, so we are fixing it in place rather than quietly editing it.

These are Lighthouse lab measurements, not Google's Core Web Vitals. Google's current Core Web Vitals are LCP, INP, and CLS, collected from real users in the field. We measured FCP, which is not a Core Web Vital, and we never measured INP at all. We collected no field data.

So the honest claim is: *96.9 percent of the sites that returned a valid mobile lab test failed at least one of the thresholds we configured.* It is not "96.9 percent of small business websites fail Google's Core Web Vitals."

The sample was not random. The 292 domains came from an existing B2B prospect list in our sales pipeline. We did not go looking for bad websites, which rules out one kind of bias, but it is still a purposive sample of sales-visible US B2B companies. It is a snapshot of that group, not a census of the small-business web.

So there is no "97 percent chance your site fails." We have seen that framing quoted back to us, and it is not supported. We did not randomly sample the web, and we never recorded whether any of these businesses had audited their site before.

Poor LCP was the headline finding. The cause is not in this dataset.

165 of 191 valid tests produced a mobile LCP over four seconds, with a median of 10.5 seconds. That is a real, serious result.

But an earlier version of this article told you *why*: oversized hero images, three blocking tracking scripts, fonts hiding text for three seconds. We did not measure any of that. The published dataset has 41 columns and none of them record hero-image bytes, script counts, or font-display values. Those were plausible guesses dressed as findings, and they should not have been in a research post.

LCP is a composite. The delay can come from server response time, late discovery of the resource, the download itself, render-blocking CSS or JavaScript, client-side rendering, or a render delay after the asset has already arrived. Compressing a hero image is sometimes right. It is not the diagnosis for every page, and "defer your scripts" is not a one-word repair for a tag stack that a consent tool depends on.

The correct first step is boring: find the actual LCP element on your page, then work out which part of its loading path consumed the time.

Every evaluated site failed the link-name check

All 191 sites where the accessibility check ran had at least one link that failed axe-core's accessible-name rule.

That means the link's purpose was not available programmatically. It usually announces as something useless, or as a raw URL, to anyone using a screen reader.

Icon-only social links in footers were a recurring example in our manual review, but we did not classify every failure by cause, so we are not going to tell you it was "usually" the footer. And an `aria-label` is one fix, not the only one. Visible text, visually hidden text, `aria-labelledby`, or a proper alt on a linked image can all supply the name.

One more limit: axe-core is an automated tool. It finds specific, real problems. It cannot certify a site as accessible, and it does not replace tabbing through the page yourself.

What we did not measure

No rankings. No impressions or clicks. No leads, conversions, or revenue. No real-user performance data. And we never asked a single owner what they knew about their own site.

So we cannot tell you these failures cost anyone a customer. We can tell you the failures are there, and that they are nearly universal in this sample. Whether a specific one is costing *you* anything requires Search Console, field data, analytics, and a before-and-after.

We also cannot tell you these were struggling businesses or thriving ones. Appearing in a B2B prospect database means a company was visible enough to be sold to. It does not establish revenue, headcount, or reputation, and the original version of this article claimed all three.

What to actually do

Start with the pages that produce business, not with the score.

Check whether you have field data at all, in Search Console or PageSpeed Insights. Smaller sites often do not have enough Chrome traffic to qualify, and that absence is itself worth knowing.

Run the lab test more than once and take the median. One Lighthouse run is a weather report, not a climate.

Identify your actual LCP element, then split the delay into server time, discovery, download, and render delay. Fix the part the evidence points at.

Compare your initial HTML against the rendered DOM, because content that only exists after JavaScript is invisible to anything that does not run it.

Run an automated accessibility check, then put the mouse down and tab through the page.

Then measure what changed after you shipped.

Why the data is public

The full dataset is 292 anonymized rows across 41 documented columns, CC BY 4.0.

You can recalculate every number in this post, disagree with our thresholds, and check the arithmetic. What you cannot do is re-crawl the original 292 sites, because the domains are anonymized. So the calculations are reproducible; the original collection is not. That is a real limit, and it belongs in the open.

The finding that survives

Six sites out of 191 passed all three thresholds. Every evaluated site failed the link-name rule. The median phone visitor waited more than ten seconds for the main content to appear.

Those numbers do not need the exaggeration we gave them.

Run the audit on your own site. It uses the same class of browser-based checks this study used, though a scan today will not reproduce an April 2026 measurement exactly, since the site, the test environment, and our rules have all moved since.

And treat the report as a starting point, not a verdict. That applies to our tool as much as anyone's.

The more common problem is that it keeps producing customers while each additional customer costs more than the last one did. Revenue rises. The dashboard stays green. And the economics of the *next* increase in spend have already turned.

That is the trap worth watching, and it is a number you can calculate rather than a feeling you wait for.

First, define the metric, because most people do not

Customer acquisition cost usually means total sales and marketing acquisition cost divided by new customers. That includes media, payroll, commissions, agencies, software, and creative production.

The number on your ads dashboard is something narrower: spend divided by conversions the platform attributed to itself.

Both are useful. They are not the same thing, and conflating them is how companies talk themselves into a budget increase.

Track three views:

- Blended CAC. All acquisition cost, all new customers. - Channel CAC. One channel's cost, divided by customers attributed to it. - Marginal CAC. The *additional* spend divided by the *additional* customers it caused.

The third one is the warning light.

The average hides the cost of the next customer

Spend $15,000, acquire 100 customers. Average media cost: $150 each.

Raise it to $25,000 and you acquire 125. The new average is $200, which already looks worse but still flatters the decision you just made.

Look at the increment instead. The extra $10,000 bought 25 additional customers. The marginal cost was $400 each, nearly triple the number you started with.

That does not automatically mean stop. A $400 marginal cost can be excellent if those customers carry enough gross-margin value.

It does mean you cannot use the historical average to justify the next budget increase. The average describes the customers you already bought. Marginal cost describes the decision in front of you.

Why marginal performance can weaken

The highest-intent audience is finite. Early spend reaches people searching your name, narrow commercial queries, past visitors, and buyers already near a decision. More budget has to reach broader terms, colder audiences, new geographies, or the same people more often.

Competition changes too. Google runs a separate auction for every search, decided by bids, relevance, quality, and context. More budget does not create an equivalent amount of new demand.

But do not reach for "that is just how paid behaves at scale." Sometimes it is. Sometimes rising CAC is a fixable problem hiding in the creative, the offer, the landing page, the sales follow-up, the lead qualification, the tracking, or a customer-value shift. Diagnose it before you declare the channel saturated. Saturation is a real economic possibility, not an excuse to stop looking.

Attribution is not incrementality

This is the part most acquisition reports quietly skip.

A campaign can take credit for a customer it did not cause. Branded search is the obvious case: someone already knows you, searches your name, clicks the ad sitting above your own organic result, and converts. The platform records a paid acquisition.

Would they have clicked the organic link instead? Attribution cannot tell you. Only an experiment can, which is why incrementality testing exists.

The question that matters is not "which channel got credit." It is "how many additional customers happened because of this spend." Those are different numbers, and only one of them belongs in a scaling decision.

CAC means nothing without customer value

A rising CAC is not automatically bad. Spending more is rational if the customers retain longer, buy larger, expand, refer others, or carry higher margin.

So the acquisition report needs more than a cost: gross-margin-adjusted customer value, payback period, retention, expansion, and incremental lift where you can measure it.

A channel is not healthy because its clicks are cheap. It is healthy when the customers it *causes* produce enough value soon enough to pay for the full cost of getting them.

Paid and organic distribute differently, and neither is free

Paid buys controllable distribution. Stop the campaign and the placement stops shortly after.

That does not mean everything disappears. The campaign produced customers, first-party data, tested messaging, conversion learning, reviews, awareness, and repeat business. Those persist.

Organic does not charge per click. A useful page can keep bringing people in for years.

But organic traffic is not "owned," and we should stop saying it is. You own the domain, the content, and your customer data. You do not own your ranking. Competitors improve, intent shifts, links get removed, formats change, and Google updates its systems several times a year. And organic is not free: research, writing, engineering, promotion, links, tools, and salaries all belong in the cost model. Comparing "paid CAC including every dollar" against "organic CAC counting only clicks" is a dishonest comparison, and it is the one most SEO pitches make.

The honest advantage is narrower and still real: an additional organic visit does not require an additional media payment at the moment it happens.

Do not trade one dependency for another

The lesson here is not "move the budget into SEO."

You can be just as fragile depending entirely on one search engine, one social platform, one marketplace, one referral partner, one affiliate, or one big customer. The risk is concentration, not paid media.

A resilient business usually has several things producing customers: paid, organic, referrals, partnerships, email, outbound, product-led signups, marketplaces, and expansion from customers it already has. The right mix depends on the business. The failure mode is when one platform controls nearly every new customer.

Use paid for what it is genuinely good at

Speed and testing. Messages, offers, landing pages, audiences, new markets, new categories, real demand signal in days rather than quarters.

Just remember that an attributed conversion is not full validation. You still need to know whether the customer was incremental, qualified, profitable, and retained.

Find your acquisition floor

Take the last twelve months. Do not stop at traffic, because traffic is the top of the chain, not the answer.

For each meaningful channel, work out the spend, the new customers, the contribution margin, the average and marginal CAC, the payback period, and the share of total revenue.

Then ask the question that actually matters:

If your largest acquisition channel lost half its volume next quarter, what would still produce customers?

Count the renewals, the existing pipeline, the referrals, the partners, the email list, the direct demand, the organic discovery, and the expansion revenue from customers you already have.

That is your floor. It is not an SEO score. It is the part of the business that keeps working when the dominant channel gets more expensive.

Before the next budget increase

Confirm the tracking. Separate leads from customers. Include the full acquisition cost, not just media. Calculate marginal CAC, not just average. Compare it against margin-adjusted customer value. Test incrementality if you can. Check retention and lead quality. Measure how concentrated you are.

Then decide whether the next dollar belongs in the campaign at all, or in the landing page, the sales process, retention, or organic visibility.

Paid acquisition does not inevitably stop working. The risk is that you keep scaling it after the economics of the next customer have quietly changed.

That is not a slogan. It is arithmetic, and you can do it this week.

---

If the organic side of that mix is the part you cannot assess, a technical audit will tell you what shape the foundation is in. It will not tell you whether you are trapped by CAC. For that, bring twelve months of spend, new-customer counts, gross margin, and channel data, and we will work out the average and marginal cost together.

That number is enormous and almost entirely useless to an individual business.

A niche manufacturer might have fifty commercially meaningful searches a month. A regional HVAC company might have thousands. Some businesses are built on referrals, procurement systems, and channel partners, and search barely touches the pipeline at all.

So the useful question is smaller and much harder:

For the searches and buyer questions that matter to your company, where do you appear?

Not for your company name. For the problem a buyer describes before they know which company solves it.

Most leadership teams cannot answer that consistently.

Start with the demand you can actually serve

Global search volume does not prove your company has an organic opportunity. Before investing in the channel, confirm that meaningful demand exists and learn how buyers actually phrase it.

Look at the language in sales calls, form submissions, customer emails, reviews, lost-deal notes, and Search Console queries. Build a fixed list of the searches and questions the business should credibly answer, then record for each one:

- Where the company appears - Which page appears, and whether it is the right page - How many impressions and clicks it earns - Whether those visitors become qualified leads - Whether those leads produce revenue

That is search visibility as a business metric. It is a short list of real queries with outcomes attached, not a global counter.

What our own research does and does not show

In April 2026 we scanned 292 sales-visible B2B small business websites drawn from a prospect list.

Of those, 191 returned valid mobile Lighthouse data. Within that group, 96.9 percent failed at least one of the laboratory thresholds we configured.

That wording matters, and the earlier version of this article got it wrong. We did not measure Google's operational Core Web Vitals. We ran synthetic Lighthouse tests covering LCP, FCP, and CLS. Google's current field metrics are LCP, INP, and CLS, collected from real users. We collected no INP and no field data.

So we did not prove that 96.9 percent of 292 businesses fail Core Web Vitals. We found that weak simulated mobile performance was overwhelmingly common among the sites that returned a valid test.

That is still worth knowing. It is not a visibility measurement.

Technical health and visibility are related, not interchangeable

This is where most audit-driven arguments overreach, including ours.

A slow, inaccessible, or hard-to-crawl page can create real friction. But a technical scan cannot tell you where the page ranks, how often it appears, how many people clicked, whether the business shows up in local results, whether the visitors were qualified, or how much revenue the page produced.

Those need Search Console, Business Profile data, analytics, CRM outcomes, and someone looking at the actual results.

The audit describes the condition of the website. Visibility describes whether the market encounters it. Revenue describes whether that encounter mattered. Three different questions, three different instruments.

We also did not survey a single owner in that study, so we cannot tell you what they knew about their own sites. The honest limit of the finding is the finding itself.

Search is not only a marketing dependency

Marketing usually owns SEO and controls almost none of what it depends on.

Engineering controls rendering, performance, and technical access. Subject-matter experts control whether the content is accurate and worth finding. Operations controls locations, hours, and contact details. Reputation, partnerships, and customer experience shape the evidence that exists about the company across the web. Sales and the CRM decide whether organic attention becomes qualified business.

Leadership's job is not to run the channel. It is to make sure those parts are measured together, because no single team can see the whole path.

A local search is not decided by a technical score

Consider a regional HVAC company competing for "AC repair near me" in July.

Google says local results are driven mainly by relevance, distance, and prominence. The website supports that: it can describe the service and the service area clearly, reinforce the business identity, and give a panicking homeowner an obvious way to call.

But a perfect Lighthouse score does not erase distance. Schema does not replace reviews. A fast site does not fix the wrong Business Profile category.

A company with decades of experience can absolutely lose to a newer competitor with better digital infrastructure. It can also lose because the competitor is four miles closer to the customer. Our audit cannot tell you which happened, and neither can anyone selling you a score.

Use click-through studies carefully

Higher positions generally get more attention. The Backlinko analysis of four million results shows click-through declining sharply with rank, and the broad pattern is real.

The actual rate depends on the query and what else is on the page: ads, local packs, shopping results, videos, featured snippets, AI Overviews. Two results at the same organic position can perform completely differently.

Use third-party studies for context. Use Search Console for your own numbers, and look for the specific shapes worth acting on:

- A page with thousands of impressions and almost no clicks - An important query sitting just outside the visible results - The wrong page ranking for a search you care about - A strong position producing traffic but no qualified leads

Those are decisions. A global search statistic is not.

What leadership should actually review

A useful search report does not need hundreds of rankings. For a fixed set of commercially important searches, each period:

- Current organic and local visibility - Impressions and clicks - Which landing pages received the demand - Qualified leads and revenue from those pages - Meaningful competitor changes - Important pages missing, buried, duplicated, or declining - Technical, content, identity, or reputation changes that could explain a move

That tells leadership whether the company is entering the buyer's consideration set. An SEO score does not.

Where the audit fits

DeepAudit loads a page in Chromium and inspects the rendered result rather than relying only on the initial HTML. It checks performance, technical SEO, content, structured data, accessibility, security, and crawlability signals. It takes about a minute and needs no account.

It identifies things to investigate. Search Console, field data, rankings, analytics, and a person reading the page determine whether those findings are affecting the business.

The board-level question

The question is not "are we doing SEO."

It is: for the demand we want, are we being considered, and can we connect that visibility to qualified revenue?

A company can have an excellent product and publish weak evidence of it. It can also have a technically perfect website and an offer nobody wants. Search visibility does not replace product quality, reputation, or sales execution. It determines whether some buyers encounter those strengths early enough for them to matter.

That is why it belongs in the business review. Not because five trillion searches happen every year. Because a small, measurable portion of them may belong to you.

A correction first

An earlier version of this post said that paid traffic is rented land and organic search is ownership. That framing is tidy, and it is wrong. You do not own an organic ranking. It is granted by a third party, revised without notice, and revocable. The true statement is narrower: organic visibility does not stop the moment you stop paying, and it accrues to work already done. That is a real difference in cost behavior. It is not ownership.

The same post also claimed that underinvesting in SEO costs companies millions in avoidable customer acquisition cost, and it cited a daily global search volume figure to support the point. We have no data for either claim. Both are deleted rather than replaced.

What search visibility depends on, and who controls it

| Dependency | Who controls it | | --- | --- | | Whether the page renders content a crawler can read | Engineering | | Mobile load performance | Engineering, plus whoever approved the third-party scripts | | Accurate business name, address, hours, and services | Operations | | Whether the claims on the page are true and current | Subject-matter experts | | Whether an interested visitor becomes qualified pipeline | Sales and whoever owns the CRM | | Keywords, content, titles, and internal linking | Marketing |

Marketing owns the last row and is measured on all six. That is a structural failure, and reallocating budget does not fix it. Leadership's contribution here is not moving SEO to a different line item. It is making sure these things are measured together and reviewed together, by the people who can actually change them.

The evidence we have

Two of our own studies speak directly to the engineering rows.

We scanned 292 sites from a B2B prospect list. 191 returned a valid mobile result. Of those, 185 failed at least one Lighthouse lab threshold and 165 had a lab Largest Contentful Paint over four seconds. The median was 10.5 seconds. These are lab numbers, not the field data Google uses for Core Web Vitals, and the sample was purposive rather than random. Treat it as a reason to check your own site, not as a probability about it.

We separately crawled 405 sites and analyzed 368. On 92 of them, something answer-critical was present in the rendered page and missing from the raw HTML: text on 57, links on 51, and name, address, or phone on 54. Systems that read the response instead of running the page see less of those businesses than a person does.

Neither of those findings is a marketing failure. Both of them land on a marketing scorecard.

The board-level question

For the demand we want, are we being considered, and can we connect that visibility to qualified revenue?

Answering it takes four inputs that live in four different systems: query and impression data from Search Console, field performance from real users, analytics on what happens after the click, and CRM records showing which sessions became pipeline. If nobody in the room can assemble those four, the honest answer is that you do not know, and the first project is instrumentation rather than content.

That question is worth more than any of the checklists we used to publish, because it does not depend on believing a metaphor.

What we do not claim

We do not promise a timeline. We have seen organic work pay back and we have seen it stall, and the difference usually had more to do with competitive density and the state of the site than with effort or spend. Anyone promising measurable organic growth in ninety days is selling certainty they do not have.

If you want a baseline on the technical dependencies, run a free audit. It loads your page in Chromium and reports what it finds in the rendered DOM across 60 or more checks in nine categories. It reports conditions. Turning conditions into a revenue number requires your data, not ours.

Lying requires intent, and that is not what happens. What happens is that a tool makes a compromise to stay fast and cheap, and then reports the result with more confidence than the method earned. The number is precise. The method behind it is not. Our own tool does this too, and we name our cases at the end of this post rather than pretending we are the exception.

Here are the four compromises, worst first.

1. The data is not from today

The ranking positions, backlink counts, and authority scores in most platforms do not come from a live look at your site. They come from an index the tool built on its own schedule, which may be days or weeks old.

So you fix a broken canonical, ship it, re-run the audit, and the tool flags the same problem, because it is replaying a crawl from last Tuesday. Or you lose a batch of backlinks and the tool keeps counting them for a month. Either way, a snapshot of the past is being presented as the present, and nothing in the interface says so.

Before you trust any change, find the "last crawled" or "data as of" date. If the tool does not show you one, that is your answer. Verify the specific fix against Google Search Console, which reflects Google's own most recent view of your site, or against a live fetch of the page.

While you are there: "domain authority" is not a Google metric. It is a third-party proxy, and different vendors compute it differently. We use Open PageRank in our own reports for the same reason everyone else uses something similar, which is that no first-party number exists.

2. The crawl stopped early

Full crawls are expensive, so tools cap them. Free and mid-tier plans routinely walk the first few hundred URLs, or the pages the crawler decided were important, and then stop. On a site with thousands of pages, "no issues found" can mean "no issues on the 500 pages we looked at," and the report will not distinguish between those two sentences.

Keyword rankings carry the same limit. Many tools estimate your position from a panel or a periodic check across a sample of locations and devices, not from where your customers actually search. The one place you can see every query you appeared for, with no sampling, is your own Search Console Performance report.

Practical version: on any site larger than a few hundred pages, ask what the crawl budget was, then hand-check the templates that make you money.

3. The score at the top is one blended number

The 0 to 100 grade is the least useful number in the report, and it is the first thing everyone reads.

It averages checks of wildly different weight. A missing meta description and a page that will not render for a crawler move the same dial. That means a site can lose a handful of points for something cosmetic, lose a handful more for something fatal, and land at 84 either way. In our 292-site scan, the median mobile LCP was 10.5 seconds. A page can be that slow and still hold a respectable overall grade, because the grade is an average and the ten seconds is one term in it.

Read the failed checks, worst first. The average is not the finding.

4. The tool read the HTML, not the rendered page

Most auditors send an HTTP request, take the raw HTML response, and parse it. That worked when every page was server-rendered. On a client-rendered React, Vue, or Svelte app, the first response can be close to an empty shell, and the headings, copy, links, and structured data arrive only after JavaScript runs. A raw-HTML tool reports all of that as missing.

The parser is not hallucinating. That content genuinely was not in the response. But it is a fact about one stage of the page, not a verdict on the page. The reverse trap is just as real: a browser-based tool can build a DOM that no crawler will ever assemble and then call the page healthy.

We have a full post on that one, with the study behind it: raw HTML and the rendered DOM tell different stories. Across 368 sites we analyzed, 92 of 368 lost at least one answer-critical element between the rendered DOM and the raw HTML.

Our tool does all four of these

We build DeepAudit AI. It is subject to every failure mode above, and here are the specific ones we know about.

It has reported broken links that were not broken. Our external link checker treats a failed fetch as a broken link. On our own site it recently returned nine broken links, and all nine were fine in a browser. LinkedIn answers automated requests with a 999 status. SSRN returns 403 to datacenter IP addresses. A client-rendered social app returned a 404 to the crawler while the page loaded normally for a person. That is a blocked crawler, not a dead link, and reporting it as breakage is exactly the kind of false confidence this post is about. We are rewriting the check to report blocked and unverifiable links in their own bucket instead of folding them into a broken count.

Our H1 rule was too strict. We counted multiple H1 tags as a failure. Multiple H1s are not an SEO failure. That rule inflated failure counts in numbers we published, and we have since demoted it to a warning.

We sample too. A DeepAudit deep scan crawls up to 50 pages. If your site is larger than that, our report describes 50 pages, not your site.

We print a score at the top. It is the same blended average we just told you to ignore. Use it to compare a page against itself over time. Do not use it to decide what to fix.

We are not Googlebot. We load the page in Chromium and inspect the rendered DOM. That is an approximation of one stage of Google's pipeline, and it is not the index. Google crawls, queues, renders, then indexes, and the only tool that reports what Google actually built is URL Inspection in Search Console.

How to read any audit, including ours

- Confirm the tool executes JavaScript before you believe anything it says about your content. - Check the data date on rankings, backlinks, and authority scores. - Assume the crawl was partial, and hand-check the pages that matter. - Skip the headline score and read the failed checks, worst first. - Reproduce the finding yourself. If you cannot reproduce it, it is a lead, not a fact.

That last line is the entire method. An audit is a list of places to look, not a verdict. Trust the specific finding you can open in a browser and see, including when the tool that produced it is ours.

Run the free audit. No signup. Then go check its work.

The first is the response the server sent. The second is the DOM the browser built after JavaScript ran.

They might be nearly identical. They might also carry different headings, links, canonicals, robots directives, structured data, forms, and body copy.

A serious audit does not pick one and call it the real page. It compares them, and the finding is usually the difference.

What the initial response tells you

A source-level auditor makes an HTTP request and reads what comes back. That is still valuable, and the tools that do it are not obsolete.

The response tells you the status code, the redirects, the headers, whether robots directives and a canonical were present before any script ran, which links were immediately crawlable, and what body content existed without JavaScript.

A purely client-rendered application may return little more than a mounting element:

```html

When an HTML parser reports that this response contains no heading and no body copy, it is not hallucinating. That content genuinely was not there yet. That is a real fact about what your server delivered, and it is exactly what a non-rendering crawler receives.

What the rendered DOM tells you

The browser adds the next layer. It fetches scripts, requests data, builds components, injects metadata, initializes forms, and attaches handlers.

That lets a browser-based audit see runtime content, JavaScript errors, failed requests, hydration behavior, client-injected JSON-LD, layout shifts, long tasks, accessibility problems in the finished DOM, and widgets that never initialized.

The rendered result is not automatically the correct one. It is a later stage of the same page.

Google processes both stages

This is where the usual framing gets it wrong, including our own earlier version of this article.

Google does not choose between the source and the rendered page. Its pipeline is crawl, then render, then index. Googlebot fetches the URL and parses the response first, extracting links and reading directives before any JavaScript executes. Eligible pages then go into a rendering queue, where Chromium runs the scripts and Google processes the rendered HTML as well. That queue can clear in seconds or take considerably longer.

One detail matters more than most people realize: Google does not click or scroll. Content that only appears after a user interaction may never reach the version Google indexes. Lazy-loaded content should load on viewport visibility, not on a scroll event.

So "it works in my browser" is not enough. And "Google renders JavaScript" is not a license to ship an empty document when the server could have sent something useful immediately.

The framework is not the diagnosis

React, Next.js, and Vue are not rendering strategies. A React app can be fully client-rendered, server-rendered, statically generated, or some hybrid. Next.js usually sends substantial HTML before hydration.

The question is never which framework is in the repo. It is what the server returned for this URL, and what changed after the scripts ran.

A parser can report a false problem, and a browser can hide a real one

If a page's H1 and JSON-LD are created by JavaScript, an HTML-only tool will report them missing and a browser-based tool will find them. Both are correct about the stage they inspected.

That does not automatically mean the site is broken. Google can process JavaScript-generated structured data once it exists in the rendered DOM. What the source report actually tells you is that those elements now depend on rendering succeeding, which is a dependency worth knowing about, not automatically a defect. It may be perfectly acceptable. It may also fail for a crawler that never runs scripts, during a runtime error, or when a third-party request times out.

The reverse trap is just as real. An auditor that scrolls the page, clicks controls, and waits out every background request can build a DOM that Google never receives. That tool will hand you a clean report on content Google cannot see.

For the record: DeepAudit does not scroll or click. It loads the page in Chromium, waits on a network-idle condition, and captures what is there. That is a deliberate choice, because Google does not interact with the page either. We would rather be limited in the same way our target is limited than produce a flattering DOM nobody else will ever build.

The difference is the finding

The most useful output is rarely the raw page or the rendered page on its own. It is what changed between them.

- Did the main body copy appear only after rendering? - Did the canonical URL change? - Did a second robots directive show up at runtime? - Did the navigation disappear after hydration? - Did structured data arrive only after a third-party request finished? - Did the contact form exist in the browser but not in the response?

We measured exactly this gap across 368 small business websites. One in four omitted at least one answer-critical element from the initial HTML that was present after rendering. That study was built for this question, which is why we cite it here rather than borrowing a number from our general audit research.

A real example

We once chased product schema that some tools found and others did not.

The JSON-LD was injected by a third-party component after an asynchronous request completed. On some runs it entered the DOM before the audit's timeout. On others it did not. The markup was not wrong. Its availability was a race condition.

The fix was not to argue with the scanner. It was to move the JSON-LD into the server-rendered response so that its presence no longer depended on a component finishing in time.

Test all three versions

For any page that matters, look at three things:

1. The source response. View Source, not Inspect. Inspect shows the DOM after scripts have run. 2. The rendered page, with JavaScript enabled. 3. Google's own rendered result, via the URL Inspection tool in Search Console. That is the only view that tells you what Google actually built, and no third-party tool is Google.

In each one, search for the main heading, the body copy, the internal links, the canonical, the robots directives, the structured data, the contact details, and the conversion path.

When the versions disagree, do not just pick the one you like. Find out why.

An HTML-only audit can miss the entire application. A browser-only audit can miss how weak the document was before the application started.

Run the free audit if you want the rendered view. Then open View Source yourself and compare. The gap between those two is where the actual work is.

That was the wrong lesson, and it took us a while to see it.

The right one is that we would never stop at raw HTML. The server response tells you what existed before any JavaScript ran. Google parses that response, extracts links from it, and reads its directives before rendering anything. Some crawlers never process anything else. A weak initial document is not irrelevant just because the browser eventually replaces it.

So the real design is two captures: what the server sent, and what Chromium built. The difference between them is usually the finding.

Why the browser was necessary anyway

A client-rendered application can return an initial document that is little more than a root element and some script tags. After the scripts run, the browser may add the main heading, the body copy, the navigation, the canonical, the structured data, the forms, and every internal link.

An HTML-only tool misses all of it. A browser-only tool makes the opposite mistake: it finds the finished page and never tells you the whole thing depends on JavaScript executing successfully.

We stopped arguing about which one was the real page and started saving both.

Why Puppeteer

We looked at Playwright, Selenium, and static parsers.

Our requirements were narrow: one browser engine, a JavaScript API the team already knew, direct access to the page and network lifecycle, and something that would run headless in Lambda. We did not need a cross-browser test suite.

Puppeteer fit the system and the team we had. Playwright would have been a perfectly defensible choice. This was not an objectively correct architectural decision, it was a fit decision, and pretending otherwise would be dishonest.

networkidle2 is a heuristic, not a definition of done

Our navigation still uses `waitUntil: "networkidle2"` with a 20-second ceiling. It is a good default. It is not proof that a page finished rendering.

Network-idle rules tell you network activity stayed below a threshold for a while. They do not tell you a component reached a ready state, a font settled, a delayed timer will not fire, or a third-party widget will ever finish.

We learned this the hard way on our own site. An earlier version waited for complete network silence, which never arrives on pages where analytics and background requests keep firing. Perfectly healthy pages were being flagged as failures because the capture never resolved. Waiting harder is not the same as waiting correctly.

A timeout should not erase the evidence you already collected. Ours returns partial results and says which stages completed, because a missing schema finding is worthless if navigation died before the script that injects the schema ever ran.

We deliberately do not scroll

This is where we changed our minds most sharply, and where a lot of audit tools go wrong.

The obvious move is to auto-scroll the page so intersection observers fire and every lazy-loaded image and component appears. It feels thorough. It produces a rich, complete DOM.

It also produces a DOM Google will never build. Google Search does not scroll and does not click. Content that only materializes on interaction may never reach the version Google indexes.

So DeepAudit does not scroll and does not click. It loads the page, waits, and records what is there without interaction. We would rather be limited in the same way our target is limited than hand you a flattering report on content no crawler will ever see.

If you do add a scrolling pass, keep it as a *separate* capture and bound it hard: max iterations, max distance, max elapsed time, and a stable-height check. An infinite-scroll page will otherwise keep your auditor alive forever.

Check the response before you trust the DOM

`page.goto()` returns a response object, and Puppeteer does not throw on a 404. If you ignore that return value you can produce a beautiful, confident SEO audit of an error page.

We record the status, the final URL, the redirect chain, and the headers before evaluating a single rule.

Public URLs are hostile input

This is the section the original version of this article was missing entirely, and it is the most important one for anyone building this.

An audit tool takes a URL from a stranger and loads it in a real browser. You are not running a crawler. You are running an untrusted code execution service that makes outbound network requests from inside your infrastructure. That is a server-side request forgery engine unless you build it not to be.

Ours intercepts every request and aborts anything that resolves to a private address:

```js // SSRF: intercept all requests, block private/internal destinations if (isPrivateIp(host)) { req.abort("blockedbyclient"); } ```

`isPrivateIp()` covers RFC1918 space, loopback, IPv4-mapped IPv6, and `169.254.x.x` link-local, which is also the AWS instance metadata endpoint. That last one matters: an unguarded headless browser pointed at `169.254.169.254` will happily fetch your cloud credentials and hand them to a page you did not write.

We resolve the host and check the resolved address, not just the string, because a hostname can resolve to a private IP and a redirect can land somewhere the original URL did not.

The rest of the job is bounded too: fixed navigation and total deadlines, HTTP and HTTPS only, and a browser closed in a `finally` so a throw during evaluation cannot leak a Chromium process.

Rendering accuracy does not matter if your auditor becomes a way into your own infrastructure.

About the user agent

We should be straight about this, because it is a real methodological choice.

DeepAudit does not announce itself. It presents as Chrome on a Pixel 5, because mobile rendering is what we are trying to reproduce and because that is the experience most visitors actually get.

That is a tradeoff, not a virtue. A declared crawler UA is more transparent and gets blocked more often. A browser UA sees what a browser sees and is less honest about what it is. We chose the browser profile and we are telling you we did, which is the only defensible version of that choice.

What we do not do is try to defeat bot detection. When a site blocks us, we detect it and say so:

```js cloudflare: "This site uses Cloudflare bot protection and blocked our automated browser. The audit cannot analyze the actual page." ```

Reporting "we were blocked" is a real finding. Quietly evading the block and reporting a score is a lie with a number attached.

What a rule should return

The original design returned a shape like this:

```js { check: "h1-presence", status: "pass", impact: "high" } ```

The problem is `impact: "high"`. Finding an H1 is an observation. Its business impact depends on the page, the visible title, the heading structure, the search demand, and what Google actually processes. The detector cannot know any of that.

Detection and interpretation have to be separate fields. A result should carry what was observed, where the evidence came from, how confident the detector is, whether a human needs to look, and which rule version produced it.

Provenance is the part people skip. "Canonical missing" is not a finding. These are three different findings:

- The canonical was absent from the HTTP response. - The canonical appeared only after JavaScript ran. - The response and the rendered DOM declare *different* canonicals.

A report that collapses those into one red icon is not helping anyone.

We also learned to keep a status for "inconclusive." A page that timed out, a rule that did not apply, and a verified defect should not look identical.

We got a rule wrong, and it shipped

Our H1 rule failed any page with more than one H1. Multiple H1s are not automatically a defect: Google reads headings for structure, and HTML5 sectioning permits them.

That single overly strict rule inflated the H1 failure number in every city study we published and every client report we generated, until we caught it and downgraded it to a warning. A polished report does not make a detector correct.

Every rule needs a version, a test, and a way to be wrong in public.

Chromium lifecycle mattered as much as the audit logic

That is still the truest sentence in this article.

A fresh browser per request is fine at low volume and wasteful fast. One leaked process destabilizes a worker. The browser close belongs in a `finally`, not at the end of the happy path, because the happy path is not where the leaks come from.

If we started again, we would build browser lifecycle management before we built most of the SEO rules.

We would also separate capture from analysis sooner. Rendering is expensive; once you have a good snapshot, many rule versions can analyze the same evidence without loading the page again. But a cached DOM is evidence, not truth. Every snapshot needs a timestamp, a browser version, a viewport, a UA, and an interaction state attached, and personalized or fast-changing pages should not be cached at all.

Our first 14-site pilot

Before we opened this publicly, we ran it against 14 websites from our own prospecting list. The point was never to measure the web. It was to find out which of our rules were wrong and which captures were failing.

Of the 14 pages: 12 produced at least ten HTML-validator errors, and 10 scored under 50 on the accessibility check. One marketing agency's homepage had 196 words. One SEO agency had no structured data on its own site. And one company had 12 internal URLs, including services and contact, that never completed inside our capture window.

Two honest caveats, because we have been telling everyone else to state theirs.

We did not keep the raw scan records, and we never wrote down which accessibility scorer produced that number or what timeout the URLs blew through. So those two counts cannot be independently checked, including by us. That is a process failure, and it is exactly why the later studies ship a dataset.

And a pilot of 14 purposively chosen prospects estimates nothing. It cannot tell you what share of the market has these problems. What it did do is expose which findings we were interpreting badly, which turned out to be most of them:

A raw count of validator errors says nothing about severity. Ten obsolete attributes are not a `` that closes early and eats your metadata. We had to classify them before the number meant anything.

A low automated accessibility score marks a page for review. It does not establish WCAG conformance either way, and no automated tool does.

The 196-word homepage was worth *reading*, not scoring. Google has no minimum word count. The real question was whether those 196 words explained what the agency did, and they did not.

The missing schema was an opportunity to make visible facts explicit, not proof that Google could not understand the site. Plenty of pages rank with no JSON-LD at all.

And 12 timed-out URLs is a finding about our scanner's capture limit until someone confirms the pages also fail for real visitors. A browser timeout and a broken contact page are not the same event, and we reported them as if they were.

That pilot taught us more than any percentage in it. A detector can identify a condition. It still needs scope, evidence, and a human before it becomes a recommendation.

Where it is now

The first public version audited one page and ran about 60 checks.

The current system runs 60-plus checks across 9 categories and does a bounded same-site deep scan of up to 50 pages. The code in this article reflects the early single-page architecture, and we would rather show you that history than pretend the mature version existed on day one.

If an SEO audit never executes JavaScript, it may never see the problems your users and search engines actually experience. And if it inspects only the rendered DOM, it may never see the weak document the server sent before the application started, the conflicting directive, or the fact that everything on the page depends on one script succeeding.

That is the sentence this whole system is built around.

The lesson underneath all of it has not changed:

Do not trust only the source. Do not trust only the rendered DOM. Do not trust one readiness event. And do not trust an automated rule just because it returned a confident answer.

Capture the evidence at each stage, record where it came from, and let the disagreement tell you where to look.

That is what Puppeteer actually gave us. Not a copy of Google. A repeatable browser where we could finally see what changed after the server response arrived.

Run the audit if you want to see the output. Then open View Source and compare it yourself.