A Reproducible JavaScript Rendering Test for Casino Pages

Why a written test protocol

"It renders fine on my machine" is not evidence. Your browser has cookies, a stored jurisdiction, granted permissions and a European IP address. Googlebot has none of those. A written protocol makes the test repeatable by another engineer next month and comparable across releases.

The test compares the same URL in three views and records what differs:

1. Raw HTML: the server response before any JavaScript runs.
2. Google's rendered HTML: from a URL Inspection live test, or the Rich Results Test for public pages.
3. Your scripted render: a headless Chromium session you control, for bulk and regression testing.

For why these differences matter, read JavaScript rendering on casino sites. The test is stage 3 of the indexation workflow, and its results feed the rendering items of the technical SEO checklist.

Step 1: pick test URLs per template

Choose two or three URLs per template rather than one page at random: homepage, slots lobby, a provider hub, a game page, a promotion, a sportsbook competition page, an event page and a help article. Templates fail together, so template coverage finds more than page count.

Step 2: capture the raw HTML

Fetch each URL without running JavaScript and save the response with its headers. Use a clean session with no cookies.

# constructed example: raw response, no JavaScript, no cookies
curl -s -D raw-headers.txt -A "Mozilla/5.0 (compatible; rendering-test)" \
  https://casino.example/slots/ -o raw.html

Record: status code, any X-Robots-Tag header, the canonical and meta robots tags, the H1, the number of <a href> links, and whether the main content (game names, event names, promotion text) is present.

Step 3: capture Google's rendered HTML

In Search Console, inspect the URL, choose "Test live URL", then "View tested page". Google's help says "the HTML tab shows the rendered HTML for the page." The same panel shows the screenshot, console messages and page resources. Note that the screenshot "is available only in a live test with a successful test result" and that "screenshots are not available for the indexed URL."

For a page you do not have Search Console access to, Google suggests the Rich Results Test, as long as the page needs no login and is not blocked by robots.txt. It uses "the rendered source code", its "default user agent is smartphone", and it fetches as Google-InspectionTool, "not using your credentials, but as Google."

Step 4: script your own render for regression tests

For checks on every release, a headless browser script gives repeatable results. This constructed example uses Playwright. Run it only against sites you own or are authorized to test, and keep the request rate low.

// constructed example: compare raw HTML with the rendered DOM
const { chromium } = require('playwright');
(async () => {
  const url = process.argv[2];
  const raw = await (await fetch(url)).text();
  const browser = await chromium.launch();
  const page = await browser.newPage({
    viewport: { width: 412, height: 915 },   // phone-sized, like Googlebot Smartphone
    locale: 'en-US'
  });
  const resp = await page.goto(url, { waitUntil: 'networkidle' });
  const facts = await page.evaluate(() => ({
    h1: document.querySelector('h1')?.textContent.trim() || null,
    canonical: document.querySelector('link[rel=canonical]')?.href || null,
    robots: document.querySelector('meta[name=robots]')?.content || null,
    links: document.querySelectorAll('a[href]').length,
    textLength: document.body.innerText.length
  }));
  const rawLinks = (raw.match(/<a\s[^>]*href=/gi) || []).length;
  console.log({ status: resp.status(), rawLinks, ...facts });
  await browser.close();
})();

Do not click, scroll or accept anything in the script. Google's lazy-loading page reminds us that Google Search "does not interact with your page", so a script that scrolls will find content Google may not.

Step 5: compare and classify

Step 6: account for caching

Google's troubleshooting page says "Googlebot caches aggressively in order to reduce network requests and resource usage" and "WRS may ignore caching headers." After a front-end deploy, Google may render with older JavaScript or CSS for a while. Use content hashes in asset file names (for example main.8f4c2.js) so a new release means new URLs.

Step 7: record the result

For each URL, store the date, release version, tool used, status code, raw versus rendered link count, canonical and robots in both views, main content present (yes or no), console errors and screenshot file names. Repeat after every release that touches templates, routing, consent or geo logic.

Questions technical teams ask