Google Sites

Google Sites blocks arbitrary JavaScript injections on modern sites. The embed widget accepts only approved embeds. This article explains what is possible and what is not.

The JavaScript restriction on Google Sites

Google Sites (the current version available at sites.google.com) does not allow arbitrary JavaScript in page content. The Insert menu offers embeds, images, and other content blocks, but those embeds are rendered in sandboxed iframes that run in a separate origin from your Google Sites URL.

A <script> tag pasted into a Google Sites embed widget does not execute against the parent page. The beacon would fire from the iframe's origin (a google.com sandbox URL), not your Google Sites URL. That means tracking via a standard embed does not work the way it does on other platforms.

This is a deliberate security choice by Google, not a StatelessID limitation. Any third-party analytics tool that requires a <script> tag in the page head or body will face the same restriction on Google Sites.

What you can measure from Google Sites

If your Google Sites site uses a custom domain (mapped via Google Sites publishing settings), and you have control over a redirect page or gateway that visitors pass through before landing on the Sites pages, you could install the snippet there. But for pages served directly from sites.google.com or a custom domain pointing to Google Sites, the JavaScript restriction applies.

Google Sites does support embedding Google Analytics (which has a native Google integration). StatelessID's approach — a plain beacon script — does not benefit from that integration path.

If measuring Google Sites traffic is a requirement, the most practical path is to use a different platform for any pages you need to track, or to accept the Google Analytics integration that Google Sites natively supports for basic view counts.

Classic Google Sites

The original (classic) Google Sites, accessible through older Google Workspace accounts, had more permissive embedding. Some operators were able to inject scripts via HTML boxes in classic Sites. However, classic Sites is deprecated and being retired. Google has migrated most sites to the current version.

If you are still on classic Google Sites and want to test the snippet, use the Insert → More gadgets → HTML Box widget. Paste the script tag there. Classic Sites does not sandbox embeds the same way the new version does, so the script may fire against the page origin.

This approach is not recommended as a long-term solution given the deprecation timeline of classic Google Sites. Consider migrating the content to a more trackable platform if analytics data is important.

Alternatives if Google Sites does not meet your tracking needs

If you need full tracking control, Netlify, GitHub Pages, Cloudflare Pages, and Vercel all offer free hosting tiers with complete HTML control. You can build the same kind of simple informational site and get full StatelessID tracking.

For users committed to the Google ecosystem, a Google Sites page can link to a separate page hosted on a trackable platform for any content where analytics data matters. Keep Google Sites for static content that does not require measurement.

The key question is whether the traffic data from your Google Sites pages justifies moving to a different platform. For most organizations, if Google Sites is already in use, the existing Google Analytics integration may be sufficient for the pages it hosts, while StatelessID serves the other parts of your web presence.

Troubleshooting

I pasted the snippet in a Google Sites embed block and the dashboard shows no data. The embed block renders in an iframe sandbox. The beacon fires from the sandbox origin, not your Google Sites URL, and does not match any registered site. This is an expected limitation of Google Sites, not a setup error.

I have a custom domain on Google Sites — does that change anything? A custom domain on Google Sites still uses the same Google-controlled rendering engine with the same JavaScript restrictions. The custom domain changes the URL visitors see, but the script execution sandbox behavior is unchanged.

Is there any workaround at all? The only workarounds involve server-side infrastructure that you would control separately from Google Sites — a proxy, a redirect gateway, or a different hosting platform for the pages you want to track. There is no client-side workaround within Google Sites' current architecture.