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

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.

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.

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.

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.

Performance Testing Tools

• PageSpeed Insights: Test Core Web Vitals for your headless pages
• Web Page Test: Detailed waterfall analysis of rendering performance
• SEO Fix in a Box: My Wix app. Free to install, it scans your site and shows what needs fixing, and paid plans write the fixes from your own Google searches