Loading…
Your Full-Service Digital Agency & AI Strategy Partner
Real strategists. Real AI tools. Real growth. — 1Digital® since 2012
Workspace by 1Digital® — the agency platform we built. Coming to select agencies. Join the early-access list →
For Composable & Headless Storefronts
Decoupled storefronts on Hydrogen, Catalyst, Next.js, Remix, and commercetools — SSR/ISR/SSG render strategy, edge sitemap orchestration, schema at the layout, Core Web Vitals, llms.txt, and crawler-equivalent HTML verified per route.
TL;DR
On a monolithic platform, the storefront ships sitemap, schema, canonical, and hreflang for you. On headless, that work moves into your front-end repo — and so does the failure mode. We audit render strategy per route, rebuild sitemap orchestration across services, inject schema at the layout level, and verify crawler-equivalent HTML on every indexable URL. Backed by 14 years on commerce platforms and trusted by 400+ brands with a 4.9/5 rating across 941+ verified reviews.
Render strategy by route
Categories and faceted PLPs where catalog data shifts. Crawlers see fresh content per request. INP risk if hydration tree is large — split with RSC where the framework supports it (Next.js App Router, Hydrogen partial hydration patterns).
PDPs where inventory and pricing tolerate a short revalidation window (60-300 seconds). Best of both: pre-rendered HTML for crawlers, revalidates on demand or on webhook. Watch out for stale Offer prices in JSON-LD — emit price as a server-time read.
About, policy, evergreen marketing, programmatic SEO templates with low update frequency. Smallest TTFB, fastest LCP. Re-deploys on content change — pair with a CMS webhook to trigger CI when editorial updates land.
Pure client-side render is incompatible with reliable SEO. Google's render budget multiplies indexation latency; AI crawlers (GPTBot, ClaudeBot, PerplexityBot) often don't execute JS at all. Reserve CSR for authenticated dashboards, never catalog.
What we own in a headless engagement
Stacks we ship on
We audit and ship SEO on Shopify Hydrogen + Oxygen (Remix + edge), BigCommerce Catalyst (Next.js + Makeswift), commercetools + Next.js, Adobe Commerce headless (REST + GraphQL + Next.js), and Salesforce Commerce Cloud headless via OCAPI / SCAPI. Same playbook across all five: SSR-first render strategy, edge sitemap orchestration, schema at the layout, INP-targeted hydration, and crawler-equivalent HTML verified with Search Console URL Inspection plus rendered-HTML diffs.
Companion services: headless commerce development when engineering capacity is needed, agentic commerce when the storefront also needs to be agent-readable, Hydrogen SEO for Shopify-specific headless, and Catalyst SEO for BigCommerce-specific headless. The cornerstone reference is ecommerce SEO agency.
Engagement shape
Render-strategy review per route. Crawler-equivalent HTML diff. Sitemap orchestration map. Schema coverage. Canonical and hreflang audit. Core Web Vitals baseline (LCP, INP, CLS) per template and route.
Sitemap-index rebuild. Schema graph injection at layout. llms.txt deployment. Canonical and hreflang topology corrections. INP-targeted hydration refactor. GraphQL or OCAPI cache strategy. Edge runtime audit.
Keyword-to-route mapping. Programmatic SEO templates where appropriate. Content briefs and editorial production. AI-engine citation tracking. Iterative INP / LCP work. Monthly reporting against organic sessions + citation share.
Headless commerce SEO is the discipline of making decoupled storefronts — where the front-end framework (Next.js, Remix, Nuxt, SvelteKit) is separated from the commerce backend (Shopify, BigCommerce, Adobe Commerce, commercetools, Salesforce) — indexable, crawlable, and citation-worthy by Google and AI engines. The challenges are render strategy (SSR vs ISR vs SSG vs CSR), edge crawler accessibility, sitemap orchestration across services, structured-data injection at the edge, and Core Web Vitals on stacks where caching strategy is your responsibility, not the platform's.
Default to SSR for category and product pages where catalog data changes and crawlers must see fresh content. Use ISR (Incremental Static Regeneration) for high-traffic PDPs where inventory and pricing can tolerate a short revalidation window (60-300 seconds). Reserve SSG for genuinely static surfaces (about, policy, evergreen marketing). Pure CSR is incompatible with reliable SEO — Google's renderer eventually executes JS but indexing latency multiplies and AI-engine crawlers (ChatGPT, Perplexity) frequently don't execute client JS at all. The right answer is almost always a hybrid: SSR for catalog, ISR for hot PDPs, SSG for static, with strict cache headers per route.
Edge runtimes (Oxygen, Vercel Edge, Cloudflare Workers, Netlify Edge) typically improve crawler experience: lower TTFB means Googlebot's render budget stretches further, INP measurements come in green more reliably, and AI-engine crawlers that allocate strict per-request time get full HTML before their budget expires. Watch out for two pitfalls: (1) edge runtimes have smaller bundle limits than Node, so heavy SDKs can push you back to Node and re-introduce cold-start latency; (2) some edge providers strip or modify headers that crawlers expect (Vary, Cache-Control). We audit edge behavior per route and confirm crawler-equivalent rendering with Search Console URL Inspection and rendered-HTML diffs.
In headless setups, no single service owns the sitemap. Shopify, BigCommerce, or Adobe Commerce only know about catalog routes; your headless front-end adds editorial routes (blog, landing pages, programmatic SEO). The pattern: generate sitemap-index.xml at the front-end origin, with sub-sitemaps for products (queried from Storefront API or GraphQL), collections, content (CMS-driven), and editorial routes. Revalidate on a fixed cadence (every 60 minutes) or on webhook (catalog update). Emit hreflang inside the sitemap, not in <link> tags, because Liquid/template <head> budgets get tight at scale.
JSON-LD must be emitted server-side on every indexable route — that means inside the framework's metadata or head export, not via client-side script tags. In Next.js App Router, that's the generateMetadata() function + dangerouslySetInnerHTML <script type="application/ld+json">. In Remix/Hydrogen, that's the meta export and loader-injected scripts. For Catalyst on BigCommerce, that's Next.js metadata plus loader-fed Product / Offer / Review / BreadcrumbList / FAQPage / Organization graphs. We architect schema at the layout level (Organization, WebSite) and route level (Product, Article, BreadcrumbList) so the JSON-LD travels with the rendered HTML.
Headless storefronts often regress LCP and INP because the team underestimates client-side hydration cost. The common failure modes: (1) hydrating entire PDPs as one React tree blocks the main thread and tanks INP; (2) heavy GraphQL responses inflate LCP because the largest image is gated behind a waterfall; (3) third-party personalization runners (Nosto, Dynamic Yield) ship blocking scripts that push INP past 200ms. Fixes: React Server Components for non-interactive surfaces, image preload hints from the server, deferred personalization with reservation-style layout, and INP-targeted code-splitting at component boundaries.
The headless front-end is the canonical surface, not the headless commerce backend. We emit canonical tags from the front-end's layout or page metadata, never relying on the backend's admin-configured canonical (which often points back at the headless backend's own URL — wrong target). For hreflang, the front-end owns the topology because it controls URL structure. We typically use sitemap-level hreflang annotations for /<locale>/ paths and emit reciprocal links across every market in the ring.
Yes, in two ways. First, AI crawlers (GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Google-Extended) make stricter assumptions about rendered HTML — they typically don't execute JS, so SSR or ISR is non-negotiable. Second, llms.txt placement and content structure matters more on headless because you control the root file directly (the commerce platform doesn't). We deploy llms.txt at the front-end root, structure content for entity extraction in markdown-friendly patterns, and track citation share in ChatGPT Shopping, Perplexity Shop, Google AI Overviews, Gemini, and Microsoft Copilot.
Shopify Hydrogen + Oxygen (Remix + edge), BigCommerce Catalyst (Next.js + Makeswift), commercetools + Next.js, Adobe Commerce headless (REST + GraphQL with Next.js), and Salesforce Commerce Cloud headless via OCAPI/SCAPI. We've shipped on all five and audit SEO across them with a shared playbook: SSR-first render strategy, edge sitemap and llms.txt, schema injection at the layout level, INP-targeted hydration, and crawler-equivalent HTML verification.
Phase 1: render-strategy audit per route (SSR/ISR/SSG/CSR), crawler-equivalent HTML diff, sitemap orchestration review, schema coverage map. Phase 2: canonical and hreflang topology rebuild if needed, llms.txt deployment, Product schema audit, Core Web Vitals work (LCP / INP / CLS). Phase 3: content strategy mapped to catalog, programmatic SEO routes where appropriate, AI-engine citation tracking. We ship code directly into the front-end repo — same team owns both `/audit` and `/commit`.
One team owns render strategy, schema, sitemap orchestration, and the front-end repo.