DEV Community: Garvit Sharda

SEO in Abu Dhabi in 2026: A Local Playbook for the UAE Capital

Garvit Sharda — Wed, 12 Aug 2026 09:16:50 +0000

For years, businesses in the UAE capital quietly sent their search marketing budgets to Dubai. In 2026 that no longer makes sense. Abu Dhabi's economy â€” government, energy, real estate, healthcare, education, tourism â€” is its own distinct market with its own buyers, its own search behaviour, and its own competitive landscape. If you run a business here, ranking well in Abu Dhabi is a different job from ranking in Dubai, and it deserves a strategy built for it.

Here is what genuinely moves the needle for SEO in Abu Dhabi in 2026.

Local intent is the whole game

Someone searching "clinic near Al Reem Island" or "office fit-out contractor Abu Dhabi" is not a generic lead â€” they are a local buyer with immediate intent. Winning that search comes down to a few local signals done consistently:

A complete, accurate Google Business Profile with the right primary category, real photos, and steady reviews.
NAP consistency â€” your business name, Abu Dhabi address and phone number identical everywhere they appear online (your site, directories, social profiles).
Location-specific landing pages that actually talk about Abu Dhabi neighbourhoods and areas you serve, not a generic "we cover the UAE" paragraph.

Local SEO compounds: the more consistently your business shows up across the local web, the more Google â€” and increasingly AI answer engines â€” treat you as the obvious local choice.

Bilingual search is not optional here

Abu Dhabi searches happen in both English and Arabic, and the two audiences phrase things differently. A serious SEO strategy accounts for Arabic keywords, right-to-left content, and â€” if you run separate language versions â€” correct hreflang tagging so Google serves the right page to the right user. Ignoring Arabic search leaves a large, high-intent slice of the market to competitors who bothered.

Answer engines are the new front door

More Abu Dhabi buyers now ask ChatGPT, Google's AI Mode, or Perplexity "who is the best [service] in Abu Dhabi?" and act on the single answer they get back. To be that answer you need the same fundamentals that win classic SEO â€” fast, crawlable, well-structured pages â€” plus structured data (Organization, LocalBusiness, FAQ schema) and consistent mentions across the web so the model is confident recommending you. Local SEO and AI-search optimisation are now the same project.

Content that matches how locals actually search

Thin, generic pages don't rank. What does: genuinely useful, locally-relevant content â€” a guide to choosing a contractor in Abu Dhabi, an explainer on a regulation that affects local businesses, an FAQ that mirrors the questions real customers ask. Each strong page is both a ranking asset and a citation an AI engine can quote.

The technical basics still decide winners

None of the above matters if the site is slow or hard to crawl. Core Web Vitals (especially INP), mobile performance, clean internal linking, a valid sitemap and https are the price of entry. Get these right and the content and local signals actually get rewarded.

The bottom line

SEO in Abu Dhabi in 2026 is local intent + bilingual reach + AI-answer readiness, all sitting on a technically sound site. It is very winnable, because many competitors are still running Dubai-shaped strategies in an Abu Dhabi market. Move deliberately on the local signals and you build a lead that is hard to unseat.

If you want specialists to run this for you, this is exactly what an SEO agency in Abu Dhabi like COM8 STUDIO does day to day â€” and the wider team is a digital marketing agency in Dubai serving the whole UAE. If you just want to see where your site stands right now, start with a free SEO audit.

Author: Garvit Sharda, COM8 STUDIO â€” helping Abu Dhabi and Dubai businesses get found in search.

International SEO in 2026: How to Serve Two Markets (UAE + US) From One Site Without Cannibalizing Yourself

Garvit Sharda — Sat, 08 Aug 2026 06:21:35 +0000

For twenty years the hardest part of international SEO was translation. In 2026 the hardest part is telling Google which version of a page belongs to which market â€” and getting it wrong quietly wastes everything else you do.

If you run one website that has to win customers in two places at once â€” say the UAE and the United States â€” you have almost certainly hit this. You publish a great page, it ranks, and then Google serves your en-US page to a searcher in Dubai (wrong currency, wrong phone number, wrong intent) or shows your Gulf page to someone in Chicago. Rankings look fine in a dashboard; conversions leak. This is a technical problem, and it has a technical fix.

Here is how to serve two markets from one site in 2026 without the two versions cannibalising each other.

First decision: URL architecture

Before a single hreflang tag, you choose how the regions live on your domain. There are three options and in 2026 the trade-offs are clearer than they used to be.

ccTLDs (example.ae, example.com) send the strongest geo-targeting signal, but every ccTLD is a separate domain in Google's eyes. If your .com has a Domain Rating of 50, your fresh .ae starts at zero. You rebuild authority per market.
Subdomains (ae.example.com) are the worst of both worlds in 2026: Google treats them as partially separate, so authority transfer is inconsistent, yet you get none of the trust signal a ccTLD gives.
Subdirectories (example.com/ae/, example.com/us/) are the recommended default for most non-enterprise sites. They consolidate all your link equity under one domain, are cheaper and faster to run, and you handle geo-targeting with hreflang plus Search Console.

Unless you are a large enterprise with a market-by-market budget, use subdirectories. One domain, one authority pool, region handled by signals rather than by fragmenting your site.

What hreflang actually does

hreflang is a single instruction to search engines: this page has other versions, here they are, and here is who each one is for. It is a language and optional region signal â€” which is exactly what a two-market business needs.

The codes matter. Language is ISO 639-1, region is ISO 3166-1 Alpha-2:

en-US â€” English, United States
en-AE â€” English, United Arab Emirates
ar-AE â€” Arabic, United Arab Emirates
x-default â€” the fallback for everyone you did not explicitly target

You can declare hreflang three ways. Pick one and never mix them:

1. HTML <link> tags in the <head> (simplest for small sites):

<link rel="alternate" hreflang="en-us" href="https://example.com/us/pricing" />
<link rel="alternate" hreflang="en-ae" href="https://example.com/ae/pricing" />
<link rel="alternate" hreflang="ar-ae" href="https://example.com/ae/ar/pricing" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing" />

2. HTTP headers â€” the only option for non-HTML files like PDFs.

3. XML sitemap â€” the best choice for large sites, because your CMS can auto-generate and update the cluster whenever pages are added or removed, instead of you hand-editing hundreds of heads.

The three rules that break everything

This is where an estimated 75% of hreflang implementations go wrong â€” and hreflang errors are blamed for 60â€“80% of multi-country SEO failures. Almost all of it comes down to three rules:

Reciprocity. If page A points to page B, page B must point back to page A. One-directional tags are ignored.
Self-reference. Every page must include a tag pointing to itself. If you have five localized versions, every page carries six declarations: five variants plus x-default.
One broken link kills the cluster. A single wrong or 404 URL, or a typo like en-uae (not a valid code â€” it's en-ae), and Google discards the entire cluster for that page. Not just the bad line â€” all of it.

That last rule is why "we added hreflang and nothing changed" is such a common story. The tags were there; one URL was wrong; Google ignored the lot.

Geo-targeting beyond hreflang

hreflang decides which version shows. It doesn't do the rest of localization for you:

Local signals on the page: currency, a local phone number and address (consistent NAP), and content that reflects local intent â€” a UAE VAT line reads very differently from a US sales-tax one.
Search Console â†’ International Targeting still lets you confirm Google is reading your hreflang and flags return-tag errors.
Do not IP-redirect users automatically. Googlebot crawls mostly from US IPs; auto-redirecting by IP can mean Google only ever sees one version. Suggest the right region, let the user choose, keep every version crawlable.

A 15-minute audit you can run today

View source on a key page. Is there a self-referencing hreflang tag? An x-default?
Click every URL in the cluster. Do any 404 or redirect? Do the return tags exist on the other end?
Check the ISO codes against the real lists â€” en-ae, ar-ae, en-us, not invented variants.
Open Search Console's International Targeting report and read the errors.
Confirm you are not auto-redirecting Googlebot by IP.

Fix those five and you are already ahead of three-quarters of multi-region sites.

Why this is worth the effort

International SEO done right is a compounding moat. Because most competitors get the technical layer wrong, a clean hreflang setup plus genuinely localized content means you quietly own the right SERP in both markets while they cannibalise themselves in one. It is unglamorous, it is mostly plumbing, and it wins.

If you'd rather have specialists run this across both markets, this is exactly the kind of work a digital marketing agency in Dubai does day to day â€” the technical SEO and AI-search services that keep a single site ranking cleanly in the UAE and the US (we do the same for US-market campaigns run out of the Gulf). If you just want to know where your current setup leaks, grab a free SEO audit and start with the five checks above.

Author: Garvit Sharda, COM8 STUDIO â€” a digital marketing agency helping UAE and US businesses rank across markets.

Google Ads vs SEO: Where Should Your Marketing Budget Go in 2026?

Garvit Sharda — Thu, 06 Aug 2026 09:10:40 +0000

Every business owner eventually asks the same question: should we put our marketing budget into Google Ads or into SEO? In 2026, with AI reshaping search and paid-media costs still climbing, the answer matters more than ever. The honest response is that these two channels do different jobs — and the smartest brands run them together rather than choosing one.

Google Ads: renting attention

Google Ads buys visibility instantly. The moment your campaign goes live, your business can appear at the very top of the results for the keywords you choose. That speed is paid search's biggest advantage: it's perfect for launching a product, filling a slow month, or testing which offers and landing pages actually convert.

The catch is simple. The traffic stops the moment you stop paying, and in competitive markets the cost per click has climbed steadily for years. Paid search is renting attention — the rent never ends, and it tends to go up.

SEO: building an asset you own

SEO works the other way around. It's slow to start, often taking three to six months to show real movement, but it compounds. A page that earns its ranking keeps attracting visitors month after month with no per-click fee. Over a year or two, the cost per acquisition from organic search typically falls far below paid, which is why so many marketers name organic search their single best return-on-investment channel.

Put another way: good SEO is an investment in an asset you own, not an expense you rent.

So where should the budget go?

A practical rule for 2026 is to run both in a deliberate split. Use Google Ads to capture existing high-intent demand and to move fast, while you build SEO as the long-term engine that lowers your blended cost of acquisition over time.

Early on, a larger share may go to ads simply because SEO hasn't matured yet. As your organic visibility grows, you shift budget away from paid and reinvest the savings. The mix should never be static.

The new layer nobody can ignore: AI search

There's a third force this year. Google's AI Overviews and assistants like ChatGPT and Perplexity now answer many queries directly, and a growing share of searches end with zero clicks. This doesn't kill SEO — it changes it. The same strong content and authority that earn rankings also make you the source these AI systems cite. Neither Google Ads nor classic SEO alone covers this shift, which is exactly why an integrated strategy wins.

Three tips that save money

Never send paid traffic to a weak page. A great click-through rate pointed at a slow or unclear landing page just burns budget faster.
Measure against qualified leads and revenue, not vanity clicks. Impressions don't pay salaries.
Stop treating the channels as rivals. Keyword data from your ads should inform your SEO, and your SEO wins should let you scale back expensive paid terms.

The bottom line

Google Ads gives you speed and control. SEO gives you compounding, durable growth. And AI search rewards the brands that invest in genuine authority. A business that funds only ads stays on a treadmill; a business that funds only SEO waits too long for results. The winners fund both, measure ruthlessly, and shift the mix toward whatever produces profitable customers.

If you're not sure how to divide your own budget, an experienced digital marketing agency in Dubai can audit your funnel and recommend a split based on your margins and goals. It's the kind of thing our data-driven marketing services are built around — and a quick free SEO audit is a smart first step, because it shows exactly where your easy organic wins are before you spend another dirham or dollar on ads.

Written by Garvit Sharda of COM8 STUDIO, a digital marketing agency helping businesses in the UAE and the US grow through SEO, AI-search optimization and paid media.

The Cookieless Future Is Here: How to Measure Marketing in 2026 Without Third-Party Cookies

Garvit Sharda — Wed, 05 Aug 2026 08:47:46 +0000

For twenty years, the third-party cookie quietly ran digital marketing. It followed users across the web, stitched together their journeys, and told advertisers exactly which ad produced which sale. In 2026, that era is effectively over — and the businesses that prepared are running the same campaign efficiency they had in 2023, while the ones that didn't are quietly bleeding budget. Here is what actually changed, what it costs, and the practical stack that fixes it.

What actually changed

The headline is simpler than the noise around it. Third-party cookies are already blocked by default in Safari and Firefox, which together account for a large share of mobile traffic. Google reversed its plan to force-remove them from Chrome and moved instead to a user-choice model — but "user choice" in practice means a growing slice of Chrome users switch tracking off too. On top of that, mobile advertising identifiers (Apple's IDFA, Android's ad ID) are well into their second wave of deprecation. The net effect: the identifiers marketers relied on to connect a click to a conversion are disappearing, and no single browser update will bring them back.

The cost of doing nothing

This is not a theoretical privacy debate; it shows up directly in the numbers. Teams that never adapted their tracking are commonly absorbing 15–30% gaps in conversion reporting. That gap is dangerous precisely because it is invisible: your ad platforms report fewer conversions than actually happened, so their algorithms optimise toward the wrong audiences, your cost-per-acquisition climbs, and no amount of creative refresh fixes a measurement problem. You end up making budget decisions on data that is quietly 20% wrong. For any business spending seriously on paid media, that is the most expensive number on the page.

The three-layer stack that fixes it

The good news is that the fix is well understood in 2026, and it is a stack, not a single tool. It has to be built in order, because each layer depends on the one below it.

Layer one is consent and a first-party foundation. Before any clever tracking, you need a Consent Management Platform wired to Google's Consent Mode v2, plus first-party cookies and data you genuinely own. If a user hasn't consented, you have no reliable signal to work with — so consent is not a compliance checkbox bolted on at the end, it is the foundation the whole stack sits on.

Layer two is server-side tagging. Instead of firing tracking from the user's browser — where ad blockers, browser restrictions and short-lived cookies eat your data — you move measurement to your own server using server-side Google Tag Manager. This gives you more durable identifiers, fewer points of failure, and a much cleaner dataset. It is the backbone; the third layer is far less effective without it.

Layer three is server-side conversion APIs. This is where you recover the lost 15–30%. Rather than relying on a browser pixel to tell Meta or Google that a sale happened, you send that conversion straight from your server through Meta's Conversions API, Google's Enhanced Conversions, and the TikTok and LinkedIn equivalents. The ad platforms get accurate conversion data again, their optimisation improves, and your reported CPA starts telling the truth.

First-party data is the real asset

Underneath the technical stack sits a strategic shift: the brands winning in 2026 treat first-party data as a competitive asset, not a byproduct. Email and SMS lists, logged-in customer accounts, loyalty programs, quiz and survey responses, and CRM records are data you own outright — no browser can block them and no platform can take them away. It is not a coincidence that email marketing still returns roughly $36 for every $1 invested: it runs entirely on data you control. Every business should be asking a blunt question this year — what do we know about our customers that we own directly, and how do we ethically collect more of it?

Don't forget your analytics

Your own reporting needs the same treatment. In GA4, that means implementing Consent Mode correctly so that Google's behavioural modelling can estimate the users who decline cookies, rather than simply losing them from your reports. Configured properly, you keep directional accuracy in your dashboards even as raw observable data shrinks. Configured badly — or ignored — your analytics slowly drift from reality, and you won't notice until a quarterly review doesn't add up.

Where to start this week

You do not need to rebuild everything at once. Start by auditing the gap: compare the conversions your ad platforms report against what your CRM or backend actually recorded. If the difference is more than about 10%, you have a measurement problem worth money. Then implement Consent Mode v2, stand up server-side tagging, and connect one conversion API — usually Meta's or Google's first — before rolling out the rest. Do it in that order and the improvements compound.

If that sounds like a lot to coordinate, it is the kind of foundational work a digital marketing agency in Dubai should own end to end, because the tracking stack, the ad accounts and the analytics all have to agree with each other. It is also exactly what our data-driven marketing services are built around — measurement first, spend second. And if you just want to know where your current setup is leaking before committing to anything, a free SEO and analytics audit is the fastest way to see it.

The bottom line

The cookieless shift is not the end of measurable marketing — it is the end of lazy measurable marketing. The businesses that treated third-party cookies as a permanent crutch are the ones hurting. The businesses that build a consent-first, server-side, first-party stack get something better than they had before: data they actually own, that no browser policy can switch off. In 2026, that ownership is the real competitive advantage.

Written by Garvit Sharda of COM8 STUDIO, a digital marketing agency helping businesses in the UAE and beyond build measurement that survives whatever the browsers do next.

Programmatic SEO in 2026: How to Ship 10,000 Pages Without Getting Deindexed

Garvit Sharda — Tue, 04 Aug 2026 11:51:28 +0000

Programmatic SEO is seductive: one template plus a dataset, and suddenly you have ten thousand pages. But here's the uncomfortable 2026 reality — roughly 80% of programmatic deployments fail, and Google's March 2024 "scaled content abuse" policy is the reason most of them get quietly deindexed. Having watched both the wins and the wipeouts, here's what actually separates the sites that rank from the ones that vanish.

The one rule that decides everything

Programmatic SEO is just template + data. It works only when each generated page provides unique, useful information that justifies its existence.

There's a brutally simple test, borrowed from a production 3,887-page Next.js site: open three of your generated pages and read them. Does each one contain at least one piece of information the other two don't? If yes, you're probably fine. If no, Google will eventually drop them.

Pure variable substitution — "Marketing in Dallas" identical to "Marketing in Fort Worth" except the city name — is exactly what the 2024 spam update named as scaled content abuse. Templating your structure is fine. Templating your value is not.

The data layer is where it lives or dies

Most deployments die in the data, not the template. Here are your data sources ranked best to worst:

Original or proprietary research — the gold standard
Curated public data + your editorial commentary
API-sourced data (OpenStreetMap, government datasets) with an editorial layer
AI-generated + genuine human review
Pure AI-generated content → gets deindexed

Invest in the data, not the template. Every page needs at least one unique data point and 30–50 words of genuinely unique context. That single paragraph is often the difference between "indexed" and "crawled, currently not indexed."

Internal linking is not optional

Programmatic pages have almost no external backlinks, so they live or die by internal links. Target 20–38 internal links per page:

Link up to the parent hub (e.g. /services/seo)
6–8 siblings (same service, different cities)
4–6 cross-category links (other services, same city)

Pages with fewer than ~10 internal links rarely get indexed by Bing at all. Build a RelatedLinks component that generates this automatically for every page — don't hand-wire it.

Getting indexed — the part everyone skips

"Crawled — currently not indexed" is programmatic purgatory, and it's where thin sites go to die. Three layers get you out:

sitemap.xml — one file is fine up to 50,000 URLs; segment by category above that.
IndexNow — ping bing.com/indexnow + yandex.com/indexnow on every deploy. Bing typically indexes within 24 hours.
GSC URL Inspection API — request indexing for your highest-priority new URLs.

On the framework side, generateStaticParams prerenders one HTML file per entry at build time, and generateMetadata gives each page a unique title + description. If build time explodes (50,000 pages × 30s = 17 hours), fall back to ISR or per-category builds.

The 5 failure modes to memorize

Thin content — variable substitution only. → Fix: one unique data point per page.
Near-duplicate pages — same boilerplate, different noun. → Fix: 30–50 unique words of context each.
No search intent — building pages for queries nobody types. → Fix: validate real volume before building.
Indexation never starts — stuck in purgatory. → Fix: internal-link density + IndexNow + GSC.
Build time explodes — → Fix: ISR / incremental, per-category builds.

The bottom line

Page count is not the risk; per-page utility is. Sites with 100,000+ programmatic pages rank fine when each one earns its place — Zapier's integrations directory, Realtor's listings, Indeed's job pages. Sites with 500 thin pages get wiped in a single update. Build the data, wire the internal links, ping IndexNow, and only then scale.

If you're planning a build like this, it's the kind of thing a technical SEO team should scope before you generate a single page — and a free SEO audit will quickly tell you whether your existing programmatic pages are actually indexed or quietly stuck in purgatory.

Written by Garvit Sharda of COM8 STUDIO, a digital marketing and web agency focused on technical SEO and scalable content architecture.

JavaScript SEO in 2026: The "Two Waves of Indexing" Myth, and What Googlebot Actually Keeps

Garvit Sharda — Fri, 31 Jul 2026 09:31:18 +0000

If you build with React, Vue, or any JavaScript framework and you care about organic traffic, there's a good chance you're still optimizing for a Google that no longer exists.

For years the mental model was "two waves of indexing": Google reads your HTML in wave one, then comes back days or weeks later to run your JavaScript in wave two. That model — which Google itself presented back in 2018 — has quietly disappeared from the official documentation. In 2026, rendering is an asynchronous queue, and Google's own docs now say a page "may stay on this queue for a few seconds, but it can take longer than that." The famous "5-second JS execution limit"? Also not in the docs. It was never a hard rule.

So the interesting question in 2026 isn't when Google will run your JavaScript. It's what Google actually kept after it rendered your page — because that's a very different thing, and it's where most JS sites quietly bleed traffic.

How Google actually processes a JS page now

Three stages, in order: crawl → render → index.

Crawl. Googlebot makes an HTTP request, checks robots.txt, and parses whatever HTML comes back.
Render. Every 200 page gets queued for rendering in a headless, evergreen Chromium (it understands modern JS — ES2020+, dynamic import(), even WebAssembly). Syntax support is not your problem. Resource and queue constraints are.
Index. Google indexes the rendered DOM and re-extracts links from it.

One trap worth memorizing: if a noindex is present in the initial HTML, Google may skip rendering entirely. So the classic "we'll inject the right robots tag with JavaScript" plan can backfire — the script that was supposed to remove the noindex never runs.

The failure modes nobody warns you about

Here's the uncomfortable part. A client-side-rendered (CSR) page ships an almost-empty HTML shell; everything real arrives with the JS. When rendering succeeds and the content looks valuable, the page indexes fine. When it doesn't, you land in one of these buckets — all visible in Search Console:

Symptom	Typical status	Likely cause
HTML is a shell, content from JS	"Crawled – currently not indexed" (or indexed empty)	Render failed or judged thin
Client-side routing, empty states served as 200	"Soft 404"	No real error code
Large JS site, new pages pending	"Discovered – currently not indexed"	Render queue / crawl budget
title/canonical/robots injected via JS	Duplicate / canonical conflicts	Initial HTML disagrees with the render

The most insidious is the indexed-empty shell: the URL is in the index, but it ranks for nothing because Google kept the pre-JS shell. Nothing looks broken until you compare what got indexed with what should have.

And "Soft 404" is a pure SPA disease: your router shows a "no results" view but the server still returns 200. Sold-out products, empty search pages, and misconfigured fallback routes generate these at scale.

CSR vs SSR vs SSG vs ISR, minus the dogma

You don't need to server-render everything. You need SEO-critical content in the initial HTML response. Quick decision:

CSR — browser builds the DOM. Fine for dashboards behind a login; risky for anything you want ranked. Pure CSR can delay indexation enough to cost a large share of organic traffic.
SSR — HTML per request. Best for dynamic or personalized content (e-commerce, feeds).
SSG — HTML at build time, served from a CDN. Ideal for blogs, docs, landing pages. Fastest TTFB.
ISR — SSG that revalidates in the background. The pragmatic 2026 default: static speed, fresh-enough data.

The non-negotiable, regardless of framework: your title, meta description, H1, canonical, internal links, and structured data must exist in the server HTML — not be painted in afterward. That's what lands cleanly in the index with zero dependency on a successful render.

A few concrete gotchas:

Use the History API for SPA routing, not URL fragments — Googlebot can't reliably resolve #/ routes.
Fingerprint your assets (main.2bb85551.js). Googlebot's Web Rendering Service caches aggressively and may serve stale JS/CSS otherwise.
Web components get flattened (shadow + light DOM), but only what's in the rendered HTML is indexable.

Stop trusting your own crawler

This is the mistake I see most. Teams run Screaming Frog or Sitebulb in render mode, see their content, and conclude "we're fine." But that only proves your tool rendered it — with its engine, its timeouts, its settings. It says nothing about what Google rendered or chose to keep.

The source of truth is Search Console:

URL Inspection shows Google's own rendered HTML, the resources it loaded, and any JS exceptions it hit.
The Page Indexing report gives the verdict per URL, at scale.

On a big JS site the real question isn't "is this one URL rendered right?" — it's "what share of my JavaScript-dependent pages is actually indexed, and under which exclusion reasons?" You answer that by bulk-inspecting your sitemap URLs against the official inspection data, not by re-rendering locally.

A 2026 checklist

[ ] SEO-critical content (title, H1, canonical, links, schema) is in the initial HTML
[ ] No noindex in the served HTML that you intend to flip with JS
[ ] SPA routing uses the History API; missing pages return a real 404 server-side
[ ] Assets are content-fingerprinted
[ ] You verify indexation in Search Console, not your own crawler
[ ] Anything ranking-critical uses SSR/SSG/ISR, not pure CSR

None of this requires abandoning your framework. It requires being deliberate about where your HTML is generated for the pages that need to rank.

If you'd rather have someone pressure-test your stack, this is exactly the kind of thing a technical SEO team digs into — and running a free SEO audit is a fast way to see which of your JS pages Google is quietly dropping before you refactor anything.

Written by Garvit Sharda. I work with COM8 STUDIO, a digital marketing and web agency, on technical SEO and front-end performance.

The 2026 AI-Crawler Reality Check: What the Data Says for Developers

Garvit Sharda — Fri, 24 Jul 2026 09:18:57 +0000

Everyone's writing think-pieces about "optimizing for AI search." I wanted numbers. So I pulled together the 2025-2026 data from Cloudflare, Vercel/MERJ, Ahrefs and the AI providers' own docs. Some of it genuinely changed how I build sites. Here's the reality check, dev to dev.

1. The AI crawlers do not run your JavaScript

This is the big one. A Vercel/MERJ analysis of 500M+ crawler fetches found that none of the major dedicated AI crawlers execute JavaScript — not OpenAI's GPTBot/OAI-SearchBot/ChatGPT-User, not Anthropic's ClaudeBot, not PerplexityBot, not Meta or ByteDance's Bytespider. They fetch your raw HTML and leave. They do download JS files (~11.5% of ChatGPT's fetches, ~23.8% of Claude's) — they just never run them.

The exception is Google: its Web Rendering Service is shared across Search and Gemini, so Google-Extended renders JS the same way Googlebot does.

Translation: if your content only exists after client-side hydration, every AI engine except Google sees an empty shell.

# see what the bots see
curl -A "GPTBot" https://yoursite.com/page | grep "your headline"

If that's empty, you need SSR, SSG, or prerendering.

2. AI crawl traffic is exploding — and barely sends anything back

Cloudflare's data shows AI crawler activity up sharply year over year, with GPTBot's volume up ~305% and reaching ~11.7% of all crawler requests by mid-2025. But roughly 86% of that crawling is for model training, not live search retrieval.

And the referrals? Lopsided doesn't cover it. Measured crawl-to-referral ratios hit ~38,065:1 for Anthropic and ~1,091:1 for OpenAI. They read enormously, cite rarely. AI tools still send under 1% of outbound web traffic today.

3. The SERP is going zero-click

By early 2026, roughly 68% of Google searches ended without a click, and pages with an AI Overview above them saw click-through drop by around 60%. Being "on page one" is worth less every quarter; being the cited source is worth more.

4. Two overhyped tactics, with the data attached

llms.txt: adoption grew ~8.8x, but in one May 2026 measurement 97% of llms.txt files received zero requests. OpenAI, Anthropic and Google all point site owners to robots.txt instead. Add it if you like — it's a cheap static file — but don't expect it to do the work.
Schema/JSON-LD as a citation hack: controlled analysis found schema presence does not independently predict AI citation once you correct for content quality. Schema still earns rich results and disambiguates entities — just don't treat it as a magic AI-ranking lever.

What actually moves the needle

Boring, durable engineering:

Server-render your content — verify with curl, not DevTools.
Allow the retrieval bots you want cited by in robots.txt; block only what you must.
Answer-first, semantic HTML — clean headings, real lists, a direct answer per section.
Core Web Vitals, INP included — fast pages get crawled more thoroughly.

None of this is a hack. It's the same discipline as good, crawlable web engineering — which is why developers, not marketers, tend to be the ones who move AI visibility. It's the technical backbone of modern AI SEO and it overlaps almost entirely with classic technical SEO.

Build for the crawler that can't run your JavaScript, and you're ready for whatever the answer engines do next.

Sources: Cloudflare Radar, Vercel/MERJ crawler study, Ahrefs brand-mentions analysis, and OpenAI/Anthropic/Google bot docs (2025-2026).

How AI Crawlers Actually Read Your Site: A Developer's Guide to GEO & llms.txt (2026)

Garvit Sharda — Mon, 20 Jul 2026 06:19:12 +0000

Your users increasingly don't scroll ten blue links anymore. They ask ChatGPT, Perplexity, or Google's AI Overview a question and read one synthesized answer. For that answer to mention your site, a machine has to crawl it, parse it, and decide your content is worth quoting.

That whole pipeline is Generative Engine Optimization (GEO) — and a surprising amount of it lives in the part of the stack developers own, not the marketing team.

Here's the one-line version: treat AI crawlers like a browser that never runs your JavaScript, and hand them clean, server-rendered, well-structured HTML. Everything below unpacks what that means in practice.

Meet the bots already hitting your server

Open your access logs and you'll find a new class of user-agents. They fall into two jobs:

Training / indexing crawlers — GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, and Google-Extended (a token that controls whether your content is used for Gemini/AI, separate from Googlebot).
Live "user-triggered" fetchers — OAI-SearchBot and ChatGPT-User, Claude-User, Perplexity-User. These hit your page in real time when someone's prompt needs a fresh source.

You control access to all of them from robots.txt:

User-agent: GPTBot
Allow: /

User-agent: Google-Extended
Disallow: /private

Blocking them keeps you out of training data and out of the answers your customers now read. For most businesses, being cited is the goal — so allow the retrieval bots deliberately.

The big one: most AI crawlers don't run your JavaScript

Googlebot renders JavaScript with an evergreen Chromium engine. Most AI-specific crawlers do not. They largely fetch your raw HTML response and move on. If your content only appears after a client-side framework hydrates in the browser, there's a real chance the bot sees an empty <div id="root"> and nothing else.

Test it the way the bot does — no browser, no JS:

curl -A "GPTBot" https://yoursite.com/your-page | grep "the headline you expect"

If your key content isn't in that response, AI engines probably can't read it. The fixes are the ones you already know:

SSR or SSG (Next.js, Nuxt, Astro, SvelteKit) so HTML ships with content in it.
Prerender / dynamic rendering for legacy SPAs you can't fully migrate.
Keep the important text in the initial HTML, not lazy-loaded behind an interaction.

This single architectural choice separates sites that get quoted from sites that are invisible to the models.

Structure your HTML so a machine can extract answers

Once the bytes arrive, the model has to understand them. Semantic, answer-first HTML is the highest-leverage, least-hyped tactic here:

One <h1>, then a logical <h2>/<h3> outline that reads like the questions people actually ask.
Lead each section with a direct, self-contained answer, then expand. Models lift clean, standalone sentences far more readily than points buried in a wall of text.
Use real <ul>, <ol>, and <table> elements. Structured facts extract cleanly; <div> soup does not.

Add JSON-LD structured data (Organization, Article, FAQPage, BreadcrumbList, Product). Whether schema directly boosts AI citations is still genuinely debated, and I won't oversell it — but it's cheap, it powers traditional rich results, and it removes ambiguity about what your entities are. Clean signals never hurt.

llms.txt: add it, but don't believe the hype

llms.txt is a proposed standard (introduced by Jeremy Howard in late 2024): a Markdown file at /llms.txt that gives models a curated map of your most important content, minus the nav and cruft.

The honest status in 2026: adoption among docs and dev-tool sites is real, but no major AI provider has publicly confirmed they consume it, and skeptics (including voices at Google) have compared it to the old keywords meta tag. Server logs rarely show the big crawlers fetching it.

My take as a developer: it costs ten minutes and a static file, so add it — but treat it as a nice-to-have, not the thing that gets you cited. Your rendered HTML is still what matters.

Speed is still a ranking and crawling signal

Core Web Vitals didn't go away. INP (Interaction to Next Paint) replaced FID in 2024 as the responsiveness metric, joining LCP and CLS. Fast, server-rendered pages get crawled more thoroughly and are less likely to time out a bot mid-fetch. The performance work you do for users pays off again for machines.

The practical GEO checklist

If you do nothing else, ship these:

Server-render your content — verify with curl, not just DevTools.
Allow the AI retrieval bots you want to be cited by in robots.txt.
Answer-first sections under a clean heading hierarchy.
JSON-LD for your core entities.
Meet Core Web Vitals, INP included.
Drop an llms.txt — low effort, possible upside.

None of this is a growth hack. It's the same discipline as good, crawlable web engineering — which is exactly why developers, not marketers, are often the ones who move the needle on it. This groundwork is the technical core of modern AI SEO, and it overlaps almost entirely with classic technical SEO: fast, semantic, server-rendered pages that both humans and machines can actually read.

Build for the crawler that can't run your JavaScript, and you'll be ready for whatever the answer engines do next.

Getting Your Site Cited by AI Search in 2026: A Front-End Developer's Checklist

Garvit Sharda — Thu, 16 Jul 2026 05:32:53 +0000

AI answer engines — Google's AI Overviews, ChatGPT Search, Perplexity, Gemini — increasingly answer users without a click. For developers, that shifts the goal: it's no longer only "rank the page," it's "be the source the model quotes." The good news is that a lot of what makes a site citable is squarely front-end and infra work. Here's the checklist my team actually uses.

1. Server-render anything you want cited

LLM crawlers are far better at parsing HTML that exists before JavaScript runs. If your key content only appears after client-side hydration, assume it won't be reliably read.

Prefer SSR or static generation (Next.js, Astro, Nuxt, etc.) for content pages.
Verify what the bot actually sees:

curl -sL https://example.com/page | grep -i "your answer text"

If your content isn't in that output, a crawler probably can't see it either.

2. Ship structured data (JSON-LD)

Schema doesn't guarantee a citation, but it makes your page cheaper for a machine to parse and reuse. Add Article, FAQPage, HowTo, Organization, and BreadcrumbList where relevant:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "What is answer-engine optimization?",
    "acceptedAnswer": { "@type": "Answer", "text": "..." }
  }]
}
</script>

Validate with Google's Rich Results Test before shipping.

3. Write answer-first, chunk-friendly HTML

Models extract self-contained passages. Structure content so each section stands alone:

Put the direct answer in the first one or two sentences of a section, then expand.
Use real semantic headings (<h2>/<h3>) phrased as questions.
Short paragraphs, genuine lists, and tables beat walls of text.

4. Actually let the AI crawlers in

You can't be cited if you block the bots. Check your robots.txt — plenty of teams block these without realizing:

User-agent: GPTBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

(Google-Extended governs Gemini/Vertex grounding and training — decide deliberately rather than by accident.)

5. Consider an llms.txt

An emerging convention: a root-level /llms.txt that points models at your cleanest, most important content:

# Example Co
> One-line description of what we do.

## Docs
- [Getting started](https://example.com/docs): setup guide
- [API reference](https://example.com/docs/api): endpoints

It isn't universally consumed yet, but it's cheap to add and forward-looking.

6. Keep it fast and stable

Core Web Vitals still matter — for users, for classic SEO, and because slow, unstable pages get crawled less. Aim for LCP < 2.5s, INP < 200ms, CLS < 0.1.

7. Measure citations, not just clicks

This is the hard part: an AI citation often produces no referral in analytics. Track it directly — run your target prompts across ChatGPT, Perplexity, and Google's AI Mode on a schedule and log whether (and how) you appear. Then watch the small-but-high-intent referral traffic that AI does send.

Where this nets out

None of this replaces fundamentals — crawlability, real authority, and genuinely useful content still underpin everything. But the front end is where a surprising amount of "AI visibility" is won or lost. If you want a second pair of eyes on the technical and content side, this is the kind of answer-engine optimization work we do day to day, and a quick free SEO audit tends to surface the crawlability and schema gaps fastest.

What are you doing to make your sites citable? Curious what's working for others.

Conversion Rate Optimization for Developers: Front-End Changes That Actually Move the Needle

Garvit Sharda — Sat, 11 Jul 2026 19:10:01 +0000

Marketing teams obsess over conversion rate. Developers usually treat it as somebody else's metric. That is a mistake — a huge share of what decides whether a visitor converts is settled in the front-end: how fast the page paints, how the form behaves, and how little friction stands between intent and action.

Here are the front-end changes that, in my experience, actually move conversion — not vanity tweaks.

1. Speed is a conversion feature, not just an SEO one

Every study on this says the same thing: conversion rate drops as load time climbs, and the fall is steepest in the first few seconds. A checkout that takes 5s to become interactive loses buyers who would have completed at 2s. So the same Core Web Vitals work you do for rankings pays a second dividend at the cash register. Prioritise the Largest Contentful Paint element, defer third-party scripts until interaction, and keep the main thread free so taps respond instantly.

2. Fix your forms — this is where money leaks

Forms are the highest-leverage surface on any lead-gen or checkout page:

Use the correct type and autocomplete tokens (email, tel, one-time-code, cc-number). Mobile keyboards and autofill do half the work for the user.
Validate inline on blur, not only on submit. Telling someone their email is wrong after they hit submit is the fastest way to lose them.
Never disable the submit button waiting for "perfect" input — let them submit and show clear, specific errors.
Cut every field you do not truly need. Each optional field measurably lowers completion.

<input
  type="email"
  name="email"
  autocomplete="email"
  inputmode="email"
  required
  aria-describedby="email-err"
/>

3. Kill layout shift and interaction jank

Cumulative Layout Shift is not just a Core Web Vitals metric — a button that jumps as an ad loads causes mis-taps and rage clicks. Reserve space for media, ads, and embeds with explicit dimensions or aspect-ratio, and never inject content above content the user is already reading.

4. Make the primary CTA unmissable and honest

One primary action per screen, high contrast, describing what happens ("Get my free audit", not "Submit"). Secondary actions get secondary styling. If a user has to hunt for the button, you have already lost some of them.

5. Instrument everything — measure, do not guess

You cannot optimise what you do not track. Fire structured events for form starts, field abandonment, CTA clicks, and completions. The gap between "form started" and "form completed" is a treasure map of exactly where users drop. The teams we work with treat CRO and conversion-focused web development as a single discipline precisely because the fixes live in the code, but the priorities come from the data.

6. A/B test without tanking performance

Client-side testing tools are notorious for causing flicker (FOOC — flash of original content) and adding render-blocking JS, which reduces the very conversions you are trying to lift. Prefer server-side or edge experiments where you can, keep the variant logic tiny, and always measure the performance cost of the testing tool itself.

A realistic workflow

Instrument the funnel and find the biggest drop-off.
Form a hypothesis about why (usually friction, confusion, or speed).
Ship the smallest front-end change that tests it.
Measure against a real baseline, not a gut feeling.
Keep the winners, revert the losers, repeat.

This is unglamorous, iterative work, but it compounds. We have documented the impact of this exact loop in our case studies — small, disciplined front-end changes adding up to double-digit conversion gains.

TL;DR

Fast pages convert better — reuse your Core Web Vitals work.
Forms are where money leaks: correct input types, inline validation, fewer fields.
Reserve space to stop layout shift and mis-taps.
One clear, honest primary CTA per screen.
Instrument the funnel; optimise the biggest drop-off first.
A/B test without adding render-blocking flicker.

Conversion is not a marketing-only concern. It is a front-end responsibility — and one of the highest-ROI things you can ship.

Written by the team at COM8 STUDIO — a digital marketing and web development agency helping brands across the UAE and US turn traffic into customers.

Structured Data in 2026: How Developers Get Their Content Cited by AI Search

Garvit Sharda — Sat, 11 Jul 2026 12:45:20 +0000

Search is splitting in two. Classic blue links are still there, but a growing share of queries now get answered directly — by Google's AI Overviews, and by ChatGPT, Perplexity, and Claude. For developers, the practical question is: what do you put in your HTML so a machine can confidently extract and cite your content?

The answer is mostly structured data — Schema.org vocabulary expressed as JSON-LD. It is the same technology that has powered rich results for years, but it matters more than ever now that LLM-based answer engines lean on it to understand entities and relationships.

Here is a developer-focused rundown.

Why JSON-LD (not Microdata or RDFa)

You can express Schema.org three ways, but JSON-LD wins for one reason: it lives in a single <script> block, decoupled from your markup. You do not have to thread itemprop attributes through your components, and it is trivial to generate from the same data you already render.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Acme Co",
  "url": "https://acme.example",
  "logo": "https://acme.example/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/acme",
    "https://twitter.com/acme"
  ]
}
</script>

Google, Bing, and the crawlers behind AI answer engines all parse this block first.

The schema types worth your time

You do not need all 800+ Schema.org types. In practice, 90% of the value comes from a handful:

Organization / LocalBusiness — who you are, your logo, address, and sameAs links to your social and authority profiles. This is what builds your entity in the knowledge graph.
WebSite with SearchAction — enables the sitelinks search box.
Article / BlogPosting — author, datePublished, headline, image. Critical for being cited as a source.
BreadcrumbList — helps crawlers understand site hierarchy.
FAQPage — pairs a question with an answer, which answer engines love to lift verbatim.
Product / Offer and Review / AggregateRating — commerce rich results.

The sameAs trick for entity SEO

If you do one thing, do this: add a complete sameAs array to your Organization schema, pointing at every authoritative profile you own — LinkedIn, Crunchbase, GitHub, Wikidata if you have it. This is how you tell machines "all of these identities are the same entity," which is the foundation of answer engine optimization. Without a strong entity, you do not get surfaced in generated answers.

Validate before you ship

Never hand-write JSON-LD and hope. Two free tools:

Schema.org Validator (validator.schema.org) — catches vocabulary errors.
Google Rich Results Test — tells you which rich results you actually qualify for.

Wire the validator into CI if structured data is business-critical. A single malformed date or missing required field silently disqualifies you from rich results.

Generating schema in a component framework

The clean pattern in React/Next.js, Vue/Nuxt, or Astro is to build the object server-side and serialize it once:

export function ArticleSchema({ post }) {
  const json = {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    headline: post.title,
    datePublished: post.publishedAt,
    author: { "@type": "Person", name: post.author },
    image: post.coverImage,
  };
  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(json) }}
    />
  );
}

Serialize with JSON.stringify (not a template literal) so quotes and special characters escape correctly — a classic source of invalid markup.

Rendering matters: do not hide it behind client-side JS

Answer-engine crawlers are far less patient than Googlebot about executing JavaScript. If your JSON-LD is injected only after hydration, some crawlers will not see it. Server-render or statically generate your structured data. This is the same crawlability principle that underpins all technical SEO — if a bot cannot cheaply read it, it does not count. When we run a technical SEO audit, missing or client-only structured data is one of the most common issues we flag.

TL;DR

Use JSON-LD in a <script type="application/ld+json"> block.
Prioritise Organization, Article, FAQPage, BreadcrumbList.
Build a complete sameAs array — it is the backbone of entity and answer-engine SEO.
Validate (Schema.org Validator + Rich Results Test), ideally in CI.
Server-render it so every crawler sees it.

Structured data used to be about star ratings in the search results. In 2026 it is about whether an AI names you as the source. Ship it.

Written by the team at COM8 STUDIO — a digital marketing and web development agency specialising in SEO, AEO/GEO, and web engineering for brands across the UAE and US.

Core Web Vitals in 2026: A Front-End Checklist That Also Boosts SEO

Garvit Sharda — Sat, 11 Jul 2026 11:50:28 +0000

Performance work used to be the thing front-end teams did "if there was time left." In 2026 it is table stakes. Core Web Vitals are a confirmed Google ranking input, and real users bounce from anything that feels sluggish on a mid-range Android phone over a flaky mobile connection.

This is the checklist I keep coming back to when I audit a site. It is written for developers, but every item also moves the SEO needle — which is exactly why performance and search visibility have stopped being two separate conversations.

The three metrics that actually matter

Largest Contentful Paint (LCP) — aim for under 2.5s. This is almost always your hero image or main headline. Quick wins: serve correctly sized images in AVIF/WebP, add fetchpriority="high" to the LCP image, preload the hero font, and remove render-blocking CSS from the critical path.

Interaction to Next Paint (INP) — aim for under 200ms. INP replaced First Input Delay in 2024 and it is far less forgiving. It measures the latency of every interaction on the page, not just the first one. Wins: break up long tasks, yield back to the main thread, debounce expensive handlers, and push non-urgent work into requestIdleCallback or a web worker.

Cumulative Layout Shift (CLS) — aim for under 0.1. Wins: set explicit width/height or aspect-ratio on all media, reserve space for ads and embeds, and never insert content above content that has already rendered.

The checklist

Images

Convert to AVIF with a WebP fallback.
Use responsive srcset/sizes so phones never download desktop-sized artwork.
Lazy-load everything below the fold with loading="lazy" — but eager-load the LCP image.

Fonts

Self-host and subset your fonts. A third-party font CDN adds a DNS lookup and a connection you do not control.
Use font-display: swap so text paints immediately.
Preload only the one or two weights you actually use above the fold.

JavaScript

Audit the bundle. A brochure or marketing site rarely needs 400KB of JS.
Code-split by route and defer everything non-critical.
Swap heavy date/utility libraries for native APIs (Intl, structuredClone, URLSearchParams).
Delay third-party tags — chat widgets, analytics, heatmaps — until the first user interaction. These are the number-one INP killers I see in real audits.

Delivery

Serve over HTTP/2 or HTTP/3 from a CDN.
Set a long Cache-Control for hashed static assets.
Turn on Brotli compression.

Measure the way Google measures

Lab tools like Lighthouse are great for catching regressions in CI, but Google ranks on field data — the Chrome User Experience Report (CrUX) gathered from real Chrome users. A site can score a perfect 100 in Lighthouse and still fail Core Web Vitals in the field, because your actual visitors are on slower devices and worse networks than your dev laptop.

So run all three:

Lighthouse in CI to catch obvious regressions before they ship.
The web-vitals npm package in production, streaming real INP/LCP/CLS into your analytics.
The Core Web Vitals report in Search Console — that is the CrUX data Google actually ranks on.

Why front-end performance is an SEO strategy

Here is the part the product and marketing side cares about: faster pages rank higher and convert better. Google has said plainly that Core Web Vitals act as a tiebreaker between pages of comparable relevance, and the correlation between a slow LCP and a high bounce rate is brutal. Every 100ms you shave off is measurable revenue on a commerce or lead-gen site.

That overlap is why the teams I work with treat performance budgets and technical SEO as a single workstream instead of two competing backlogs. When engineering owns Core Web Vitals, the SEO team stops filing tickets for problems the front-end already fixed.

If you want an outside read on where a site currently stands, a structured free SEO audit will surface the CWV failures, crawl and indexation issues, and rendering problems in one pass — and, satisfyingly, most of the recommended fixes land right back in the front-end checklist above.

A note on frameworks

None of this is framework-specific, but a few defaults help. Next.js and Nuxt give you image optimization and route-level code splitting for free. Astro and other "islands" frameworks ship near-zero JS by default, which is fantastic for content sites. SvelteKit and SolidStart compile away a lot of runtime overhead. Whatever you use, the metrics do not care about your framework — they care about bytes, main-thread time, and layout stability.

TL;DR

LCP < 2.5s — optimize hero image + font
INP < 200ms — break up long tasks, defer third-party JS
CLS < 0.1 — reserve space for media and ads
AVIF/WebP + responsive images
Self-hosted, subset fonts
Route-based code splitting
CDN + Brotli + HTTP/3
Measure field data, not just Lighthouse

Performance is a feature. Budget for it, measure it in the field, and ship it like one.

Written by the team at COM8 STUDIO — a digital marketing and web development agency working with brands across the UAE and US.