I've sat in enough client calls to notice a pattern: everyone has an opinion on keywords. Nobody wants to own the website's actual performance. The marketing team says it's an engineering problem. The dev team says nobody told them speed affects rankings. Meanwhile the site sits there, half-loading on a customer's phone in Bangalore and both teams assume it's someone else's job to fix.
That gap is what this piece is about. Not the theory of Core Web Vitals — plenty of guides cover that — but where it actually breaks down in practice, and why, at MyAibo, we stopped treating it as a separate workstream from SEO and GEO a while back.
What we've actually seen slow sites cost
One client came to us convinced their content strategy wasn't working. Traffic was fine. Conversions weren't. Turned out their product pages had a 6.8-second LCP on mobile, mostly from unoptimized hero images. We swapped to WebP, lazy-loaded below-the-fold content, and conversions moved before we'd touched a single word of copy.
That's the thing nobody wants to hear: sometimes the fix isn't better content. It's a website that isn't fighting the content.
The Metrics, without the fluff
Google still uses three Core Web Vitals to judge page experience: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). The current "good" bar sits at LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. Sites that want a real competitive edge are pushing INP closer to 150ms, not just scraping under the 200ms line.
Here's the part worth being honest about, though: these aren't the ranking factor. They're a tie-breaker. If your competitor's content genuinely answers the question better than yours, a faster page won't save you. What Core Web Vitals actually do is decide who wins when two pages are otherwise close — and in most competitive categories, "otherwise close" describes a lot of pages.
There's a wrinkle that trips up more Indian businesses than it should: Google ranks based on real-user Field Data from the Chrome User Experience Report (CrUX), not the lab score you get from running PageSpeed Insights on office Wi-Fi. I've seen sites score 95+ in Lighthouse and still perform badly for real users on a 4G connection in a smaller city. If your metro traffic converts fine and your tier-2/tier-3 traffic doesn't, this is one of the first places I'd look before blaming the content.
Why this now matters to ChatGPT, not just Google
This is the part that's changed in the last year or so, and it's the reason we stopped filing "site speed" and "SEO" under different departments internally.
AI answer engines such as ChatGPT, Perplexity, Google's AI Overviews don't just read your content. They're implicitly judging whether your page is a reliable enough source to stake their own answer on. A slow, janky, or unstable page reflects badly on whatever the AI is about to tell a user in its own voice, so it's less likely to get cited, independent of how good the writing is.
A few ways this plays out in practice:
Fast-loading pages read as more trustworthy sources to both crawlers and AI retrieval systems. Low INP correlates with the kind of engagement signals these systems treat as quality proxies. A layout that doesn't jump around while loading reads as more professional — to a person and, it turns out, to whatever's evaluating the page algorithmically. And crawl efficiency compounds over time: fast, well-structured sites get indexed more often and more deeply, so new content gets a fair shot at citation sooner rather than sitting unseen for weeks.
None of this is exotic. It's just rarely framed as a marketing problem, so it rarely gets marketing-level attention.
The new complication almost nobody's talking about yet
On July 1, 2026, Cloudflare announced a change that's going to catch a lot of businesses off guard if nobody's watching for it. Cloudflare sits in front of roughly a fifth of the web, so when it changes default behavior, it's not a niche update.
They've replaced the old blunt "block all AI bots / allow all AI bots" toggle with three categories: Search, Agent, and Training crawlers. Starting September 15, 2026, new defaults will block Training and Agent crawlers on ad-monetized pages unless a site owner opts out while Search crawlers stay allowed.
Here's the catch. Googlebot, Applebot, and Bing's crawler are multi-purpose as they crawl for search indexing and AI training in the same pass. Under the new defaults, a business trying to block AI training scraping could accidentally throttle the exact crawler that gets them into Google Search and AI Overviews in the first place, unless someone actually goes into the Cloudflare zone settings and checks before mid-September.
I'd bet most site owners reading this have no idea this deadline exists. That's not a criticism — it's a Cloudflare dashboard setting, not something that shows up on a marketing team's radar. But it's exactly the kind of decision that shouldn't be left to whoever last had admin access.
What we'd actually recommend checking
Not a 40-point audit checklist. Just the handful of things that tend to matter most, in the order I'd tackle them:
Pull your Core Web Vitals data from Google Search Console — it reflects real CrUX field data — rather than trusting a single Lighthouse run. Fix INP before chasing LCP; heavy JavaScript blocking the main thread is the most common cause of poor interactivity, and it's the one people skip because it doesn't show up as obviously in a basic speed test. Serve images in WebP or AVIF through a CDN instead of full-resolution files straight from origin. If you're behind Cloudflare, go check your bot management settings before September 15 — specifically whether Search crawlers are protected from getting caught in a broader Training/Agent block. And treat your framework and hosting choice as an SEO decision, not just an engineering preference, because rendering strategy and time-to-first-byte trace straight back to it.
Why We Built This Into One Practice, Not Two
This is the reasoning behind pairing development with GEO, AEO, and SEO at MyAibo instead of treating them as separate service lines with separate timelines. A brilliant content strategy sitting on a slow, badly architected site is a strategy fighting itself the whole way. We wrote separately about zero-click search and how Indian businesses can still win traffic — this piece is really the other half of that conversation, because content strategy and site architecture stop being separable once AI engines start grading both at once.
For teams that don't have the bandwidth to keep checking this quarter over quarter, our AI automation work is partly built around exactly that: catching Core Web Vitals drift and crawler config changes before they quietly cost you visibility.
Where we'd leave this
If there's one thing I'd want a business owner to take from this, it's not a metric to memorize. It's this: stop letting "that's a dev thing" or "that's a marketing thing" decide who owns your site's performance. Neither team fully owns it right now at most companies, which is exactly why it keeps slipping. Pick someone. Give them the September 15 deadline. Check back in three months.