Skip to main content
How you render and integrate your storefront affects search engine visibility, page performance, and how reliably automated clients (including AI crawlers) can access your content. This guide covers the main rendering approaches used with Elevate integrations, and clarifies what is and isn’t within Elevate’s control.
Elevate’s responsibility is limited to its API: accepting queries and returning correctly formatted results. Rendering strategy, frontend architecture, and resulting SEO or performance outcomes are determined by your own implementation and are outside Elevate’s scope.

​
Rendering approaches

​
Client-side rendering (CSR)

Content is built in the browser via JavaScript after the page loads, typically by calling the Elevate API directly from the client. Considerations:
  • Simpler to implement and iterate on.
  • Content is not present in the initial HTML response, which can delay or limit visibility to crawlers that don’t execute JavaScript.
  • Performance metrics like Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) are directly affected by how loading states are handled, since Elevate’s API response time is only one part of total page render time.

​
Server-side rendering (SSR)

Content is rendered on the server, with the Elevate API called server-side before HTML is returned to the browser. Considerations:
  • Content is present in the initial HTML, improving accessibility for crawlers and reducing dependency on client-side JavaScript execution.
  • Generally more resilient for SEO-sensitive pages such as search results and category listings.
  • Requires more implementation effort and infrastructure than CSR.

​
Headless vs. non-headless (Shopify-native)

On non-headless Shopify setups, storefront pages are typically served by Shopify’s own rendering, with Elevate integrated via client-side calls into that existing page structure. This constrains which rendering approach is practical without deeper platform-level changes.
Elevate does not prescribe or enforce a rendering architecture. These are implementation decisions made by you or your development partner, based on your platform, resources, and priorities.

​
Automated clients and rendering

Not all crawlers execute JavaScript. Search engines like Google generally execute JavaScript, but do so in a second rendering pass: the initial crawl and indexing pass uses only the raw HTML, with JavaScript execution queued separately and subject to delays that vary by site. Many AI-driven crawlers do not execute JavaScript at all, and rely entirely on what’s present in the initial HTML response. If discoverability by these clients matters for your business, ensure critical content, particularly product and category information, is present in server-rendered HTML rather than relying solely on client-side rendering.

See also: Handling bots and crawlers

​
What this means for your implementation

Elevate returns the same data regardless of rendering approach. What varies is how and when that data becomes visible to users, search engines, and other automated clients. SEO outcomes depend on many factors beyond rendering strategy, including content quality, site structure, and backlinks. Rendering approach is one input among many, not a guarantee of outcome either way. Core Web Vitals scores are a function of your frontend implementation, not something Elevate measures, controls, or is responsible for.
Last modified on October 12, 2026