DEV Community: Pratik Goswami

I Read Google’s Official AI Search Guide So You Don’t Have To. Here’s What Actually Matters

Pratik Goswami — Fri, 22 May 2026 09:28:31 +0000

Google just wrapped up its Google I/O 2026 and after spending some time going through all of Google's official documentation on Search Agents, I decided to create a one-stop guide to things I took away from all the information. While I originally posted on Medium, I wanted to share it here as well because the Dev.to community tends to care more about these stuff.

Agentic Search Optimization, Answer Engine Optimization, Generative Engine Optimization - the terminology changes depending on who you follow, but the panic underneath it is the same: Google has changed, agents are reading your site, and if you are not optimizing for it, you are invisible.

So developers have been doing what developers do. They are adding llms.txt files. They are "chunking" their content. They are rewriting copy specifically for AI models. Some are even paying for tools that promise to get their site cited by ChatGPT.

Here is the thing. Google just published an official guide on how to optimize your website for generative AI features on Google Search. I read it cover to cover. Most of what the internet is selling you isn’t what search engines are looking for. This article highlights what can actually boost your visibility to such agents.

First, a Quick Recap on Why This Matters

If you read my previous article, Your Portfolio Is Invisible. Here’s How I Fixed Mine, feel free to skip this section as you already know the core idea. Your site has two types of readers: humans and machines. And increasingly, it is the machines that decide whether the humans ever find you.

SEO (Search Engine Optimization) is about helping crawlers like Googlebot index and rank your content so people find you in search results.

AEO (Answer Engine Optimization) is about helping AI systems form an accurate and confident understanding of your site, so they can surface it when someone asks a relevant question.

The difference matters more now than it did a year ago. Google is actively building Search Agents. These are autonomous systems that can perform tasks on behalf of users. Whether it be booking a reservation, comparing products or researching services; to do any of that, the agent first has to read, understand, and trust your site. If it cannot do that, it will not recommend you and that is the whole problem.

What Google Actually Says

Google has created a guide titled Optimizing your website for generative AI features on Google Search. It is the official position from Google Search Central and it serves as a guide to optimize a website for the new Search Agents.

From Google’s perspective, optimizing for generative AI search is optimizing for the search experience, and thus still SEO.

It means the same foundational principles that have always made a site rank well - original content, clean structure and good performance - are still what matter. The difference is in how those principles are applied in a world where an AI model is summarizing your page rather than a user clicking through to read it.

Part 1: What Actually Moves the Needle

1. Non-Commodity Content

This is the section that gets the most emphasis in the Google guide and the least attention in most AEO tutorials.

Google uses the phrase “valuable, non-commodity content” and it is worth understanding what they mean.

Commodity content is a summary of information that already exists. It answers a question accurately, but it could have been written by anyone or generated by an AI model. The content has neither a point of view nor a first-hand experience. It does not tell you something you could not find in the first five results for the same query.

Non-commodity content is the opposite. It can include a first-hand review, case study with real numbers or an expert take that reflects genuine experience in the field. Something that provides a unique viewpoint.

Here is the uncomfortable truth. The content most developers are cranking out to “rank for AI” is precisely what AI models are trained to ignore. If you are writing blog posts that restate what the documentation already says, you are producing commodity content. The irony is that the shortcut most people reach for, using AI to generate more content faster, tends to produce the exact type of content that generative AI systems are trained to look past.

Your perspective is the signal. The depth you bring from actually having built, shipped, and debugged something, is what makes your content worth citing.

2. Clear Technical Structure

This part will be familiar if you read the SEO article, but the reasoning has a new layer to it now.

Google’s AI systems use the same underlying infrastructure as traditional search. That means the same technical requirements apply. A page has to be indexed and eligible to appear in Google Search before it can appear in AI Overviews or be used by a Search Agent.

The checklist looks like this.

Semantic HTML. This is still the highest-leverage change most developers can make. When your markup uses <article>, <section>, <nav>, <h1> through <h3>, and <main> correctly, a crawler reads your page like an outline. Without them, it reads a flat document and has to guess what matters. The Google guide specifically notes that while perfectly semantic HTML is not required, it is generally a good idea because it helps multiple types of users, including AI systems that parse and navigate your page structure.

Crawlable content. If your content only renders after a user interaction, a state toggle, a tab click, or a modal open, it effectively does not exist to a crawler. Googlebot crawls the initial DOM, not the post-interaction state. Audit your site for content that is conditionally rendered and refactor it so the important information is present in the initial HTML.

Sitemap and robots hygiene. A sitemap provides a guide to the crawlers about every page on your site so nothing gets missed. A robots file tells crawlers which pages they are and are not allowed to visit. Both are small files that have an outsized impact.

Good page experience. Google’s guide explicitly links page experience as an AI search signal. Thus, Core Web Vitals like LCP (Largest Contentful Paint), which measures how long it takes for the largest visible element to load, has a major impact. A slow site is not just a UX problem, it is a visibility problem.

3. Structured Data (The Right Way to Think About It)

There is a nuance here that most articles miss. While structured data is not required for generative AI search, it is still a good idea to use it responsibly as it is a part of improving the overall SEO strategy. In other words there is no special schema.org that can give you an edge with AI search, but it does help with being eligible for rich results on Google Search.

Generative AI search is built on top of the same index as traditional search. A site that is well-optimized for rich results tends to also be better represented in AI responses. Structured data gives crawlers explicit, machine-readable facts about your content rather than making them infer those facts from your prose.

A Person schema on a portfolio tells Google your name, your role, your employer, and your social profiles in one structured block. A Product schema on an e-commerce page gives price, availability, and reviews in a format that leaves nothing to interpretation.

For a personal site, the most useful schemas are Person, WebSite, and SoftwareApplication if you are showcasing projects. For a commercial site, focus on Organization, Product, FAQPage, and LocalBusiness if applicable.

The goal is not to stuff your page with schema, rather to shine the spotlight on your most important facts.

Part 2: The Myths Worth Dropping

I want to go through it because these myths are widespread, and I believe acting on them is a waste of time at best, counterproductive at worst.

llms.txt is not a signal

This has been circulating as the hot new AEO tactic. The idea is that you create a machine-readable file at your domain root describing your site for LLMs, similar to how robots.txt works for crawlers. Google’s guide is clear to highlight that you do not need to create llms.txt or any other "special" markup for AI. While they will be crawled and indexed, they don’t provide any advantage to improving visibility.

Chunking content does not help

The theory is that breaking your pages into smaller pieces helps AI systems process them more easily. Google explicitly highlights this as a myth, as their systems can handle multiple topics on a single page and surface the relevant piece to users. There is no ideal page length for generative AI search. So make pages for your audience, not for the AI.

You do not need to write for AI keywords

AI systems can understand synonyms. They understand the general meaning of a query and match it to relevant content even when the phrasing does not match. You do not need to worry about capturing every variation of how someone might search for your topic.

Seeking inauthentic “mentions” does not work

Some tools and guides push you to get your brand mentioned in blog posts, forums, and discussion threads across the web, with the reasoning that it will help AI systems associate your brand positively.

Google addresses this directly. Their core ranking systems focus on high-quality content while others focus on blocking spam. Their generative AI feature depends on both. Thus, pushing for bulk mentions may be harming visibility instead of boosting it.

Part 3: The Part Most Guides Are Not Writing About Yet

AI agents are autonomous systems that can perform tasks on behalf of users - not just answer questions, but take actions. A browser agent, for example, can visit your website, analyze visual renderings (like screenshots), inspect the DOM structure, and interpret the accessibility tree, all to gather the information before reporting back to the user.

Google’s agent-friendly guidelines come down to one principle: if an agent cannot see it clearly and click it confidently, it will skip it.

Google links to a separate guide on agent-friendly website best practices. Although it is worth reading alongside this, here is a summary of the best practices:

Use <button> and <a> tags for interactive elements. If you must use a <div>, give it role="button" and a tabindex. Agents are trained to recognize semantic HTML as actionable.
Set cursor: pointer in CSS on clickable elements. This is treated as an explicit actionability signal.
Keep your layout stable. Agents that take screenshots get confused by elements that shift position across pages, like a cart button that appears in a different location per product category.
Always link <label> tags to their inputs using the for attribute. This tells the agent what a form field is actually for.
Make sure interactive elements are larger than 8 square pixels. Visual analysis filters out anything smaller, so a tiny button effectively does not exist to an agent.
Remove transparent overlays and ghost elements. If a layer covers an interactive element, even a fully transparent one, the agent may discard the node underneath it entirely.

Additionally, the Universal Commerce Protocol (UCP) is emerging as a standard that will allow Search Agents to do significantly more on commercial sites. If you run an e-commerce site or any site where a user might want to complete a transaction, this is something to track.

This is not something you need to act on today. But it is the direction things are heading, and being aware of it now means you are not late to the party.

The Summary: What to Actually Do

The foundation has not changed.

Build a site that is technically clean, fast, crawlable, and can be indexed.
Create content that has a real point of view and provides something a generic summary cannot.
Make your most important facts explicit through structured data.

References

Part I: Don't Wait for Data. Render What You Know.

Pratik Goswami — Tue, 19 May 2026 02:30:00 +0000

Part I of the series "Don't Let the User Wait - Render Quickly to Keep Their Attention."

The problem hiding inside SSR

Server-Side Rendering promises the world: fast first paint, SEO-friendly markup, no content flash. For simple pages, it delivers. But real product pages are rarely simple. They need authentication checks, user details and live data to name a few - a cascade of API calls that all have to resolve before the server can respond.

If the page only renders after all data are fetched, the server is just the new bottleneck and the user experience is hurt.

Lets consider the case of a chat based application. The page needs to check user authentication before calling for the user details and user chats. All three API calls - auth, user details, chats - must complete before a single pixel is painted. Meanwhile, the user only sees a white screen and their experience is indistinguishable from a slow client-side app, regardless of whether the work is happening on the server.

"We moved to SSR and our Lighthouse score went up, but users still complain it feels slow." - every other engineering team.

The fix: Render the shell, let components own their data

The key insight is that not all data is equally critical for the initial render. In the case depicted by the image above, auth is critical to determine what the user is shown - you need a valid session before you send anything. But userDetails and chats? Those are content. The page can exist without them, and they can load in after the shell is already painted.

This article explores this using React and Next.js. If you're working with a different stack, the same principle applies at the BFF layer - framework-agnostic and without any dependency on Server Components. That's covered in Part II - coming 27 May.

React Server Components and Suspense make this the natural way to build. The idea splits into two clear phases:

Phase 1 - Render the shell immediately.
The page render is only blocked for auth. Once the session is confirmed, the HTML shell - with navigation, layout and skeleton placeholders - is sent to the browser and rendered. The user sees something real and fast.

Phase 2 - Each component fetches its own data.
UserDetails and Chats are asynchronous Server Components wrapped in Suspense boundaries. They each independently fetch their own data on the server and render their resolved HTML into the page as they complete - no waiting for each other, no coordinating through a parent.

The user lands on a page that is already painted - navigation is visible, layout is in place, skeleton loaders hold the space where content will appear. Then UserDetails and Chats swap in, each one independently, as soon as its data is ready.

Suspense as the rendering contract

React Suspense is the mechanism that wires this process together. Each data-dependent section of the page is wrapped in a <Suspense> boundary with a skeleton fallback. React renders the skeleton immediately and replaces it with the resolved content the moment the component is ready to render.

// app/home/page.tsx (Next.js App Router)
import { Suspense } from 'react'
import { UserDetailsSkeleton, ChatsSkeleton } from './skeletons'

export default async function HomePage() {
  // Only auth blocks here — this is the only awaited call
  const session = await getSession()
  if (!session) return redirect('/login')

  return (
    <main>
      {/* Renders immediately — no data dependency */}
      <Header user={session} />

      {/* Skeleton shown instantly, swapped when data arrives */}
      <Suspense fallback={<UserDetailsSkeleton />}>
        <UserDetails userId={session.id} />
      </Suspense>

      {/* Resolves independently — doesn't wait for UserDetails */}
      <Suspense fallback={<ChatsSkeleton />}>
        <ChatList userId={session.id} />
      </Suspense>
    </main>
  )
}

Each Suspense boundary is independently resolvable. UserDetails can swap in before ChatList is ready and vice versa. The user sees a progressively enriched page rather than a binary flip from white screen to full content.

Each component owns its own fetch

The other half of the pattern is that each async Server Component fetches only what it needs, independently. There's no parent component collecting all the data and passing it down:

// components/UserDetails.tsx
async function UserDetails({ userId }: { userId: string }) {
  const details = await fetch(`/api/users/${userId}/details`)
    .then(r => r.json())

  return <ProfileCard {...details} />
}

// components/ChatList.tsx
async function ChatList({ userId }: { userId: string }) {
  const chats = await fetch(`/api/users/${userId}/chats`)
    .then(r => r.json())

  return <ChatFeed chats={chats} />
}

What React does under the hood:
renderToPipeableStream sends the HTML shell to the browser first. As each Suspense boundary resolves, React emits an inline script chunk over the same open connection. The browser swaps the skeleton for the real content without a full page reload or a separate network request.

Don't forget the error boundary

While Suspense handles the loading state, pair it with an ErrorBoundary to handle failure. This ensures that a broken API call degrades at the component level rather than crashing the whole page:

<ErrorBoundary fallback={<ChatsErrorCard />}>
  <Suspense fallback={<ChatsSkeleton />}>
    <ChatList userId={session.id} />
  </Suspense>
</ErrorBoundary>

Now if ChatList fails - network timeout, downstream 500, or anything else - the rest of the page is completely unaffected. Failed components can be retried either manually or automatically using exponential backoff strategy. Now the page has a significant improvement over the old SSR model where a single API failure would crash the entire render.

What this does to your metrics

Metric	Classic SSR — wait for all	Server Components + Suspense
TTFB	Auth + all API calls combined	Auth only — often 80–90% faster
FCP	After all data resolves	Shell arrives immediately
LCP	Tied to the slowest API call	Each section loads as ready
Error scope	One failure crashes the page	Per-section Error Boundaries
Data ownership	Centralised in page component	Each component owns its fetch

When to apply this pattern

Your page has a mix of critical and non-critical data. The pattern shines when there's a clear hierarchy - shell first, primary content second, secondary content third.

Backend calls have variable latency. If auth is fast but recommendations or chat APIs are slow, don't hold up the whole page. Let the slow sections render independently.

You're on Next.js App Router. Pages Router with getServerSideProps doesn't support this model - all data fetching is centralised and blocking. App Router's async Server Components and loading.tsx files are designed precisely for this pattern.

Summary

The old SSR model treats the page as a single blocking unit - nothing goes to the browser until everything is ready. Server Components and Suspense treat the page as a composition of independently resolvable sections, each with its own data timeline.

Block render only on auth, and render the shell immediately. Let each component own its data and render its content when ready. Pair every Suspense with an ErrorBoundary so failures stay local and can be retried.

The result is a page that feels genuinely fast - not because you moved computation around, but because you changed when the user sees something.

Not on React or Next.js?
The same principle applies - but the fix lives in the BFF, not the frontend framework. Part II covers the framework-agnostic approach using HTTP streaming. Works with Vue, Svelte, Angular, or anything else.

Part II - Don't Wait for APIs. Send What You Have. → Coming 27 May.

Your Portfolio Is Invisible. Here's How I Fixed Mine.

Pratik Goswami — Tue, 12 May 2026 02:30:00 +0000

Everyone is building. AI tools have made it trivially easy to spin up a beautiful portfolio or product site in an afternoon and deploy it to Vercel or Netlify before dinner. But here is the thing nobody talks about: Vercel gives you a URL. It does not give you an audience.

I learned this firsthand. I have had a personal website at pratikgoswami.dev for years. It looked great - it had my projects, experience, contact details - but the only people who ever visited it were recruiters who already had my resume or connections who clicked through from my LinkedIn. The site was essentially a private document with a public URL.

Then, in late April 2026, I spent two days fixing that. Here is exactly what I did and what happened after.

First, Understand Who You Are Actually Building For

Most developers optimize their site for one audience: humans. But your site has two types of readers: humans and machines. And increasingly, it is the machines that decide whether the humans ever find you.

SEO (Search Engine Optimization) is about helping Search Engines (like Google) crawl, understand, and rank your content so people find you through search.
AEO (Answer Engine Optimization) is newer, and arguably more important today. It is about helping AI assistants like ChatGPT, Gemini, and Claude form a confident, accurate understanding of who you are, so they can mention you when someone asks "who are good full-stack developers with fintech experience?"

Think of it this way: SEO gets you on the map. AEO makes you a landmark.

With LLMs becoming the next search interface, both matter. I decided to tackle them together.

The Honest Baseline

Before I made any changes, my Google Search Console data tells an honest story. The site had a tiny trickle of impressions starting in early April, the result of some rudimentary metadata I had set up previously. But it was flat, sparse, and averaging a position of 36+ in search results, effectively invisible.

I deployed my SEO and AEO changes on April 28th, 2026. By April 30th, impressions spiked sharply. In the 12 days since, the site has accumulated 52 impressions, with 2 actual clicks and a 1.8% CTR. Small numbers, but the trajectory is the story. The spike is real and it came immediately after the changes.

Now let me walk you through exactly what I changed.

Part 1: Traditional SEO - Making It Readable for Google

My site is built with Next.js (App Router), TypeScript, and Sanity CMS. It looked clean to any human visitor. To a crawler, it was a meaningless soup of <div> tags.

1. Semantic HTML Refactoring

The simplest change with the highest impact. I replaced generic container divs with meaningful HTML elements.

Before:

<section id="skills-section">
  <div className="skills-section-title">Skills</div>
  <div>
    {skillList.map(({title, skills}) => (
      <div className="skill-container" key="{title}">
        <div className="skill-title">{title}</div>
        <div className="skill-item-container">
          {skills && skills.map((skill, index) => (
            <div className="skill-item" key="{`${title}-${index}`}">{skill}</div>
          ))}
        </div>
      </div>
    ))}
  </div>
</section>

After:

<section id="skills-section" aria-label="Skills">
  <h2 className="skills-section-title">Technical Skills</h2>
  <div className="skills-grid">
    {skillList.map(({ title, skills }) => (
      <article className="skill-container" key="{title}">
        <h3 className="skill-title">{title}</h3>
        <ul className="skill-item-container">
          {skills && skills.map((skill, index) => (
            <li className="skill-item" key="{`${title}-${index}`}">{skill}</li>
          ))}
        </ul>
      </article>
    ))}
  </div>
</section>

Why does this matter? A crawler reads your HTML like an outline. <h1> through <h3> tags are chapter headings. <section> and <article> are meaningful containers. Without them, Googlebot sees a flat document with no hierarchy and has to guess what is important.

2. Fixing Content Discoverability

This one surprised me. I had project details that rendered conditionally, after a user interaction: a click to expand, a tab switch, a state toggle. It looked fine in the browser, but Googlebot crawls the initial DOM, not the post-interaction state. If your content only renders after a click, it effectively does not exist to Google.

I refactored these components to render all content in the initial HTML, using CSS to control visibility rather than React state.

3. Adding Guides for Crawlers

I added robots.ts and sitemap.ts to my project - two small files that do an important job. robots.ts tells crawlers which pages they are allowed to visit. sitemap.ts hands them a complete map of every page on your site so nothing gets missed. Next.js App Router makes this clean.

// app/robots.ts
export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: "*",
      allow: "/",
      disallow: [""], // Routes that you dont want Crawler to see
    },
    sitemap: "https://www.pratikgoswami.dev/sitemap.xml",
  };
}

// app/sitemap.ts
export default function sitemap(): MetadataRoute.Sitemap {
  return [
    {
      url: "https://www.pratikgoswami.dev",
      lastModified: new Date(),
      changeFrequency: "monthly",
      priority: 1,
    },
  ];
}

The last step is submitting your sitemap in Google Search Console. That single action transforms your site from something Google might eventually find into something Google knows exists today.

4. Performance and Core Web Vitals

Google uses Core Web Vitals, specifically LCP (Largest Contentful Paint), as a ranking signal. LCP measures how long it takes for the largest visible element on your page to load - the lower the number, the faster your site feels to a visitor.

I had been importing FontAwesome icons as an external dependency, which added unnecessary weight to the bundle. I replaced the animated canvas background with a native Canvas API implementation, cutting the external dependency entirely and improving load performance.

Part 2: AEO - Making It Readable for AI

Most developers fix their SEO and think the job is done. It is not. Search behavior has fundamentally shifted. People are using ChatGPT, Gemini, and Claude as search engines now, asking them to recommend developers, tools, and products. If an AI model does not know who you are, you are invisible to an entirely new class of search. AEO is how you fix that.

1. JSON-LD Structured Data

Think of JSON-LD as your verified ID card for the internet - it tells search engines which queries you are relevant to, and gives AI models the structured facts they need to represent you accurately.

I added a <script type="application/ld+json"> block to my site's <head> using the Person and SoftwareApplication schemas from Schema.org. This gives AI models explicit, machine-readable facts rather than forcing them to infer who you are from your prose.

<Script
    id="schema-person"
    type="application/ld+json"
    dangerouslySetInnerHTML={{
      __html: JSON.stringify({
          "@context": "https://schema.org",
          "@type": "Person",
          name: "Pratik Goswami",
          jobTitle: "Frontend Software Engineer",
          url: "https://www.pratikgoswami.dev",
          sameAs: [
          "https://www.linkedin.com/in/prtkgoswami",
          "https://github.com/prtkgoswami",
          ],
          worksFor: {
          "@type": "Organization",
          name: "TikTok, IBM",
          },
          description:
          "Frontend Engineer specializing in React, TypeScript, and scalable UI systems.",
      }),
    }}
/>

Without this, an LLM has to guess who you are based on scattered text. With it, you are handing the model a verified fact sheet.

2. The Triangle of Trust - Entity Linking via sameAs

The sameAs property is subtle but powerful. By linking your personal domain to your LinkedIn and GitHub profiles, you are creating a web of verification across multiple authoritative sources.

LLMs build a confidence score around named entities. If "Pratik Goswami" appears on a personal website, a LinkedIn profile, and a GitHub account, and those sources all link to each other, the model develops a high-confidence entity. It knows who you are. Without these links, you are just an unnamed node in a vast graph.

This is the triangle of trust: your domain, LinkedIn, and GitHub. Each point of the triangle reinforces the others.

3. Writing for RAG - Declarative, Specific Descriptions

Retrieval-Augmented Generation (RAG) is how many LLMs fetch context before answering. They pull relevant chunks of text from indexed sources. That means how you write about your projects matters as much as the schema you add.

Vague (bad for RAG):

"Passionate developer who loves building impactful things."

Specific (good for RAG):

"Built Gears Connect, a B2B automotive parts marketplace using Next.js, PostgreSQL, and Stripe, enabling real-time inventory management for 50+ vendors."

The second version is indexable. It is full of specific, searchable facts. An LLM retrieving context for a query like "full-stack developers who have built marketplace apps" can actually use it.

4. JSON-LD Over llms.txt

You may have seen chatter about llms.txt, a proposed standard for helping LLMs read your site, but it is a shortcut, not a foundation.

llms.txt is a plain-text file placed at the root of your domain that gives AI crawlers a human-readable summary of your site, similar to how robots.txt works for search crawlers. Low effort to set up, but also low density. It carries no schema, no entity relationships, and zero influence over search rankings.

JSON-LD does all of that and more. It is a W3C standard understood by Google, Bing, LinkedIn, Perplexity, and SearchGPT simultaneously. It defines explicit relationships - that "Pratik Goswami" is a Person, worksFor specific organizations, and is the author of specific projects. It also unlocks Google Rich Results, putting your job title and links directly in the search listing. llms.txt cannot do any of this.

Part 3: Monitoring - Closing the Loop

Shipping SEO and AEO changes without monitoring is like sending a message and never checking if it was delivered. Monitoring closes the feedback loop - it tells you what Google has indexed, which queries are surfacing your name, and which parts of your site are actually holding a visitor's attention. Without it, you are optimizing blind.

Google Search Console was the first thing I set up, before deploying any changes. Verifying your domain and submitting your sitemap establishes a direct line of communication with Google.

The LLM test is simple and satisfying: ask ChatGPT, Gemini, and Claude "Who is Pratik Goswami?" My site now surfaces accurate, confident responses across all three. That is the AEO working.

Custom Google Analytics tracking using IntersectionObserver lets me track which sections of my site recruiters actually read, not just that they visited. Knowing that the "Job Application Tracker" project card gets more dwell time than others is actionable data, not a vanity metric.

const observer = new IntersectionObserver(
    (entries) => {
        entries.forEach((entry) => {
            const sectionId = entry.target.id;

            if (entry.isIntersecting) {
                // User entered a section
                activeSection.current = sectionId;
                enterTime.current = Date.now();
                sendSectionView(sectionId);
            } else if (activeSection.current === sectionId && enterTime.current) {
                // User left the section → calculate time spent
                const duration = Date.now() - enterTime.current;
                sendTimeSpent(sectionId, duration);
                activeSection.current = null;
                enterTime.current = null;
            }
        });
    },
    { threshold: 0.5 } // Trigger when 50% of a section is visible
);

SECTIONS.forEach((id) => {
    const el = document.getElementById(id);
    if (el) observer.observe(el);
});

Was It Worth It?

In two days of work, the site went from effectively invisible to ranking on the first page of Google for my name, accumulating 52 impressions in 12 days, and being recognized by ChatGPT, Gemini, and Claude when asked who I am.

The numbers are early, but the direction is clear. The spike in the Google Search Console (GSC) chart is immediate and unambiguous.

Here is what I want you to take away:

A beautiful site and a discoverable site are not the same thing. Most portfolios are the former, not the latter.
AEO is not the future. It is right now. LLMs are already answering career questions. If you are not structured for them, you are invisible to them.
The implementation is smaller than you think. Two files, one schema block, and a few hours of refactoring later, my site went from invisible to indexed. The effort was minimal. The compounding visibility was not.
Treat your portfolio like a product. Ship, measure, iterate.

Your Quick-Start Checklist

Pick one item from this list and do it this weekend:

[ ] Replace <div> wrappers with <section>, <article>, and proper <h1>–<h3> hierarchy
[ ] Audit for content hidden behind React state and render it in the initial HTML
[ ] Add robots.ts and sitemap.ts in Next.js App Router
[ ] Submit your sitemap in Google Search Console
[ ] Run PageSpeed Insights and check your LCP score
[ ] Add a Person JSON-LD schema to your <head>
[ ] Add sameAs links to LinkedIn and GitHub in your schema
[ ] Rewrite your project descriptions to be specific, declarative, and technical
[ ] Ask ChatGPT or Gemini who you are and see what they say today

So… What Is Next?

This is just the starting point. The real value of setting up monitoring is that the data now tells me where to focus next - which projects are getting attention, which queries are surfacing my name, and where there is still room to improve. I will keep the structured data updated as my experience grows, revisit the content as AEO standards evolve, and let the analytics guide the next round of changes. The foundation is built. Now it gets to compound.