DEV Community: Joshua Gutierrez

Turning an SEO Audit Into a Revenue Strategy

Joshua Gutierrez — Fri, 05 Jun 2026 19:37:10 +0000

Most SEO work starts with a checklist.

Titles. Headings. Keywords. Page speed. Internal links. Technical errors. Content gaps.

Those things matter, but they are not the whole job.

For Axion Deep Digital, the real problem was not simply whether the site could rank. The deeper question was whether the site could turn search traffic into qualified business.

That changed the entire direction of the project.

This was not just an SEO audit. It became a full search, offer, conversion, and measurement strategy.

The Starting Problem

Axion Deep Digital already had a strong foundation.

The site had service pages, local pages, blog content, research pages, and a free SEO audit tool. It also had real traffic coming in.

But traffic alone does not mean the website is working.

The question was simple:

Where are visitors entering, what are they trying to do, and why are they not becoming leads?

The first audit showed that the issue was not one bad headline or one missing button. The issue was structural.

The site had three major conversion leaks.

First, several pages had offer and intent mismatch. A visitor reading about review generation, Google Business Profile management, or conversion optimization was often pushed toward the same generic SEO scanner. That created a disconnect. The visitor came for one problem, but the offer answered a different one.

Second, there was call to action dilution. Multiple pages asked visitors to book a call, run an audit, request a quote, contact the company, or explore another page. When every action is presented as equally important, the visitor has to decide what matters. That creates friction.

Third, the audit result moment was underused. When someone enters their website and views an audit result, they are showing intent. That result page should not behave like a static report. It should become the strongest sales page on the site, because it is personalized, timely, and tied directly to the visitor’s problem.

What the Traffic Data Changed

The first recommendation set focused heavily on the highest intent moments.

That was useful, but incomplete.

A high intent moment only matters if enough visitors reach it.

The traffic data changed the priority order. Over a ninety day period, the homepage and the free SEO audit page represented most of the site’s entry traffic. The homepage carried the largest share, while the free SEO audit page had the strongest engagement.

That meant the highest leverage work was not buried deep in the site. It was right at the front door.

The strategy shifted from “fix every page” to “fix the spine.”

The first priority became the path most visitors were already taking:

Homepage
Free SEO audit page
Audit start
Audit result
Qualified next step
Tracked lead record

That path became the foundation for the entire strategy.

The Real SEO Lesson

The biggest lesson was that SEO should not stop at rankings.

Ranking gets the visitor to the page. Strategy decides what happens next.

A page can rank and still fail if the offer does not match the searcher’s intent. A page can get traffic and still fail if the call to action is unclear. A page can create interest and still fail if there is no measured path from visit to lead.

That is why this project treated SEO as a business system, not just a visibility project.

The work had to connect:

Search intent
Page type
Offer match
Conversion path
Audit experience
Lead qualification
Analytics
Revenue potential

That is the difference between getting more traffic and building a search engine that produces business.

Rebuilding the Offer Strategy

The site already had a strong central asset: the free SEO audit.

The problem was that too many different pages leaned on the same generic version of that offer.

A better system changes the promise based on the visitor’s intent.

A visitor on the free SEO audit page wants a visibility diagnosis.

A visitor on a web development page wants to know whether the current website is costing revenue.

A visitor on a Google Business Profile page wants to know why competitors are showing up in local results.

A visitor on a review generation page wants to know whether their review profile is weaker than competitors.

A visitor on a conversion optimization page wants to know where leads are leaking.

The same technical system can support all of those experiences, but the offer has to feel specific.

So the strategy became:

Website visibility audit for SEO traffic.

Revenue leak audit for web development traffic.

Local visibility audit for Google Business Profile traffic.

Review gap audit for review generation traffic.

Lead leak audit for conversion optimization traffic.

That keeps the offer aligned with the page promise.

Turning the Audit Result Into a Sales Page

The audit result page became the most important strategic surface.

A weak audit result says, “Here is your score.”

A stronger audit result says, “Here is what is wrong.”

A great audit result says, “Here is what matters most, why it affects your business, and what to do next.”

The improved result experience should show the visitor:

Their score
The most important issues
The likely business impact
The top three fixes
The next best action
The risk of doing nothing
A simple way to get help

This matters because most business owners do not need a wall of technical information. They need prioritization.

They need to know what is hurting rankings, what is hurting leads, and what should be fixed first.

That makes the audit result more than a report. It becomes a personalized decision page.

Fixing the Call to Action Problem

One of the clearest problems was that the site used too many different action paths.

Some pages pushed a free audit.

Some pushed a consultation.

Some pushed a quote.

Some pushed a contact form.

Some pushed multiple options at once.

The fix was not to remove every secondary path. The fix was to create hierarchy.

Each page should have one primary action.

For cold or informational traffic, the primary action should usually be the free audit.

For warmer commercial traffic, the primary action can be a guided review or teardown.

For visitors who already completed an audit, the next action should be a specific help offer tied to their result.

The key is that the visitor should never wonder, “What am I supposed to do next?”

The page should make the next step obvious.

Why Measurement Had to Come First

The traffic report showed another major issue: the site was counting sessions, but not meaningful conversion events.

That meant the site could see activity, but not business movement.

A proper SEO strategy needs measurement from the first visit to the final lead outcome.

The measurement plan should track:

Landing page
Audit started
Audit completed
Score generated
Email captured
Booking clicked
Booking completed
Contact submitted
Lead qualified
Deal won or lost
Revenue attached

Without that event chain, optimization is mostly guesswork.

With that chain, the site can answer the questions that actually matter.

Which pages create leads?

Which offers attract qualified buyers?

Which audit scores lead to calls?

Which search paths create revenue?

Which pages only create noise?

That is how SEO becomes accountable.

The Final Strategy

The final strategy was not to patch every page at once.

The better move was to build one end to end trust slice first.

That slice starts with the homepage and free SEO audit page, moves into the audit experience, turns the result into a personalized sales page, routes the visitor to the right next step, and records the lead in a way that can be measured.

Once that works, the same model can be adapted across the site.

The web development page can use a revenue leak version.

The local pages can use a local visibility version.

The Google Business Profile page can use a map visibility version.

The review generation page can use a review gap version.

The conversion optimization page can use a lead leak version.

That creates a repeatable SEO and conversion system instead of a collection of disconnected pages.

What This Project Demonstrates

This project shows how I approach SEO work.

I do not treat SEO as a checklist or a collection of isolated page edits.

I look at how search intent, page structure, offers, analytics, conversion flow, and business value connect.

The work included:

Auditing page intent
Identifying offer mismatch
Reviewing traffic concentration
Reprioritizing based on impact
Designing a cleaner conversion path
Improving the audit result experience
Planning event tracking
Connecting SEO work to qualified leads and revenue

The final outcome was a more disciplined strategy:

Focus on the pages with the most current opportunity.

Match each offer to the visitor’s intent.

Make the audit result the strongest conversion moment.

Track every meaningful action.

Optimize for qualified revenue, not vanity traffic.

For this project, SEO was the entry point.

The real work was building a smarter path from search visibility to business growth.

By Joshua R. Gutierrez
SEO Specialist, Axion Deep Digital

Hardening Two Multi Tenant SaaS APIs

Joshua Gutierrez — Fri, 05 Jun 2026 18:08:08 +0000

What We Found, What We Fixed, and What Changed

Security hardening is not glamorous work.

Most of it is careful reading, boring verification, uncomfortable edge cases, and refusing to trust assumptions that have quietly become part of the system.

Recently, I completed a remediation pass across two multi tenant SaaS products: Site2CRM and Made4Founders. Both products had grown into real platforms, with authenticated dashboards, public webhooks, billing flows, CRM integrations, OAuth style connections, file uploads, background jobs, and customer owned data.

That kind of product has a wide attack surface.

The work started with security reports and ended with two hardened branches, 24 total commits, more than 140 new regression tests, database migrations, centralized security utilities, audit logging, startup gates, and CI checks that now block the same classes of mistakes from coming back.

This article is a breakdown of what we found, how we fixed it, and the engineering lessons that came out of the process.

The goal was not just to close findings

A security report usually arrives as a list of issues.

That can make the work feel transactional.

Fix this endpoint. Add this check. Reject this payload. Patch this route.

That is necessary, but it is not enough.

The real question is:

What class of mistake allowed this bug to exist?

That question changed the remediation strategy.

For every finding, the goal became:

Fix the specific issue
Add a regression test for that finding
Centralize the security pattern where possible
Add a guard so the same mistake is harder to reintroduce
Document any deployment or data migration steps clearly

That approach turned the work from a cleanup pass into a hardening pass.

Finding 1: Tenant data must always be scoped by tenant

In a multi tenant application, the most important security rule is simple:

A customer should only be able to access data that belongs to their organization.

That rule sounds obvious, but enforcing it consistently is where systems get tested.

A risky query often looks harmless:

lead = db.query(Lead).filter(Lead.id == lead_id).first()

The problem is that lead_id alone is not a tenant boundary.

In a multi tenant system, the query needs to prove both identity and ownership:

lead = (
    db.query(Lead)
    .filter(
        Lead.id == lead_id,
        Lead.organization_id == current_user.organization_id,
    )
    .first()
)

The same principle applies to updates, deletes, dashboard feeds, background jobs, calendar items, configuration records, and integration data.

In one case, a calendar feed was using a join path that could leak data across tenants. In another, a vault configuration model had rows that were not safely attached to an organization. Both issues were fixed by making organization ownership explicit, adding migrations where needed, and creating regression coverage around the exact failure modes.

The broader lesson was this:

Tenant isolation should not depend on developer memory.

It should be a pattern the codebase makes easy and the test suite actively defends.

Finding 2: Organization admins are not platform admins

One of the clearest authorization lessons came from a global resource protected by a tenant level role check.

Most SaaS products have organization roles like:

OWNER
ADMIN
USER

Those roles are useful inside a customer account. An organization owner should be able to manage users, settings, forms, integrations, and billing details for that organization.

But tenant authority is not platform authority.

A customer OWNER should not be able to manage global platform resources, issue marketplace codes, access internal tools, or make changes that affect other organizations.

The risky pattern was conceptually simple:

if current_user.role not in ["OWNER", "ADMIN"]:
    raise HTTPException(status_code=403)

That check answers the wrong question.

It asks:

Is this user powerful inside their own organization?

For global platform actions, the application needs to ask:

Is this user trusted to operate the platform itself?

The fix was to introduce a real platform staff boundary and move global operations behind that boundary.

require_platform_staff(current_user)

This was not just a one line fix. Tests were added to prove that tenant owners and tenant admins could not access platform scoped functionality. A static guard was also added so future global table routes cannot quietly be protected only by tenant roles.

The lesson:

Never reuse customer roles for platform administration.

They represent different trust models.

Finding 3: Public webhooks are public, not trusted

Public webhook endpoints need to be reachable by external providers.

That does not mean they should trust incoming requests.

Several webhook surfaces needed stronger sender verification. The risk was not that the endpoints existed. The risk was that state changing payloads could be processed without proving they came from the provider they claimed to represent.

The corrected model is:

Read the raw request body
Verify the provider signature
Reject missing or invalid signatures
Parse the payload only after verification
Apply idempotency where relevant
Mutate state
Return success

This mattered for provider events such as:

Inbound messaging events
Email bounce and complaint notifications
Billing lifecycle events

Billing webhooks received extra attention because they can change plan state. A forged billing event can potentially activate, cancel, downgrade, or otherwise alter customer access.

The fix was to make verification mandatory. If the provider webhook secret or webhook ID is missing in production, the app should fail closed. If the signature is invalid, the route should reject the request instead of logging the error and continuing.

The lesson:

A webhook endpoint can be public without being unauthenticated.

Reachability and trust are separate things.

Finding 4: External install identifiers are not authentication

One integration trusted a client supplied install identifier as if it were a credential.

That is dangerous.

Install IDs, instance IDs, account IDs, and external resource IDs are identifiers. They are not proof that the caller owns the installation.

The hardened approach was to require a signed provider token, verify it server side, and only then extract the canonical installation identity from the verified payload.

The corrected flow became:

Receive signed provider instance token
Verify the token using the provider app secret
Extract the canonical instance ID from the verified payload
Resolve the install record from that verified identity
Refuse cross organization rebinding unless ownership is proven

This fixed both the authentication issue and the related install rebinding risk.

The lesson:

Do not authenticate integrations with bare IDs.

Use provider signed assertions, server side verification, and explicit ownership rules.

Finding 5: User controlled URLs need SSRF protection

Several features across the two products involved server side requests to external URLs.

That pattern is common:

Outbound webhooks
RSS imports
Social integrations
Callback URLs
Remote media fetches
Health checks

The security risk is SSRF, or Server Side Request Forgery.

SSRF occurs when a user can influence a URL that the server requests. Without guardrails, an attacker may be able to point the server at internal infrastructure:

localhost
private network addresses
cloud metadata services
link local addresses
internal admin panels

The fix was to centralize outbound fetching through a safe fetch utility.

That utility blocks dangerous destinations, applies timeouts, restricts redirects, limits response size, and prevents internal response bodies from being reflected back to users.

The important part was centralization.

Instead of asking every route to remember SSRF rules, risky outbound requests now go through one safer path.

The lesson:

Any feature that lets a user provide a URL should be treated as a network boundary.

Finding 6: Cryptography should not have production fallbacks

Development conveniences can become production vulnerabilities if they are allowed to survive past local use.

The hardening pass removed weak secret fallbacks and hardcoded encryption key fallbacks. Token encryption was versioned, and a re encryption path was added so legacy stored values could be migrated safely.

The improved model included:

No hardcoded production fallback keys
Explicit application encryption key required
Versioned encrypted token format
Migration script for legacy tokens
Production flag to reject legacy plaintext tokens after migration

The lesson:

Cryptographic failure should be loud.

If the key is missing in production, the app should not quietly invent one.

Finding 7: File uploads should stay boring

File uploads are easy to underestimate.

For brand logos and media uploads, the safest approach was to restrict formats and improve storage behavior.

The hardening changes included:

Rejecting risky file types where they were unnecessary
Using high entropy media names
Enforcing body size limits
Handling chunked uploads safely
Avoiding active content in logo uploads

One practical example was SVG.

SVG can be useful, but it can also contain active content. If served from the wrong origin or with weak headers, it can become a stored XSS risk.

XSS means Cross Site Scripting. It occurs when attacker controlled content executes JavaScript in a trusted browser context.

For a logo upload feature, SVG was not worth the additional risk.

The lesson:

If a product only needs images, do not accept formats that behave like documents or code.

Finding 8: Security relevant configuration should fail closed

Some risks were not about code paths. They were about missing configuration.

Examples included:

Missing webhook secrets
Missing encryption keys
Missing CAPTCHA secrets
Missing Redis for rate limiting
Weak application secret keys
Insecure production cookie settings

The fix was to add production startup gates.

In development, flexible configuration is helpful.

In production, missing security configuration should stop the app from starting.

A startup gate turns a hidden runtime weakness into an obvious deployment failure.

The lesson:

Failing to boot is better than booting insecurely.

Finding 9: Rate limiting should not silently degrade

Rate limiting is often treated as a nice to have, but for authentication and abuse prevention it is a security control.

If Redis is unavailable and the system silently falls back to per process memory, limits become weaker under multiple workers.

For example, a limit of 10 attempts may effectively become 40 attempts across four workers.

The production behavior was hardened so that security sensitive rate limiting depends on a real shared backend.

The lesson:

A degraded security control should be visible, not silent.

Finding 10: Regression tests are part of the fix

Every meaningful finding received a named regression test.

That mattered.

A test named after a security issue tells future maintainers why the behavior exists. It also prevents a fix from being accidentally removed during a refactor.

Examples of the test coverage included:

Tenant data cannot be accessed across organizations
Platform scoped routes require platform staff
Unsigned webhooks are rejected
Invalid webhook signatures are rejected
Unsafe webhook URLs are rejected
SVG logo uploads are rejected
Weak production secrets fail startup
Legacy plaintext tokens can be rejected after migration

The lesson:

If a security issue was important enough to fix, it is important enough to test.

Finding 11: Static guards catch what tests miss

Tests are excellent for specific behavior.

Static lint is better for broad architectural patterns.

Both repositories now have security lint guards for risky patterns:

Tenant owned queries without organization scope
Raw outbound requests using user controlled URLs
State changing public routes without auth or signature classification
Global platform routes protected only by tenant roles

The linter supports a baseline, which is important for mature codebases.

A baseline allows known accepted cases to remain documented while CI fails only on new violations. That keeps the guard practical instead of noisy.

The preferred workflow is:

Fix the violation
Add a clearly marked exception only when intentional
Update the baseline only when the exception is reviewed and accepted

The lesson:

The best time to add a guard is right after fixing the bug class.

That is when the pattern is fresh, the risk is understood, and the team knows what should never happen again.

Finding 12: Some fixes require operational discipline

Not every security fix ends with a commit.

Some work has to happen during deployment:

Coordinate breaking integration changes
Set required production secrets
Run database migrations
Inspect quarantined records
Re encrypt stored tokens
Enable flags that reject legacy formats
Scrub sensitive files from Git history
Run full test suites before release

These steps were intentionally left as human controlled actions because they affect production data, integration behavior, and deployment timing.

That is part of responsible hardening.

The code can be ready before production is ready.

The lesson:

A remediation branch is not deployable until the operational checklist is complete.

What changed by the end

Across both products, the hardening pass produced:

24 total commits
More than 140 new regression tests
Database migrations
Centralized webhook verification
Centralized SSRF safe fetch behavior
Fail closed production startup gates
Platform staff authorization
Audit logging for sensitive actions
Versioned token encryption
Tenant isolation checks
Security lint guards enforced in CI
Main branches left untouched for review

More importantly, the products now have better security shape.

The fixes were not just scattered patches. They became reusable boundaries.

Tenant data access now has stronger conventions.

Platform operations now have a separate trust model.

Webhook verification now follows a consistent pattern.

Outbound URL fetching now has a safer path.

Production misconfiguration now fails early.

Dangerous patterns now have CI visibility.

Final takeaway

The most valuable security work is not only fixing what was found.

It is asking what the finding reveals about the system.

A good remediation process should answer:

What failed?
Where else could it fail?
What is the correct shared pattern?
How do we test the fix?
How do we prevent the class from returning?
What must be true before deployment?

That mindset turns a security report into a stronger codebase.

Patching closes issues.

Hardening changes the system.

Article written by, Joshua R. Gutierrez | CEO, Axion Deep Labs

ChatGPT Can't Render Your Site. Here's What Happens When You Ask it to Audit One Anyway.

Joshua Gutierrez — Tue, 26 May 2026 01:58:08 +0000

We wanted to know how reliable ChatGPT is as an SEO auditor, so we asked it to audit our own agency site, axiondeepdigital.com. Four prompts. Fresh thread. No setup, no priming. We then verified every concrete claim against
the actual page, against PageSpeed Insights, and against our own SEO workbench.

The audit came back at roughly 2,000 words. It included a numeric grade rubric ("Technical SEO 9/10, Architecture 8.8/10"), a prioritized fix list, named architectural risks, and an opinion on Googlebot rendering behavior. It looked like the kind of audit a senior SEO consultant might produce after a real review.

Most of it was confabulation dressed as analysis. One of its predictions was exactly backwards. And in the same thread, ChatGPT contradicted itself in a way neither it nor a casual reader would catch.

Here's the receipt for each prompt.

Prompt 1: The grade rubric was assigned without measurement

We asked: "Can you do a full technical SEO audit of [our URL]? I want specific issues, not a generic checklist."

ChatGPT returned an extensive audit with a grade rubric:

Technical SEO: 9/10
Architecture: 8.8/10
Content Depth: 6.8/10
Topical Authority: 6.5/10
Local SEO Structure: 8.5/10
Conversion SEO: 8.7/10

These numbers feel authoritative. They map to nothing measurable. Lighthouse outputs a Performance score and a separate SEO score. Search Console reports impressions, clicks, and CTR. None of these tools produce a "Technical SEO" or "Architecture" or "Conversion SEO" number. The grades exist nowhere in any real auditing tool. ChatGPT invented the rubric and assigned scores against it.

We then checked the factual claims. ChatGPT identified eight technology brands as "mentioned" on our homepage:

Vercel, Stripe, Netflix, Next.js, React, FastAPI, OpenAI, AWS

Of those eight, three (FastAPI, OpenAI, AWS) are not mentioned on our homepage at all. That is a 37.5% hallucination rate on a claim that takes less than a minute to verify in a browser.

Same pattern with the city pages it cited. It listed four geo pages by URL: /albuquerque, /las-cruces, /new-mexico, /web-development-new-mexico. The first two exist. The last two don't.

When ChatGPT mixes real observations with confabulated ones inside the same paragraph, the result is harder to catch than pure fabrication. A reader assumes the whole list was verified the same way.

Prompt 2: ChatGPT contradicted itself two messages later

We asked: "What are the current Core Web Vitals (LCP, CLS, INP) for [URL] on mobile? Give me the actual numbers."

ChatGPT replied:

I cannot reliably give you the real current field numbers for LCP, CLS, and INP from Google's CrUX dataset without direct access to PageSpeed Insights or the Chrome UX Report API for that URL. The web search environment here can access documentation and indexed pages, but it cannot execute a live Lighthouse/PageSpeed test against your domain or pull the live CrUX metrics feed.

This is correct. But ChatGPT had just spent 2,000 words in the previous message grading our site as if it had run Lighthouse against it. If it cannot execute a Lighthouse test, the grades in prompt 1 came from somewhere other than measurement. The two responses contradict each other inside the same conversation. ChatGPT did not flag the contradiction. A casual reader wouldn't either.

Then it guessed anyway:

I would expect CLS to already be very good, LCP to be decent but hero/media dependent, INP to likely be your weakest metric if third party scripts or animations are present.

We ran the actual Lighthouse mobile audit the same day. Lighthouse weights each Core Web Vital and reports a contribution out of a maximum. Here is the prediction next to the measurement:

Metric	ChatGPT predicted	Lighthouse measured (mobile)
CLS	"already very good"	+25 / 25 (perfect)
LCP	"decent but hero/media dependent"	+2 / 25 (lowest tier)
INP / TBT (interaction)	"likely your weakest metric"	+27 / 30 (one of our best)

CLS was a gimme. CLS is good on most modern sites and predicting that requires no information at all. LCP, the metric ChatGPT softened with "decent," scored 2 out of a possible 25 on mobile, which is the bottom tier Lighthouse reports. The metric ChatGPT confidently named as weakest scored 27 out of 30, the strongest of the three. The ranking was exactly inverted.

There is one more thing in this answer worth flagging. ChatGPT recommended PageSpeed Insights to retrieve the real CrUX field data. We checked. Our site does not have CrUX field data at all. Sites below Google's traffic threshold do not get field data, and the CrUX dataset returns "does not have sufficient real-world speed data" for our origin. A reader following ChatGPT's advice would arrive at PageSpeed, look for the field numbers ChatGPT promised, find nothing, and have no explanation for why.

Prompt 3: A confident render analysis without rendering anything

We asked: "Does Google see the same content on [URL] that a human visitor sees? Walk me through what Googlebot renders vs what the user renders."

ChatGPT delivered a careful, technically literate answer:

Based on the rendered structure, Googlebot is seeing substantially the same primary content that human users see on axiondeepdigital.com.

The phrase "based on the rendered structure" is doing all the work in that sentence. ChatGPT did not render anything. It cannot render anything. Its earlier message in this same conversation said so explicitly. The entire walkthrough of what Googlebot sees vs. what the user sees is pattern-matching on what a "modern Next.js site" typically does, not measurement of what our site actually does.

If we had a broken hydration path, if our hero was client-only, if our city pages were rendering empty divs to the bot, the answer would have looked identical. That is the worst possible failure mode for an auditing tool: confident output that is invariant to the actual state of the thing being audited.

Prompt 4: Three priorities that have nothing to do with the actual problem

We asked: "If I could only fix three things on [URL] this week to improve search rankings, what should they be and why those three?"

ChatGPT's answer: build a topical authority cluster, convert portfolio items into standalone case studies, improve internal semantic linking. Each recommendation came with an explanation that would apply word-for-word to any well-built Next.js agency site on the planet.

What the answer did not mention: our mobile Performance score is 69, our mobile LCP scores 2 out of 25, and Google has been weighting Core Web Vitals into ranking since 2021. A real "top three this week" list, given the data, starts with "fix mobile LCP." ChatGPT could not start there because it did not know.

It also credited us with "fast rendering stack using Next.js" as a strength in prompt 1. On mobile, our Performance score is 69 with LCP scoring 2 of a possible 25. Fast is generous.

The deeper problem

Our SEO category in Lighthouse scores 100. Best Practices is 100. Our own SEO workbench gives the site 96/100 overall. ChatGPT's gut call of "9/10 Technical SEO" is, by accident, close to the truth.

That is the trap.

ChatGPT arrived at a roughly correct grade not by measuring our site, but by pattern-matching what a well-built Next.js agency site usually looks like. We happen to be one. If we had been one of the 96.9% of small business sites our 292-site study found failing mobile Core Web Vitals, the audit would have read identically. Same grades. Same praise for "fast rendering stack." Same "your bottleneck is authority, not technical." Same generic top three.

You cannot use ChatGPT to find out whether your site is broken, because ChatGPT will tell you it is fine either way.

What to use instead

For SEO auditing, use tools that actually load your page in a real browser:

PageSpeed Insights: synthetic Lighthouse run, free, gives you real numbers.
Google Search Console URL Inspection: shows you the rendered HTML Google sees.
DeepAudit AI: our free real browser SEO audit, 100+ checks, full Chromium rendering. Built precisely because pattern-matching auditors lie. axiondeepdigital.com/free-seo-audit

ChatGPT is excellent at writing, summarizing, and explaining concepts. It is not an auditor. Asking it to audit a website is asking it to do a job it cannot do, and the danger is not that it refuses, but that it answers anyway.

Originally published on axiondeepdigital.com.

Why Most AI Writing Tools Quietly Fail

Joshua Gutierrez — Tue, 19 May 2026 22:44:50 +0000

I spent a session this week tearing apart one of our own systems, and the post-mortem turned into a thesis I keep coming back to:

Most AI writing tools are optimized for transformation, not preservation.

Our adapter looked correct on the surface. You write a post, click “Auto Adapt,” and out come Twitter, LinkedIn, and Threads versions. Short. Clean. Under the character limit. Technically successful.

Semantically wrong.

I noticed it when I fed the adapter a post about real before-and-after SEO scores from our portfolio. The original had four specific score deltas, three domain names, Core Web Vitals data, and a thesis about why HTML-parsing audit tools miss what real-browser ones catch. Evidence-heavy.

The adapter compressed all of it into:

"Every one jumped."
That line bothered me. Not because it was inaccurate. Because it erased the proof. The post still had the same shape (problem, explanation, CTA) but it no longer had the thing that made it persuasive.

The adapter was doing exactly what I’d asked it to do.

The optimization target was wrong
The engineering was fine: parallel async adaptation, platform-specific character limits, fallback truncation, taxonomy-aware prompting, safe failure behavior. All clean.

The prompt was the problem. It said:

"Rewrite this for Twitter."
Sounds harmless. Unpack what “rewrite” actually permits:

summarize
restructure
merge claims
drop specifics
abstract upward
replace evidence with implication
optimize for engagement over fidelity
The system was behaving correctly. The philosophy was wrong.

The shift
The whole architecture moved around one sentence:

The author’s wording, length, and specifics are correct unless they
violate a rule.

That sentence flips the model’s role. Most AI writing tools assume the model should act like the creator. But creators don’t want replacement. They want assistance with distribution friction: formatting, platform constraints, length caps, pacing, thread splitting.

Become a Medium member
The moment the AI starts “improving” the substance, trust collapses. Because now the creator has to audit the AI instead of using it.

What actually changed
The model became a copy editor, not a writer. The instruction shifted from “rewrite this post” to “make the smallest possible change necessary.” The model can fix formatting, remove forbidden phrases, adjust syntax, handle structural constraints. It is no longer authorized to rewrite hooks, invent framing, replace evidence, or compress meaning.

Preservation became enforced, not requested. Before the model runs, the system extracts protected facts: numbers, score deltas, URLs, domains, quoted text, structured evidence blocks, CTAs. After generation, a validator checks that those facts survived. If they didn’t, the output is rejected and the system falls back to deterministic trimming.

That distinction is the actual breakthrough. A prompt saying “please preserve the numbers” is not a guarantee. LLMs are not deterministic semantic compressors. They abstract naturally. So you don’t ask the model to preserve facts. You verify it afterward and reject when it didn’t.

The fallback became deterministic. Earlier versions had instructions like “drop the weakest sentence.” That sounds rigorous until you implement it. Weakest according to what? Without an explicit scoring policy, “deterministic fallback” is just another hidden heuristic.

The new fallback ranks sentences using weighted signals: protected fact presence, forbidden phrases, adjective density, duplication, position, CTA detection, sentence length. Same input, same scoring, same output. No hidden model mood swings.

What it looks like in practice
Three before/after pairs from the rebuild:

Original: “axiondeep.com 91→96, axiondeepdigital.com 94→96, made4founders.com 90→97. Mobile Core Web Vitals all in the Good range.”
Old adapter: “Every one jumped.”
New adapter: “axiondeep.com 91→96. axiondeepdigital.com 94→96. made4founders.com 90→97. All Mobile CWV: Good.”

Original: “We audited 292 small business websites. 96.9% failed Core Web Vitals on mobile.”
Old adapter: “Most websites are slow.”
New adapter: “Audited 292 small business sites. 96.9% failed mobile CWV.”

Original: “I’d actually like to hear it if the audit missed the mark for you.”
Old adapter: “Send feedback.”
New adapter: Unchanged. The line is short enough and structurally fine.

The third example is the point. Most posts need fewer changes than the model wants to make.

What I haven’t solved
The hardest case is the emotionally critical weak sentence. Example:

"My dad would've loved this."
There is no deterministic rule that recognizes why that sentence matters. An LLM cannot reliably infer it either. Structurally it’s removable. Compression-friendly. Emotionally, it might carry the entire post.

I did not find a clean answer. The system flags short sentences as candidates for removal but errs toward keeping anything that doesn’t match a forbidden pattern. The cost is occasionally bloated drafts. The benefit is never silently destroying the line that mattered most.

That was the trade I was willing to make. Engineering systems become dangerous when they pretend uncertainty doesn’t exist.

The real product was the feedback loop
The most strategic decision wasn’t in the adapter at all. It was capturing final_published_text after the user edits and posts.

That single field turns the adapter from a static feature into a measurable editorial system. We can now observe what users reverted, what they preserved, where they distrusted the AI, how aggressively they edited, which transformations survived. Most AI writing tools optimize against assumptions. This one will optimize against observed correction behavior.

The telemetry probably matters more than the adapter itself.

If you’re building anything in the AI writing space and you’ve fought the same problem, I’d genuinely like to compare notes. The hard part isn’t the model. It’s deciding what the model is allowed to optimize for.

— Joshua R. Gutierrez

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

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

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

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

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

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

Key stats (copy-paste friendly)

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

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

How we measured

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

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

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

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

What this study does and does not prove

Before the numbers, the honest scope:

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

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

Finding 1: LCP is the silent killer

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

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

What is causing it, in order of frequency:

1. Hero images served as full-resolution PNG

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

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

import Image from 'next/image';

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

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

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

2. Render-blocking JavaScript in the head

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

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

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

Or on Next.js:

import Script from 'next/script';

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

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

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

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

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

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

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

72.4% of sites post poor mobile FCP.

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

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

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

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

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

Finding 3: 100% of sites failed Link Labels

This is the number that should bother you most.

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

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

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

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

The fix is one attribute:

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

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

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

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

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

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

Three lines. You now pass axe-core.

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

85.5% of sites pass mobile CLS.

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

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

The takeaways for developers

If you read nothing else from this, read this:

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

The dataset

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

Report: State of Small Business Websites 2026

Suggested citation:

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

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

The takeaway, in one sentence

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

That is what the 3.1% do.

Your Website Exists. AI Doesn't Know That.

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

Someone just asked ChatGPT for a recommendation in your industry.

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

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

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

The Problem No One Is Talking About

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

AI assistants don't do that.

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

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

The Fix: One File, 10 Minutes

The solution is called llms.txt.

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

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

The standard defines two files:

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

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

What Goes In Each File

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

llms.txt -- Keep It Tight

# Your Business Name

> What you do, in one sentence.

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

## Services

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

## Free Tools

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

## Areas Served

- City, State (headquarters)
- City, State

## Contact

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

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

llms-full.txt -- Go Deep

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

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

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

Implementation

Next.js / Static Sites

Drop both files in /public:

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

Served automatically. Done.

WordPress

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

Optional: Reference in robots.txt

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

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

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

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

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

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

How to Know It's Working

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

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

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

The Bigger Picture

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

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

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

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

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

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

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

What a 98 Lighthouse Score Actually Takes

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

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

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

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

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

Here is what that actually required.

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

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

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

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

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

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

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

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

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

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

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

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

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

One Button Too Many

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

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

Google. GitHub. LinkedIn. X. Facebook.

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

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

That is when things got interesting.

What We Build

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

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

Simple idea. Should be straightforward.

We also let users sign in with X.

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

What Went Wrong

Here is the problem.

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

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

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

So it silently reconnects the personal account.

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

Not ideal.

The “Fixes” That Did Not Work

We tried to patch it.

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

It did not help.

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

The only workaround was telling users to:

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

We actually wrote that into a tooltip.

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

The Question We Should Have Asked Earlier

We stopped debugging and checked our data.

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

Zero.

Not low. Zero.

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

Nobody used X.

So we had been maintaining:

OAuth flows
Token refresh logic
API credentials
Debugging time

For a feature nobody used.

The Fix Took 10 Minutes

We deleted the button.

Removed the frontend component. Cleaned up the API call.

About 20 to 30 lines of code.

Then we separated our X apps:

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

Same pattern we already used for LinkedIn.

Immediately, everything worked.

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

What We Actually Learned

This was not really about X.

It was about a common engineering habit.

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

Each OAuth provider feels cheap to add.

Just another button. Another callback. Another env variable.

But they are not free.

Each one adds:

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

And sometimes, they conflict with other features.

The Real Cost of “Just One More Option”

We spent hours debugging X.

Token issues
Session conflicts
API limitations
OAuth redirect loops

X has also become harder to work with:

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

All of that for a login button nobody clicked.

The Broader Point

Every feature has a maintenance cost.

Not just code.

Debugging time
Support tickets
Mental overhead
Edge cases

OAuth is especially messy.

Every provider behaves differently:

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

There is no standard. Only variations.

Our Rule Now

Before adding a login option, we ask one question:

Would our target user actually sign up this way?

For founders using a business tool:

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

X and Facebook do not.

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

If You Are Building Something Similar

A few things we learned the hard way.

1. Do not mix login and integration OAuth

Session conflicts are real and you cannot control them.

2. Separate your developer apps

Authentication and integrations should not share the same setup.

3. Test with multiple accounts

Most bugs only appear in real world usage patterns.

4. Remove what is not earning its place

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

The Result

Four login buttons.

No conflicts.

No late night debugging sessions over something nobody uses.

Sometimes the best feature you can ship is a deletion.

Closing

We are building Made4Founders.

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

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

We are trying to make it simpler.

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

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

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

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

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

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

So I wrote them down.

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

Here is what we found.

The Numbers

Out of 61 websites:

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

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

The 7 Most Common Problems

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

1. HTML Validation Errors (43%)

This was the most common issue by far.

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

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

2. Missing or Broken H1 (40%)

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

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

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

3. Accessibility and Form Issues (26%)

This one stood out.

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

Beyond usability, this is a compliance risk.

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

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

4. No Sitemap.xml (23%)

Almost a quarter of sites had no sitemap.

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

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

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

5. Missing Meta Description (21%)

One in five sites had no meta description.

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

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

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

6. No Structured Data (19%)

Structured data tells search engines what your business actually is.

Name. Services. Location. Reviews. Hours.

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

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

7. Broken Internal Links (17%)

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

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

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

The Pattern Nobody Talks About

These problems do not show up alone. They stack.

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

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

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

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

What This Means for Your Business

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

The fixes themselves are not hard.

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

The hard part is knowing what is broken.

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

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

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

Either way, you should know.

Joshua R. Gutierrez, M.S.

CEO, Axion Deep Labs

Founder, Axion Deep Digital

We Built 3 Websites. None of Them Ranked.

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

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

1. Our Entire Website Was Invisible to Google

This one still hurts.

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

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

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

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

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

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

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

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

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

3. We Had Five H1 Tags on One Page

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

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

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

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

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

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

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

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

5. Client Components Killed Our Server-Rendered Content

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

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

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

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

6. Our Privacy Page Had the Wrong Analytics ID

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

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

7. Our Sitemap Had Wrong Dates

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

8. 78 Images With Zero Metadata

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

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

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

9. Our Old Brand Name Was Still in Five Places

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

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

The 4 Things That Actually Matter

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

Crawlability

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

Rendered Content

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

Data Accuracy

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

Structure

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

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

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

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

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

Try DeepAudit AI Free →

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

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

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

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

Why We Built It

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

The problems:

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

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

What We Found Scanning 500+ Sites

78% have broken or missing meta descriptions

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

65% fail basic accessibility checks

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

71% have no structured data

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

Average Lighthouse performance score: 44

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

83% missing at least one security header

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

Only 12% have proper internal linking

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

The Tech Stack

For anyone curious about how we built it:

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

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

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

The 7 Categories We Score

Each site gets a weighted score across:

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

Final score: 0-100 with a letter grade.

What Makes It Different

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

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

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

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

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

Try It

DeepAudit AI — Free AI SEO Audit Tool

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

DEV Community: Joshua Gutierrez

Turning an SEO Audit Into a Revenue Strategy

Most SEO work starts with a checklist.

The Starting Problem

What the Traffic Data Changed

The Real SEO Lesson

Rebuilding the Offer Strategy

Turning the Audit Result Into a Sales Page

Fixing the Call to Action Problem

Why Measurement Had to Come First

The Final Strategy

What This Project Demonstrates

Hardening Two Multi Tenant SaaS APIs

What We Found, What We Fixed, and What Changed

The goal was not just to close findings

Finding 1: Tenant data must always be scoped by tenant

Finding 2: Organization admins are not platform admins

Finding 3: Public webhooks are public, not trusted

Finding 4: External install identifiers are not authentication

Finding 5: User controlled URLs need SSRF protection

Finding 6: Cryptography should not have production fallbacks

Finding 7: File uploads should stay boring

Finding 8: Security relevant configuration should fail closed

Finding 9: Rate limiting should not silently degrade

Finding 10: Regression tests are part of the fix

Finding 11: Static guards catch what tests miss

Finding 12: Some fixes require operational discipline

What changed by the end

Final takeaway

ChatGPT Can't Render Your Site. Here's What Happens When You Ask it to Audit One Anyway.

Prompt 1: The grade rubric was assigned without measurement

Prompt 2: ChatGPT contradicted itself two messages later

Prompt 3: A confident render analysis without rendering anything

Prompt 4: Three priorities that have nothing to do with the actual problem

The deeper problem

What to use instead

Why Most AI Writing Tools Quietly Fail

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

Key stats (copy-paste friendly)

How we measured

What this study does and does not prove

Finding 1: LCP is the silent killer

1. Hero images served as full-resolution PNG

2. Render-blocking JavaScript in the head

3. Custom fonts with no font-display directive

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

Finding 3: 100% of sites failed Link Labels

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

The takeaways for developers

The dataset

The takeaway, in one sentence

Further reading

Your Website Exists. AI Doesn't Know That.

The Problem No One Is Talking About

The Fix: One File, 10 Minutes

What Goes In Each File

llms.txt -- Keep It Tight

llms-full.txt -- Go Deep

Implementation

Next.js / Static Sites

WordPress

Optional: Reference in robots.txt

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

How to Know It's Working

The Bigger Picture

What a 98 Lighthouse Score Actually Takes

One Button Too Many

What We Build

What Went Wrong

The “Fixes” That Did Not Work

The Question We Should Have Asked Earlier

The Fix Took 10 Minutes

What We Actually Learned

The Real Cost of “Just One More Option”

The Broader Point

Our Rule Now

If You Are Building Something Similar

1. Do not mix login and integration OAuth

2. Separate your developer apps

3. Test with multiple accounts

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