Rendering strategies: SSG, ISR and SSR for maximum SEO impact

Module 43: Wix Headless SEO | Lesson 493 of 688 | 48 min read

The rendering strategy you choose for your headless Wix frontend directly impacts how search engines crawl your pages, how fast they load, and how they rank. This lesson breaks down SSG, ISR and SSR with real SEO implications for each.

Static Site Generation (SSG) for Maximum Speed

SSG pre-renders every page at build time, creating static HTML files that load instantly from a CDN. For SEO, this means the fastest possible Time to First Byte (TTFB), perfect Largest Contentful Paint (LCP) scores, and guaranteed crawlability since Googlebot receives fully rendered HTML with zero JavaScript execution required.

Server infrastructure powering Wix headless SSG ISR and SSR rendering strategies — Choosing the right rendering strategy (SSG, ISR or SSR) directly impacts how search engines crawl and rank your headless Wix pages.

SSG works best for content that does not change frequently: blog posts, product category pages, about pages and landing pages. With Wix headless, your build process fetches all CMS content via the Wix API and generates HTML at deploy time.

Incremental Static Regeneration (ISR) for Scale

ISR combines the speed of SSG with the freshness of dynamic content. Pages are statically generated but can be revalidated in the background when stale. For a Wix eCommerce site with thousands of products, ISR means you do not need to rebuild every page when one product changes. The page serves from cache while a new version generates in the background.

From an SEO perspective, ISR provides near-identical benefits to SSG but with fresher content. Set your revalidation period based on how often your content changes: 60 seconds for product prices, 3600 seconds for blog posts, 86400 seconds for static pages.

Server-Side Rendering (SSR) for Real-Time Data

SSR generates HTML on every request. This is necessary when content must be real-time: personalised pages, search results pages, or pages displaying live inventory. The SEO trade-off is a higher TTFB compared to SSG/ISR since the server must generate HTML before responding.

SEO Best Practice: Use SSG or ISR for 90% of your pages and reserve SSR only for pages that genuinely need real-time data. This gives you the best balance of SEO performance and content freshness.

Choosing the Right Strategy Per Page Type

Homepage: ISR with 300s revalidation for fresh content blocks
Blog posts: SSG at build time, rebuild on publish via webhook
Product pages: ISR with 60s revalidation for price/stock updates
Category pages: SSG with rebuild on category changes
Search results: SSR with pagination and canonical tags
Member dashboards: SSR with noindex (no SEO value)
Landing pages: SSG for maximum speed and conversion

Implementing Rendering Strategies with Wix APIs

How to implement ISR for Wix product pages in Next.js

In your Next.js App Router project, create the file app/products/[slug]/page.tsx to handle individual product pages with a dynamic slug parameter.
At the top of the file, export an async generateStaticParams function that calls the Wix eCommerce API to fetch all product slugs and returns them as an array of param objects.
In the default page component, accept params as a prop, extract the slug, and call the Wix stores API to fetch the matching product: const product = await products.getProductBySlug(params.slug).
Export the constant export const revalidate = 60 at the top of the file to enable ISR with a 60-second revalidation window for price and stock updates.
Add export const dynamicParams = true below the revalidate export so that new products added in Wix after the last build are generated on-demand on first visit and then cached.
Build the JSON-LD Product schema object inside the component using data from the Wix API response, mapping name, description, price, currency and availability to Schema.org properties.
Inject the schema as a <script type="application/ld+json"> tag inside a Next.js <Head> component or the metadata API to ensure Googlebot receives it in the initial HTML.
Optimise product images by constructing Wix Media CDN URLs with the format: media.wixstatic.com/media/[id]/v1/fill/w_800,h_600,q_80,enc_auto/image.jpg for each product image.
Run npm run build locally to confirm generateStaticParams succeeds and the first batch of product pages are generated without errors.
Use the Google Search Console URL Inspection tool on a deployed product page URL to verify Googlebot receives fully rendered HTML including the product title, price and schema markup.

Common Mistake: Do not use client-side data fetching for content that needs to be indexed. If product details load via useEffect after the page renders, Googlebot may see an empty page. Always fetch SEO-critical data on the server.

How to Choose the Right Rendering Strategy for Your Headless Wix Site

Use this decision workflow to assign the correct rendering strategy to every page type on your headless Wix frontend.

Assigning rendering strategies to each page type in your headless Wix project

Open a spreadsheet and list every distinct page type on your headless Wix site: homepage, blog post, product page, product category, service page, about page, search results, member dashboard and any custom CMS pages.
For each page type, answer three questions: Does it need real-time data? Does the content change frequently? Is it personalised per user? Use these answers to determine the appropriate rendering strategy.
Mark all pages that require real-time personalisation (member dashboards, cart pages, order history) as SSR with export const dynamic = "force-dynamic" in your page.tsx file.
Mark pages with frequently changing data (product prices, stock levels, blog feeds) as ISR. Set revalidate to match the update frequency: 60 for prices, 300 for blog feeds, 3600 for less volatile data.
Mark all static content pages (about, contact, static landing pages) as SSG with export const dynamic = "force-static". These pages should never change without a new deploy.
In your Next.js App Router project, open each page.tsx file and add the appropriate export const revalidate = [seconds] or export const dynamic = "force-static" or "force-dynamic" declaration at the top of the file.
For ISR pages, also export a generateStaticParams function that returns all known slugs from the Wix API, so the most important pages are pre-built at deploy time rather than generated on first request.
Test each rendering strategy by running npm run build and checking the build output log. Next.js labels each route as Static (S), Dynamic (D) or ISR (seconds) in the build summary table.
Deploy to Vercel and use Vercel Analytics to monitor the cache hit rate for each ISR route. Aim for a cache hit rate above 80% for product and blog pages to maximise CDN performance.
Set up revalidation webhooks in your Wix dashboard (Dashboard > Settings > Webhooks) that trigger a Next.js on-demand revalidation call whenever a product or blog post is published or updated in Wix.
After 2 weeks in production, review Core Web Vitals in Google Search Console for each page type. If SSR pages show poor LCP, consider migrating them to ISR with a short revalidation window to improve cache coverage.

This lesson on Rendering strategies: SSG, ISR and SSR for maximum SEO impact is part of Module 43: Wix Headless SEO in The Most Comprehensive Complete Wix SEO Course in the World (2026 Edition). Created by Michael Andrews, the UK's No.1 Wix SEO Expert with 14 years of hands-on experience, 750+ completed Wix SEO projects and 425+ verified five-star reviews.