DEV Community: Garvit Sharda

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.