Wix JavaScript rendering issues: when Google cannot see your content

Wix is a JavaScript-heavy platform. Every Wix website relies on JavaScript to render content, build page layouts, load dynamic elements, and power interactive features. While Google has become significantly better at rendering JavaScript over the years, the process is not instantaneous, not always complete, and can introduce SEO risks that do not exist on traditional HTML websites. When Google cannot fully render your Wix pages, entire sections of content can become invisible to search engines, meaning they will never rank for relevant keywords. This lesson explains exactly how Google handles JavaScript rendering, what specific issues affect Wix sites, how to diagnose rendering failures, and the practical steps you can take to ensure Google sees all of your important content.

How Google Renders JavaScript: The Two-Wave Indexing Process

When Googlebot encounters a page, it does not simply read the HTML source code like a traditional crawler. For JavaScript-heavy sites like Wix, Google uses a two-wave indexing process that is fundamentally different from how it handles static HTML sites.

Wave 1: Initial HTML Crawl

In the first wave, Googlebot downloads the raw HTML of your page. For a Wix site, this initial HTML is relatively sparse compared to the fully rendered page: it contains the basic page structure, metadata, some content that Wix server-side renders, and references to JavaScript files that will build the rest of the page. Google extracts what it can from this initial HTML, including title tags, meta descriptions, canonical tags, structured data embedded in the HTML head, and any server-side rendered content.

Wave 2: JavaScript Rendering

In the second wave, Google places the page into a rendering queue. The Web Rendering Service (WRS), which runs a headless Chromium browser, executes the JavaScript on the page to produce the fully rendered DOM (Document Object Model). This is where Google finally "sees" the complete content of your Wix page, including dynamically loaded text, images, navigation menus, and interactive elements. The critical issue is that this second wave can be delayed by hours, days, or even weeks depending on Google's rendering capacity and your site's crawl priority. During this delay, any content that only exists after JavaScript execution is invisible to Google.

Why Wix JavaScript Rendering Matters for SEO

Wix's architecture means that the rendering process is not just a theoretical concern but a practical one that affects real rankings. Several Wix-specific factors make JavaScript rendering particularly important to understand.

• Wix uses a single-page application (SPA) architecture for some navigation, meaning page transitions do not always trigger full page loads. While Wix has implemented solutions for this (such as proper URL changes and History API usage), it can affect how Google perceives page boundaries.
• Dynamic content elements on Wix (repeaters, dynamic pages, filtered content, datasets) all rely on JavaScript to populate. If rendering fails, these elements appear empty to Google.
• Wix Apps (Stores, Bookings, Blog, Events, etc.) inject their content via JavaScript. Product descriptions, blog post content, event details, and booking information all require successful JavaScript rendering to be visible.
• Third-party apps from the Wix App Market add additional JavaScript layers that may not render correctly for Googlebot, potentially hiding the content they display.
• Velo by Wix (custom code) adds another layer of JavaScript that Google must execute. Complex Velo applications with API calls, data queries and conditional rendering are at higher risk of rendering failures.

How to Check What Google Sees vs What Users See

The most important diagnostic skill for Wix JavaScript rendering issues is comparing the rendered page that Google sees against what a normal user sees. There are several methods to perform this comparison, each revealing different aspects of potential rendering problems.

Method 1: URL Inspection Tool Rendered Page

Using GSC URL Inspection to check rendered content

• Open Google Search Console and enter the URL you want to check in the URL Inspection tool at the top of the page.
• Wait for the inspection results to load. Click on "Test Live URL" to get the most current rendering (rather than the cached version).
• Once the live test completes, click "View Tested Page" in the top-right corner of the results.
• You will see three tabs: HTML, Screenshot, and More Info. Click "Screenshot" first to see a visual representation of what Google sees.
• Compare this screenshot carefully against what you see when visiting the page in your browser. Look for missing sections, blank areas, or content that has not loaded.
• Click the "HTML" tab to view the rendered HTML source code. Use Ctrl+F (Cmd+F on Mac) to search for specific text from your page. If important content text is missing from the rendered HTML, Google cannot see it.
• Check the "More Info" tab for any resource loading errors. These errors indicate JavaScript files, CSS files, or API calls that failed during Google's rendering process.

Method 2: Google Cache Check

Search for your page on Google and click the three dots next to the result, then select "Cached" to view the version Google has stored. Compare this against your live page. Missing content in the cached version indicates rendering issues. Note that Google has been phasing out some cache features, so this method may not always be available.

Method 3: Site Search Verification

Use the site: operator in Google Search to verify specific content is indexed. Search for site:yourdomain.com "exact phrase from your page" using a unique phrase from the content you want to verify. If Google returns the page, that content was successfully rendered and indexed. If Google returns no results, the content may not have been rendered or indexed.

Common Wix JavaScript Rendering Problems

Understanding the specific rendering issues that affect Wix sites helps you proactively prevent them. These are the most common JavaScript rendering problems we see on Wix websites.

Lazy-Loaded Content Below the Fold

Wix uses lazy loading for images and some content sections that are below the initial viewport. While Google's renderer does scroll pages to trigger lazy loading, it does not always scroll far enough or wait long enough for all lazy-loaded content to appear. Content far down a long page is at higher risk of not being rendered. If you have important SEO content (keyword-rich text, product details, FAQ sections) positioned very low on a long page, consider moving it higher in the page layout or ensuring it loads without lazy loading.

Dynamic Elements That Require User Interaction

Any Wix content that only appears after a user action (clicking a tab, expanding an accordion, selecting a filter, scrolling a carousel) is at risk of not being rendered by Google. Googlebot does not click buttons, expand accordions, or interact with page elements. Content hidden behind tabs, accordion panels, lightbox pop-ups, or interactive widgets may remain invisible to Google.

AJAX Content and API-Dependent Elements

Wix dynamic pages and elements that fetch data from Wix Data Collections or external APIs via AJAX calls present a rendering risk. If the API call takes too long, fails, or requires authentication, the content will not appear when Google renders the page. Velo code that fetches data from external APIs is particularly susceptible to this issue because the external API must respond quickly enough for Google's rendering timeout.

Pop-Ups and Lightbox Content

Wix lightboxes and pop-ups are rendered via JavaScript and typically require user interaction (or a time delay) to appear. Google does not wait for timed pop-ups and does not click triggers to open lightboxes. Any content exclusively inside a Wix lightbox will not be rendered or indexed by Google. Never put important SEO content inside lightboxes.

Third-Party App Rendering Failures

Apps installed from the Wix App Market add their own JavaScript to your pages. Some apps render content client-side only, meaning the content they display may not be visible to Google. Common examples include third-party review widgets, social media feed embeds, live chat widgets with content, custom form builders, and interactive calculators. If an app provides critical content (not just functionality), verify that Google can see the content using the URL Inspection tool.

Wix Server-Side Rendering (SSR) and Its Limitations

Wix has invested heavily in server-side rendering (SSR) to mitigate JavaScript rendering issues. Wix SSR pre-renders critical page content on the server before sending it to the browser, meaning Google receives some content in the initial HTML without needing to execute JavaScript. This is a significant advantage over many other JavaScript-heavy website builders.

• Wix SSR renders critical content elements including page titles, headings, body text, image alt attributes, meta tags and structured data in the initial HTML response.
• Wix Blog posts, Stores product descriptions, and other native Wix app content benefit from SSR, making them more reliably indexed.
• Dynamic page content from Wix Data Collections is SSR-rendered when using native Wix dynamic pages.
• However, SSR has limitations: interactive elements, elements with conditional visibility, Velo-injected content, and some third-party app content are NOT server-side rendered.
• Custom Velo code that runs in the onReady() function may execute on the server (via SSR) but code that depends on user interaction or browser-specific APIs will only run client-side.
• The SSR output can differ from the fully client-rendered page, particularly for personalised content, geolocation-dependent content, or user-state-dependent content.

How to Verify Googlebot Can Access Critical Content

Comprehensive rendering verification process

• Make a list of your 20 most important pages (highest traffic, highest revenue, key landing pages).
• For each page, identify the critical SEO content: headings, product descriptions, service details, FAQ content, pricing information, and any text that targets your primary keywords.
• Use the URL Inspection tool's "View Tested Page" screenshot and HTML tabs to verify each piece of critical content is visible to Google.
• Search Google for site:yourdomain.com "unique phrase" using unique text snippets from each piece of critical content to confirm indexing.
• If any critical content is missing from Google's rendered version, identify why: is it lazy-loaded too far down, hidden behind an interaction, loaded via an external API, or inside a third-party app widget?
• For content Google cannot render, implement one of the workarounds described in this lesson (move content higher, replace interactive elements with static content, use native Wix elements instead of third-party apps).
• After implementing fixes, re-test using URL Inspection to confirm the content is now visible.
• Repeat this verification quarterly to catch any rendering regressions caused by site updates or new app installations.

Velo Code Rendering Considerations

If you use Velo by Wix (formerly Corvid) to add custom functionality, your code introduces additional JavaScript rendering considerations that can directly impact SEO.

• Code in the page onReady() function runs both on the server (SSR) and client. Place critical content-setting code here for the best rendering outcome.
• Code in $w.onReady() runs after the page DOM is ready. Content set here is more likely to be SSR-rendered than content set in event handlers.
• Backend web modules (.jsw files) run only on the server. Use these for data fetching operations to ensure data is available during SSR.
• wixData.query() calls in onReady() are SSR-compatible. Data fetched this way is available in the initial HTML response.
• External fetch() calls may not complete during SSR if the external server is slow. Set timeout limits and have fallback content.
• Avoid using setTimeout(), setInterval(), or requestAnimationFrame() for loading critical content. These are not SSR-compatible and may not execute during Google rendering.
• DOM manipulation via $w() selectors in onReady() is SSR-compatible, but dynamic element creation is not. Prefer data-binding and repeaters over dynamic DOM creation.
• Use wixSeo API methods for programmatic SEO (setting titles, descriptions, structured data) rather than direct DOM manipulation, as these are SSR-aware.

Improving Content Visibility for Googlebot on Wix

Beyond diagnosing problems, there are proactive steps you can take to maximise the amount of content Google can successfully render on your Wix site.

• Place your most important SEO content (target keywords, unique value propositions, key information) in the top portion of the page. Content above the fold has the highest probability of being rendered successfully.
• Use standard Wix text elements rather than custom-coded text rendering. Wix text elements benefit from SSR while custom Velo text rendering may not.
• For product pages, ensure descriptions, specifications, and reviews are rendered using native Wix Stores elements. Avoid replacing these with custom Velo-rendered alternatives unless necessary.
• For blog content, use the native Wix Blog rich text editor. Content created in the Wix Blog is SSR-rendered and reliably indexed.
• Minimise the use of client-side conditional rendering for important content. If you use Velo to show/hide elements based on conditions, Google will only see the default state.
• Ensure all critical images have alt text set in the Wix Editor (not just via JavaScript). Alt text set in the Editor is included in the SSR HTML.
• Use the wixSeo API to set meta tags, structured data, and Open Graph tags programmatically rather than injecting them via custom HTML elements.
• Test your page speed with Google PageSpeed Insights. Extremely slow pages may time out during Google rendering, resulting in incomplete content indexing.

When JavaScript Rendering Completely Blocks Indexing

In some cases, JavaScript rendering issues can completely prevent a page from being indexed. This happens when Google's renderer encounters a fatal error, when critical resources are blocked, or when the rendering process times out. Signs that rendering is blocking indexing include pages stuck in "Discovered - currently not indexed" status despite having quality content, the URL Inspection screenshot showing a blank or error page, and the rendered HTML containing none of your visible page content.

Emergency steps when rendering blocks indexing

• Use the URL Inspection tool to test the live URL. Check the "More Info" tab for resource loading errors.
• If resources are blocked, check your robots.txt for rules that might block JavaScript or CSS files. Wix should not block these by default, but custom rules could cause issues.
• Check if the issue is isolated to specific pages or site-wide. Site-wide rendering failures suggest a platform-level issue or a global code error.
• If you have recently added Velo code, temporarily disable it and re-test. A JavaScript error in custom code can crash the entire rendering process.
• If you recently installed a new Wix App, temporarily disable it and re-test. A malfunctioning app can break rendering.
• Check the browser console on your live page for JavaScript errors. Any errors visible in the console may also prevent Google from rendering the page.
• Contact Wix support if the issue persists and you cannot identify a cause. Provide them with the URL Inspection screenshots showing the rendering failure.

Workarounds for Persistent JavaScript Rendering Problems

When you cannot fix a rendering problem directly (because it stems from the Wix platform or a required app), use these workarounds to ensure Google still gets your critical content.

• Add critical content as structured data (JSON-LD) via Wix Custom Code in the page head. Structured data in the HTML head does not require rendering to be parsed by Google.
• Use the Wix SEO meta description field to include a comprehensive summary of the page content. Meta descriptions are in the HTML head and always available to Google.
• Create a text-based summary of key content above the fold that is SSR-rendered, even if you also present the content in a more interactive format below.
• For content-heavy apps (reviews, testimonials, FAQ), consider duplicating critical content in native Wix text elements rather than relying solely on the app's rendering.
• Implement internal linking with descriptive anchor text to pass context about the page content to Google, even if Google cannot fully render the page.

Complete How-To Guide

Complete step-by-step JavaScript rendering audit for your Wix site

• Create a spreadsheet with columns: URL, Page Type, Critical Content Elements, SSR Status, Rendering Status, Issues Found, and Fix Applied.
• List your top 20-30 most important pages in the spreadsheet, prioritising by traffic and revenue.
• For each page, document the critical content elements that must be visible to Google (main headings, product descriptions, service details, FAQ content, reviews, pricing).
• Open Google Search Console and use the URL Inspection tool to test each page live. For every page, click "View Tested Page" and examine both the screenshot and the rendered HTML.
• Compare the rendered screenshot against your live page. Note any missing sections, blank areas, or content that failed to load. Record these in your spreadsheet.
• In the rendered HTML tab, use Ctrl+F to search for unique text from each critical content element. If the text is not found in the rendered HTML, Google cannot see it. Record the status.
• For each page with rendering issues, identify the cause: lazy loading, interactive element (tab/accordion), third-party app, Velo code, external API dependency, or pop-up/lightbox.
• Implement fixes based on the cause. Move content higher for lazy-loading issues. Replace tabs with visible content for interaction-dependent issues. Use native Wix elements instead of third-party apps where possible.
• For Velo code issues, move critical data fetching to onReady() and use backend web modules for external API calls to ensure SSR compatibility.
• After implementing fixes, re-test each page using URL Inspection. Verify the critical content now appears in the rendered HTML.
• Use site: search queries on Google to verify critical content is being indexed. Search for unique phrases from your content to confirm they appear in Google's index.
• Set a quarterly reminder to repeat this audit. Platform updates, new app installations, and content changes can introduce new rendering issues.
• Document your findings and fixes to create a team knowledge base for Wix JavaScript rendering best practices specific to your site.