What I Learned · Real Portfolio Experiment
AI Search & MarTech
Are You Using Lovable for Your Website? You Need to Know This.
Your website may look perfect in the browser while search engines and AI crawlers receive something very different. I discovered it while auditing my own portfolio.
By Natália Nogueira — AI & MarTech Specialist
Published September 9, 2026
What humans saw
What some machines received
By Natália Nogueira — AI & MarTech Specialist
Published · ~11 min read
Start here
The five-second version
My portfolio looked perfectly healthy in a browser. The pages loaded. The copy was there. Everything worked.
But when I inspected what was being delivered before JavaScript ran, the HTML response was suspiciously small—under 5 KB—and contained very little of the actual page content.
To a human visitor, I had a complete portfolio.
To some crawlers, I had something closer to an H1 and a dream.
The reason was not bad copy or a missing keyword strategy. My portfolio had been created on Lovable's older, client-side-rendered stack. Lovable changed the foundation for new projects on May 13, 2026, introducing TanStack Start and server-side rendering. After I updated my project and republished it, far more of the page appeared in the delivered HTML—and the difference in discoverability became visible.
That rabbit hole taught me something every marketer building with AI needs to understand:
A page can exist, look beautiful, and still be difficult for a search engine or AI crawler to consume.
Let's unpack what happened, without turning this into alphabet soup.
Alphabet soup, sorted
First: AEO and GEO are driving everyone nuts
If SEO, AEO, GEO, LLMO, and AI SEO are beginning to look like someone dropped a box of Scrabble letters in a marketing meeting, you are not alone.
Here is the useful version:
SEO — Search Engine Optimization
Rank pages in traditional search results
“Will Google show my page?”
AEO — Answer Engine Optimization
Make content easy to extract as a direct answer
“Can a system confidently answer the question using my content?”
GEO — Generative Engine Optimization
Increase visibility, inclusion, or citation inside AI-generated responses
“Will a generative engine use or mention my content when it creates an answer?”
So, what is the difference between AEO and GEO?
There is significant overlap, and the industry does not use the terms consistently.
AEO is the broader, answer-first idea. It grew from optimizing for featured snippets, voice assistants, knowledge panels, and other systems that return an answer instead of only a list of links. Today, it is also commonly used for ChatGPT, Perplexity, Claude, Gemini, and Google AI Overviews.
GEO is more specifically focused on generative engines. The term was formalized in the 2023 paper GEO: Generative Engine Optimization, which examined how content could gain visibility within answers synthesized by generative AI. The researchers reported visibility improvements of up to 40% in their experimental setting—but that is not a promise that adding a few citations will increase anyone's organic traffic by 40%.
My honest recommendation? Do not build three disconnected strategies.
Think of it as one visibility system:
- SEO helps your page get discovered and ranked.
- AEO makes the information clear and extractable.
- GEO makes the content useful, trustworthy, and citable inside a generated response.
Different labels. Shared technical foundation.
And that foundation starts with a crawler being able to access the content at all.
The investigation
What was actually happening to my Lovable portfolio?
Lovable's previous stack used React, Vite, and client-side rendering.
In a client-side-rendered single-page application, the server can initially send a very small HTML shell. The browser then downloads JavaScript, runs it, and constructs the visible page.
Humans using modern browsers normally see the final result without thinking about any of this.
But crawlers are not all browsers.
Some execute JavaScript. Some execute it later. Some have limited rendering capabilities. Some social preview bots simply read the HTML response and look for metadata. If the meaningful content only appears after JavaScript runs, discoverability becomes less reliable.
Important nuance
Page weight is not an SEO score
A response under 5 KB does not automatically mean a page is unindexable. But when a content-heavy page returns a tiny document containing almost none of its visible copy, it is a strong reason to investigate.
The real question is not:
“How many kilobytes is my page?”
It is:
“Is the content I want indexed actually present in the HTML a crawler receives?”
In my case, very little of it was.
May 13, 2026
What Lovable changed
According to Lovable, projects created from May 13, 2026 onward use TanStack Start and support server-side rendering.
Previous stack
React + Vite
New stack
TanStack Start
Previous stack
Primarily client-side rendered
New stack
Supports SSR, SSG, and CSR
Previous stack
Browser builds the visible page
New stack
Complete HTML can arrive with the first response
Previous stack
Existing apps receive crawler pre-rendering
New stack
New projects receive native SSR capabilities
Instead of sending an almost-empty shell and waiting for the browser to build everything, server-side rendering can send fully formed HTML on the first request. Static marketing routes—such as landing pages, blog posts, and About pages—may also be pre-rendered during deployment when appropriate.
This matters for three audiences:
- Traditional search crawlers, which can access the copy more directly.
- AI-search crawlers, which may not execute client-side JavaScript reliably.
- Social preview bots, which need page-specific title, description, and Open Graph data in the returned HTML to generate a useful LinkedIn, Slack, WhatsApp, or X preview.
Lovable reports early gains across its domains of 2.9% in organic search traffic for apps using pre-rendering and 98.5% in traffic from AI tools such as ChatGPT and Perplexity. Those are platform-wide early results, not a guarantee for an individual website, but the direction is worth paying attention to.
Important correction
What owners of older Lovable projects need to know
Projects created before the new stack were not simply abandoned.
Lovable says older projects automatically receive pre-rendered snapshots for verified crawlers, with no opt-in or migration required. Human visitors still receive the regular single-page application.
That is different from being built natively with full SSR.
Lovable now also documents a migration path for eligible older projects. You can:
- Use
/migrate; - Open Project Settings and look for the Migrate option; or
- Ask the agent to “upgrade my app to TanStack” and approve the migration.
The live site is not changed until the migrated version is published, and the migration consumes credits. If the Migrate option is absent, Lovable says the project is already on the current engine.
So the accurate takeaway is:
Newer Lovable projects use the SSR-capable TanStack stack by default. Older projects receive crawler pre-rendering automatically and may also be eligible for full migration.
In my portfolio's case, updating and republishing changed how much content I could see in the delivered output. That was the moment the problem stopped being theoretical.
The nuance
Why “Google can render JavaScript” is not the end of the conversation
Yes, Google can render JavaScript.
But “can” and “always does immediately, completely, and exactly as intended” are not the same statement.
And Google is only one part of discovery now.
ChatGPT, Perplexity, Claude, Gemini, Bing, social platforms, messaging apps, and specialized agents do not necessarily crawl, render, retrieve, or cite pages in the same way. A modern visibility strategy cannot depend on every system behaving like Googlebot.
Server-rendered or pre-rendered HTML reduces that dependency. It gives machines useful content earlier, with fewer steps and fewer assumptions.
This is not a replacement for good content. It is the delivery system that allows good content to participate.
Try it yourself
The wonderfully simple audit I actually used
If your website was built with Lovable—or any JavaScript-heavy builder—do not panic. Audit it. And I promise this is not one of those “open twelve developer tools and whisper sweetly to the console” audits.
I opened PowerShell, pasted one small script, and asked it to fetch my own homepage the way an AI crawler would. Then I did the most technically sophisticated part of the entire process: I pasted the results into Lovable, asked it to upgrade the project, published the updated version, and ran the exact same test again. That was it. That was the audit.
One command. No SEO suite, no crawler subscription, no dramatic incident bridge. Here it is:
$url = "https://natalianogueira.tech"
$phrase = "solutions architect"
$response = Invoke-WebRequest -Uri $url -UserAgent "GPTBot/1.0"
$html = $response.Content
[pscustomobject]@{
"HTML length" = $html.Length
"FAQ visible" = $html -match [regex]::Escape($phrase)
"H1 count" = ([regex]::Matches($html, "<h1[\s>]")).Count
"JSON-LD count" = ([regex]::Matches($html, "application/ld\+json")).Count
"HTTP status" = [int]$response.StatusCode
}HTML length
Shows whether the returned HTML is substantial or suspiciously small for a content-heavy page.
FAQ visible
Searches for a distinctive phrase located deeper in the page to determine whether more than the hero or H1 was returned.
H1 count
Checks how many primary headings appear in the returned HTML.
JSON-LD count
Checks whether structured-data scripts are present in the initial response.
HTTP status
Helps identify whether the tested URL responds directly or encounters a redirect.
Try it on your website
Replace my URL with the page you want to audit. Then replace “solutions architect” with a distinctive phrase from the middle or bottom of your own page.
Run it, read the results, and then hand them to your AI assistant of choice with this follow-up:
Based on these results, is the meaningful content present in the initial HTML? What should I investigate next?Friendly clarification
Before the comments section gets ideas
These checks provide diagnostic clues. They do not individually prove whether a page is indexable or whether it will rank. HTML response size is not an SEO score, and identifying the request as GPTBot does not perfectly reproduce every AI platform's complete crawling and retrieval system.
The goal is simpler: a quick way to compare what appears in your browser with what is actually present in the returned HTML.
Reflection
What this taught me as an AI & MarTech specialist
The funniest part of this story is that nothing looked broken.
There was no dramatic error screen. No missing section. No giant red warning that said:
“Congratulations! Humans can see your expertise. Machines may receive the decorative shell.”
That is exactly why this matters.
AI builders are making it possible to create excellent digital experiences at extraordinary speed. But speed does not remove the need to understand what happens between a published page and the systems expected to discover it.
Marketing, technology, and AI search are no longer separate conversations.
Your positioning can be brilliant.
Your copy can be strategic.
Your design can be beautiful.
But if the delivery layer hides that work from crawlers, your best content may never enter the consideration set.
The new marketer does not need to become a framework engineer. But we do need enough technical curiosity to ask better questions:
- What is the server returning?
- What can a crawler access without running JavaScript?
- Is this route individually discoverable?
- Can an answer engine extract a clear, trustworthy answer?
- Can a generative engine understand who created this and why the source is credible?
That curiosity is how I found the problem on my own site.
And yes, I lost several hours to the rabbit hole.
But it gave me something more useful than a quick fix: a much better understanding of how modern discovery actually works.
Final takeaway
The names will change. The fundamentals will not.
AEO and GEO are new labels around a rapidly changing behavior: people are increasingly asking systems for answers instead of manually reviewing ten blue links.
The names may continue to change. The fundamentals will not:
- 1
Make your content accessible.
- 2
Make it understandable.
- 3
Make it useful.
- 4
Make it credible.
- 5
Make it easy to attribute.
And if you built a Lovable project before May 13, 2026, check your stack and inspect what your server actually returns.
Your website may be saying everything you intended.
Just make sure the machines can hear it too.
Quick answers
FAQ
What is the difference between SEO, AEO, and GEO?
- SEO focuses on visibility in ranked search results. AEO focuses on making content suitable for direct answers. GEO focuses on visibility, use, and citation in answers synthesized by generative AI. In practice, they overlap and share foundations such as crawlable HTML, clear structure, authority, relevance, and strong source signals.
Did Lovable introduce server-side rendering in May 2026?
- Yes. Lovable states that new projects created from May 13, 2026 use TanStack Start and support server-side rendering. Older projects remain on the previous application stack unless migrated, but Lovable provides them with automatic pre-rendering for verified crawlers.
Do all Lovable projects created before May 13 need to be migrated?
- No. Lovable says existing projects already receive crawler pre-rendering without manual work. Full migration may still be valuable when you want the current TanStack architecture and native SSR, but it should be evaluated and tested rather than treated as a universal emergency fix.
How do I know if my Lovable project can migrate?
- Check Project Settings for a Migrate option, use /migrate, or ask the Lovable agent whether the project is using the previous stack. Lovable says that if no Migrate option appears, the project is already on the latest engine.
Is a small HTML response proof that my page cannot be indexed?
- No. Response size alone does not establish indexability. It is a diagnostic clue. Confirm whether the important content and metadata appear in the initial HTML, then validate crawler access, rendering, indexing, canonicalization, and sitemap behavior.
Will SSR automatically make a website rank?
- No. SSR and pre-rendering improve content accessibility, but ranking and AI visibility also depend on relevance, quality, authority, internal and external links, technical health, competition, and user value.
References
Sources
- Lovable: Building apps using TanStack Start(opens in a new tab)
Rollout date, old/new stack comparison, rendering behavior, legacy pre-rendering, and early traffic results.
- Lovable: SEO and AI search(opens in a new tab)
SSR for new apps, automatic pre-rendering for older apps, migration instructions, social previews, and SEO/AEO review features.
- Lovable Documentation: Optimize your app for SEO and AI search(opens in a new tab)
Official implementation and audit guidance.
- Aggarwal et al.: GEO—Generative Engine Optimization(opens in a new tab)
The research paper that formalized GEO.
Keep Following Along
Want to See More Insights Like This?
Add Natalia Nogueira as a Preferred Source on Google and make it easier to find my latest articles and insights.
Search my name on Google, then tap the three dots next to my result and choose “Add as Preferred Source”. You can remove it anytime.
Is your marketing technology working beautifully—or only looking beautiful?
The delivery layer decides whether your best work is ever discovered.
I help businesses connect the technical and strategic sides of marketing—from AI visibility and automation to funnels, CRM architecture, integrations, and the systems that make growth possible.