DEV Community: JAIMIN UMARANIYA

AI SEO Checklist 2026 By Jaimin Umaraniya

JAIMIN UMARANIYA — Mon, 10 Aug 2026 12:24:46 +0000

My Portfolio Failed Google’s AI-Readiness Test — Here’s the Checklist I Built to Fix It
I run a full-stack and AI developer portfolio. It has clean metadata, Open Graph tags, verified Google Search Console and Bing Webmaster Tools accounts, optimized images, and a solid technical foundation. On paper, it looked like a well-optimized website.

Then I decided to look at it from a different perspective.

Instead of viewing it as a visitor, I fetched my own blog page the same way a crawler or an AI search engine might — without executing JavaScript.

The result surprised me.

The page title was there. The meta description loaded correctly. The navigation appeared as expected.

But under “Technical Blog & Articles,” there were no blog posts.

No article titles.

No publication dates.

No content.

Just a placeholder telling users that JavaScript was required to render the page.

Every article I’d written was invisible to anything that relied on the raw HTML response. That includes many AI crawlers, social preview bots, and, depending on how they retrieve information, some of the systems powering AI experiences like ChatGPT, Gemini, and Perplexity.

That realization completely changed how I think about modern SEO.

This isn’t about adding another keyword or installing an llms.txt file.

It’s about making sure your content can actually be discovered, understood, and referenced by the systems that increasingly sit between your website and your audience.

Traditional SEO Still Matters, But It Isn’t the Whole Story
Google has made it clear that there isn’t a separate “AI ranking algorithm.” The same fundamentals that help websites succeed in traditional search crawlability, helpful content, structured information, and technical qualityalso support visibility in AI-powered search experiences.

What has changed is how information is consumed.

Traditional search usually follows a simple path:

Rank → Show a link → User clicks

AI-powered search works differently:

Retrieve → Compare trusted sources → Generate an answer → Cite sources (sometimes) → User may never visit the website

That changes the goal.

Instead of optimizing only for rankings, developers now need to think about retrieval, clarity, and machine-readable content.

If an AI system can’t understand your page, it can’t reference it.

How AI Search Retrieves Information
Most modern AI search systems follow a retrieval-based workflow.

A user asks a question.

The AI expands that question into multiple related searches, looks for reliable sources, compares information across several pages, and then generates a response.

The process looks something like this:

User Question
↓
Query Expansion
↓
Search Index
↓
Retrieve Trusted Sources
↓
Evaluate Authority
↓
Generate Response
↓
Citations
Two questions determine whether your content has a chance of appearing:

Can the system access your content?
Is the content structured well enough to understand?
My portfolio failed the first question.

Everything else became irrelevant.

The Problems I Found on My Own Website
Instead of theoretical advice, here’s what I actually discovered while auditing my portfolio.

Blog content wasn’t available without JavaScript The articles only appeared after the application hydrated in the browser.

For human visitors that wasn’t a problem.

For crawlers relying on the initial HTML response, the blog effectively didn’t exist.

Missing Article Schema Each blog post lacked structured data such as:

Article
Blog Posting
Without these signals, search engines have to infer what the page represents instead of being told directly.

Missing Person & Organization Schema Although my name appeared throughout the site, there was no structured connection between:

Jaimin Umaraniya
Portfolio
LinkedIn
GitHub
Technical expertise
Those relationships matter when building entity authority.

Weak Trust Signals Individual articles didn’t include:

Author information
Published date
Last updated date
Small details like these improve both user trust and machine understanding.

Poor Internal Linking Each article existed on its own.

There were very few connections between blog posts, projects, or case studies.

Write on Medium
A knowledge base should behave like a network, not a collection of isolated pages.

My AI SEO Checklist for 2026
After reviewing my own website, I created a practical checklist that I’m implementing across every page.

Rendering & Crawlability
Server-side rendering (SSR) or Static Site Generation (SSG)
Verify content appears in raw HTML
Submit XML Sitemap
Configure robots.txt correctly
Add canonical URLs
Ensure pages return proper HTTP status codes
Structured Data
Article Schema
Blog Posting Schema
Person Schema
Organization Schema
Breadcrumb Schema
FAQ Schema
Software-Application Schema (for projects)
Content Quality
Every article should include:

A clear answer near the beginning
Real examples
Original screenshots
Code snippets where relevant
Logical heading hierarchy
Practical takeaways
Entity SEO
Maintain consistency across your website and profiles:

Full name
Professional title
Portfolio
LinkedIn
GitHub
Technology stack
Consistency helps search engines understand who you are and what topics you’re associated with.

Internal Linking
Every article should connect to:

Related blog posts
Relevant project case studies
Documentation
Tutorials
Resource pages
Good internal linking helps both readers and crawlers navigate your content.

Image Optimization
Every image should have:

Descriptive filenames
Meaningful alt text
Responsive formats
Proper compression
Open Graph compatibility
What Agentic Browsers Look For
AI-powered browsers and autonomous agents don’t simply index pages.

They evaluate them.

When visiting a website, they often look for answers to questions like:

Can this page answer the user’s question immediately?
Is the information current?
Is the author clearly identified?
Are claims supported by evidence?
Can I navigate to related information?
If your website behaves like a well-organized knowledge base, AI systems can understand it much more effectively.

Three AI SEO Myths Worth Ignoring
Myth 1: Adding an llms.txt file guarantees AI visibility
It may help certain tools discover your website, but it won’t fix poor content, weak structure, or missing crawlability.

Myth 2: Publishing hundreds of AI-generated articles builds authority
Quantity rarely beats originality.

A handful of well-researched articles with practical examples will almost always outperform dozens of generic posts.

Myth 3: Keyword density is still the most important ranking factor
Modern search focuses much more on understanding, context, and quality than simple keyword repetition.

Write naturally.

Structure your content well.

Solve real problems.

My 90-Day Improvement Plan
Here’s the roadmap I’m following for my own portfolio.

Weeks 1–2
Move blog pages to SSR or SSG
Verify content appears in raw HTML
Weeks 3–4
Add structured data
Generate a dynamic sitemap
Improve metadata
Weeks 5–6
Add author profiles
Improve internal linking
Add publication dates
Weeks 7–8
Rewrite older articles with better examples
Add diagrams and code samples
Weeks 9–12
Monitor Google Search Console
Track indexing improvements
Continue publishing high-quality technical content
Final Thoughts
Building an AI-ready website isn’t about chasing another ranking factor.

It’s about creating a website that’s easy to understand — for both people and machines.

If your content can’t be accessed, structured, and trusted, it becomes much harder for search engines and AI systems to surface it, regardless of how well it’s written.

Traditional SEO is still the foundation.

The difference today is that your website also needs to be readable, connected, and structured for the next generation of search.

About the Author
I’m Jaimin Umaraniya, a Full-Stack Developer focused on building modern web applications with React, Next.js, AI-powered SaaS, Technical SEO, and performance-first architecture.

Through my technical articles and real-world case studies, I share practical insights on software engineering, frontend architecture, modern SEO, and building products that are both user-friendly and search-friendly.

If you’d like to explore more of my work, visit my portfolio:

🌐 Portfolio: https://portfoliojaimin.netlify.app

💼 LinkedIn: https://linkedin.com/in/jaimin2106

If you’ve audited your own website and discovered similar issues — or found something completely different — I’d genuinely enjoy hearing about your experience. Technical discussions like these help all of us build better products.

The Complete Technical SEO Guide for React Applications (2026)

JAIMIN UMARANIYA — Thu, 30 Jul 2026 12:14:23 +0000

Technical SEO Guide for React Apps (2026) By Jaimin-Umaraniya

Is React good for SEO? Yes—but only if you handle rendering, metadata, and performance correctly.

Installing Next.js doesn't fix your SEO by itself. It just hands you more rendering options to choose from, and you still have to choose the right one. I've audited a fair number of React apps at this point, and the pattern repeats: strong product code, but almost no attention paid to what Googlebot actually sees during and after JavaScript execution.

Fix that gap, and rankings usually follow.

Why Technical SEO Matters for React

Technical SEO isn't about stuffing keywords into a page. It's about making your app easy to crawl, render, and understand.

Get it right and you get faster load times, better Core Web Vitals scores, pages that actually get indexed, and rich results through structured data. Get it wrong, and Google either can't see your content or decides it isn't worth ranking.

How Google Actually Crawls a React App

Google runs a headless version of Chromium to render JavaScript before indexing anything. The sequence looks like this:

Fetch: Googlebot fetches the initial HTML.
Queue: The page gets queued for rendering.
Execute: Chromium downloads and executes your JS.
Parse: The rendered DOM gets parsed for content and links.
Index: Content and links go into the index.

The Rendering Bottleneck: Step 2 is where most developers get burned. If your JS execution is slow or your content depends on client-side data fetching, indexing can lag by days. This is exactly why frameworks like Next.js, Remix, and Astro support server-side rendering (SSR) and static site generation (SSG)—they get real content into the first HTML response instead of making Google wait for a JS round trip.

7 Practices That Actually Move the Needle

1. Metadata Per Page, Not Per App

Every route needs its own title, meta description, canonical tag, and Open Graph tags. A single static title tag that never changes is one of the most common React SEO mistakes out there.

2. Core Web Vitals

Google uses LCP, INP, and CLS as ranking signals. For React specifically:

Code-split by route, not just by vendor bundle.
Lazy-load below-the-fold images and components.
Prevent layout shift by watching font loading and reserving space for ad slots.
Monitor JS bundle size, since large client bundles hurt Interaction to Next Paint (INP) more than almost anything else.

3. Structured Data

Add JSON-LD for Organization, Article, FAQ, Breadcrumb, or SoftwareApplication schema depending on the page. It won't guarantee a rich result, but it removes ambiguity for the crawler.

4. Clean URL Structure

Keep URLs readable and stable (e.g., /blog/react-seo-guide or /projects/seo-hub-analyzer). Avoid query-string-heavy or ID-based URLs for content pages—they're harder to link to and harder for anyone to remember.

5. Sitemap and Robots.txt

Generate your sitemap at build time so it stays in sync with your real routes. Double-check that your robots.txt isn't accidentally blocking your JS or CSS directories. This happens more often than you'd expect, and it quietly breaks rendering.

6. Image Optimization

Use descriptive filenames and real alt text, not image1.jpg. Compress aggressively and serve WebP or AVIF formats with a standard JPEG fallback.

7. Strategic Internal Linking

Link related content on purpose: blog posts to project pages, guides to docs, one article to the next in a series. This is still one of the highest-leverage, lowest-effort SEO tasks available.

Mistakes I See Most Often

Generic titles: One title tag reused across every page.
Client-side only: Content that only renders after a client-side fetch, with no SSR fallback.
Blocked assets: JS or CSS unintentionally blocked in robots.txt.
Missing canonicals: Paginated or filtered views left to compete with each other in search.
Lazy alt text: Alt tags left empty or filled with the raw filename.

Pre-Deploy Checklist

Before you ship your next major update, ensure these are ticked off:

[ ] Unique title and meta description per page.
[ ] Canonical URLs set.
[ ] Sitemap generated and submitted to Search Console.
[ ] robots.txt reviewed (JS and CSS not blocked).
[ ] Structured data (JSON-LD) added where relevant.
[ ] Images compressed and properly described.
[ ] Internal links established between related pages.
[ ] Mobile layout tested and responsive.
[ ] Core Web Vitals checked in Page Speed Insights.
[ ] HTTPS enforced.

Closing Thought

None of this is exotic. Most of it is basic hygiene that gets skipped because it's not on the "ship the feature" checklist.

If I had to fix one thing first on a typical React app, it would be the rendering strategy. Get your content into the initial HTML response, and everything else gets easier from there.

Written by Jaimin Umaraniya

Full-stack developer and technical SEO consultant, working on React, Next.js, Firebase, and AI-powered SaaS products.

Portfolio: https://portfoliojaimin.netlify.app
LinkedIn: https://linkedin.com/in/jaimin2106

Run into a React SEO problem this doesn't cover? I'd like to hear about it.

Why Your Developer Portfolio Should Work Like a Product, Not a Resume

JAIMIN UMARANIYA — Mon, 27 Jul 2026 10:15:57 +0000

When I built my first portfolio, I did what most developers do. Hero section, tech stack, a handful of projects, a contact form. Clean, but forgettable.

The more portfolios I looked at, the more they started to blur together. Different colors, different fonts, same experience.

So I stopped asking "how do I showcase my skills" and started asking something better: how do I build something people actually enjoy exploring?

That question changed how I think about the whole thing. I don't treat my portfolio as a website anymore. I treat it as a product, something that ships, gets used, and gets a little better every month.

The mistake most developers make

A portfolio isn't just another project. It's how someone decides, in about ninety seconds, whether to trust you with real work.

Most developers spend weeks on the app and an afternoon on the site that's supposed to sell it. That gap shows up as generic project descriptions, no real engineering detail, a mobile experience nobody tested, slow load times, and nothing that gives a visitor a reason to come back.

A recruiter or client usually makes up their mind within a couple of minutes. If your portfolio doesn't tell them who you are and what you've built by then, you've already lost the moment.

Treat it like a product, not a resume

Every product answers three questions: who is it for, what problem does it solve, and how does it get better over time. Your portfolio should answer the same ones.

A recruiter wants to know if you can build production-ready software. A client wants to know if they can trust you with their business. Another developer just wants to learn something from what you built.

Once your portfolio starts answering those questions, it stops being a personal website and turns into something people actually spend time on.

Build features, not just pages

Products succeed because every feature earns its place, not because there are more of them. A few things I think belong on any developer portfolio right now:

Real case studies, not tech lists. "Built with React, Node, and Firebase" tells nobody anything. What's worked better for me: why I built the project, what problem it solved, the architecture calls I made, what broke, and what I'd change if I rebuilt it today. People remember stories, not stacks.

A blog. Writing has done more for my career than I expected going in. Every post forces me to turn a half-formed idea into something coherent, and a few posts have brought in more traffic than any project page on the site. A blog is the difference between a static showcase and something that's actually alive.

Speed, treated as a feature. Nobody notices a fast site. Everybody notices a slow one. Core Web Vitals, image loading, bundle size, fonts, caching, all of it adds up to whether someone sticks around past the first few seconds.

Mobile, tested first, not last. Test your portfolio on a phone before you test it anywhere else. A lot of developer portfolios still look like they were designed for a 27-inch monitor and never opened on anything smaller.

Technical SEO. Semantic HTML, proper metadata, Open Graph images, a sitemap, internal links. None of it is glamorous, but none of your work matters if nobody finds it.

Actual data. Which projects get attention, where people drop off, which posts perform, what gets clicked. I didn't start tracking any of this until about a year in, and I regret waiting that long.

Keep shipping

A resume gets touched when you're job hunting. A portfolio, if you're doing it right, gets touched constantly. Every project, every post, every small fix should leave it a little better than it was last month.

What actually changed my thinking

It wasn't a design trick or a framework choice. It was one question I started asking before adding anything new: does this solve a real problem for the person looking at it, or am I only adding it because portfolios are "supposed to" have it?

That single question cut a lot of noise out of my own site.

The short version

Nobody's comparing your portfolio to other portfolios. They're comparing it to everything else competing for their attention that day, a resume, a LinkedIn scroll, another tab. A portfolio that shows how you think beats one that just lists what you've shipped, most days.

If you're rebuilding yours this year, build it like something you'd actually want to use, not something you're required to have.

About me

I'm Jaimin Umaraniya, a full-stack developer. I write about the parts of building software that don't usually make it into the readme: portfolios, React, technical SEO, and the small decisions that add up to a product people actually want to use.

Portfolio: portfoliojaimin.netlify.app · LinkedIn

If any of this resonated, or you think I'm wrong about parts of it, I'd like to hear it.