DEV Community: Joshua Gutierrez

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.