Experience Edge best practices

Avoid exposing your Context ID to the browser

The Preview GraphQL API and the Delivery GraphQL API require a Context ID for authenticating requests to Sitecore from your front-end app. If your app makes GraphQL requests directly from the browser (client-side JavaScript), the Context ID is visible in network traffic and browser developer tools, where anyone can view and reuse it to query your Sitecore content.

Client-side queries could occur in, for example, a search-as-you-type user interface or when lazy-loading personalized content.

To protect your Context ID, keep it on the server and never let it reach the browser. You can do this by routing queries through a serverless function, an API route, or a similar server-side proxy. This way, the browser calls your proxy (such as your own API route like /api/search), and the proxy makes the GraphQL request using the Context ID. This ensures that the browser never sees the Context ID because the ID never leaves the server.

For static or server-rendered content, you don't need an explicit proxy because the GraphQL request never leaves the server in the first place.

Test large queries on both Preview and Delivery

Because query complexity is calculated differently between the Preview GraphQL API and the Delivery GraphQL API, we recommend you validate important queries against both endpoints, especially when they are near query complexity limits.

Don't include global data in page queries

In the layout data returned by the Preview GraphQL API and the Delivery GraphQL API, the rendering data is bundled together with the specific page it represents. If you embed global data, such as navigation menus or footer links, into that page-level output, then any change to that global data, such as renaming a navigation item, forces you to republish every single page that includes it. This is because the cache for each page must be invalidated and regenerated.

Instead, retrieve that global data separately, using a dedicated GraphQL query. This way, a navigation change only requires updating the result of that one query instead of triggering a full site republication.

If you put global data in the Layout service output for pages, a data change requires a republication. For example, navigation data used in page headers and footers. Consider using GraphQL calls from your rendering host to get this data instead.

Use variables in GraphQL queries

Pass dynamic values as variables rather than embedding them directly in the query string. Variables keep the query structure separate from its data, which reduces string-concatenation risks and makes client and server behavior safer and more predictable. A query that uses variables also has a stable string across requests, so the GraphQL server can reuse the parsed and validated query document instead of re-parsing each new string. That reuse is a performance optimization that reduces parse and validation overhead.

Give each query a consistent, descriptive operation name. Keep the name static for the same query shape to maximize cache hits unless you intentionally need separate cache behavior. A stable name like LayoutQuery also makes it easier to identify slow or failing queries in server logs, tracing tools, and analytics.

Exclude internal sites from Experience Edge

You might have internal, non-production sites in SitecoreAI. To prevent those sites and their content from being available via the Delivery GraphQL API, you can mark them as internal.