Set Up Server-Side GTM on WordPress with Stape.io

Updated May 2026. Rewritten with the current Stape flow, a tag-migration walkthrough, an honest self-host comparison, and the gotchas the old step list skipped.

Server-side GTM on WordPress moves your tag processing off the visitor’s browser and onto a container you control. Done right, it speeds up your pages, recovers analytics data that ad blockers and Safari quietly drop, and gives you real control over what data leaves your site. Done carelessly, it is a second piece of infrastructure that breaks silently and nobody notices for a week.

We are Osher Digital, a Brisbane data and automation consultancy, and we set up server-side tagging for clients often enough to have opinions about it. This guide covers what a GTM server actually is, the full setup on WordPress with Stape, how to migrate your existing tags without double-counting, and the honest call on whether to use Stape or self-host. If you run WooCommerce specifically, our WooCommerce server-side tracking guide goes deeper on ecommerce events; this one is the general WordPress setup.

What a Server-Side GTM Server Actually Does

Standard Google Tag Manager runs in the browser. Every tag, every pixel, every analytics call fires from the visitor’s device. A server-side GTM container changes the path: the browser sends one request to your own container, hosted on a server, and that container forwards events to GA4, Google Ads, Meta, and anywhere else from server to server.

That one change in topology buys you four things:

• Faster pages. Far less JavaScript runs in the browser, which helps Core Web Vitals and, indirectly, rankings.
• More complete data. Requests go to your own subdomain, so ad blockers and tracking-prevention features do not recognise and block them.
• Longer-lived first-party cookies. Cookies set server-side last well beyond the seven-day cap Safari’s ITP imposes on client-side scripts.
• Control over the data. You decide what fields leave your server and where they go, which makes privacy compliance far easier to reason about.

The catch is that you are now running a server. It needs to stay up, stay patched, and stay monitored. For a site with real traffic and ad spend, that is a fair trade. For a brochure site with a contact form, it is not.

What You Need Before You Start

Get these in place before touching the setup:

• A self-hosted WordPress site (the .org version) on WordPress 6.x with HTTPS active and admin access.
• An existing GTM web container running on the site, with a note of your current tags, triggers, and variables.
• Access to your DNS, so you can add a CNAME record for the custom subdomain.
• A Stape account. The free tier is fine to test; a paid plan before you rely on it.

Decide your subdomain now, for example gtm.yoursite.com.au. Using your own subdomain rather than the default Stape URL is the whole point: it is what keeps the cookies first-party and the requests off the blocklists. Set it up first time rather than retrofitting it.

Setting Up Server-Side GTM on WordPress with Stape

Four steps to a working server-side GTM setup. An hour or two the first time.

Step 1: Create the Server Container

In Google Tag Manager, create a new Server container. It produces a container config string. In Stape, create a new server, paste that string, and choose a hosting region near your audience. For an Australian site, Sydney or Singapore gives the lowest latency. Stape spins up the container and gives you a server URL.

Step 2: Add the Custom Domain

In Stape’s domain settings, add gtm.yoursite.com.au and create the CNAME record it provides in your DNS. Propagation usually takes under an hour but can run longer. Once Stape verifies the domain, it provisions an SSL certificate automatically. This subdomain becomes the endpoint your WordPress site sends data to.

Step 3: Install and Connect the Stape Plugin

Install the Stape GTM Server Side plugin from the WordPress plugin directory or the Stape GitHub repository. Activate it, then under Settings > GTM Server Side enter your custom subdomain in the Stape Server URL field and your web container ID (GTM-XXXXXXX). Save. The plugin now routes your site’s GTM through the server container, and includes a custom loader that disguises the script path from ad blockers.

Step 4: Add a GA4 Tag in the Server Container

In your server container, add a GA4 client to receive incoming requests, then a GA4 tag pointing at your Measurement ID. Open Preview mode, load your site, and confirm the page_view event arrives at the server and lands in GA4 Realtime. Once that works end to end, you have a functioning server-side GTM setup and can start moving real tags across.

Migrating Tags to Server-Side GTM

Not every tag belongs server-side. Move the ones that benefit, leave the ones that need the browser.

• Move these: GA4, Google Ads conversions, the Meta Conversions API, and other analytics or advertising tags that just send data.
• Leave these client-side: anything that changes the page (A/B testing tools, chat widgets, anything that reads the DOM or reacts to clicks in real time).

The one rule that saves you grief: run the new server-side tag and the old client-side tag in parallel for a day, compare the numbers, then disable the client-side one. Cutting over instantly means that if the server tag has a problem you lose data with nothing to compare against. The most common mistake here is forgetting to disable the old client-side GA4 tag, which double-counts every event until someone spots the suspiciously high numbers.

If you want this migrated cleanly without losing a fortnight of conversion data mid-campaign, book a call and we will run the cutover with you.

Self-Hosting the GTM Server vs Using Stape

The server-side GTM container is Google’s, and you can run it yourself on Google Cloud, AWS, or any host that runs the Docker image. So why pay Stape? It comes down to who you want maintaining the infrastructure.

Self-hosting is cheaper at high volume and gives you full control, but you own the scaling, the SSL renewal, the uptime, and the patching. We have seen self-hosted containers silently stop forwarding events because an autoscaler scaled to zero overnight to save money. Stape handles all of that, plus the WordPress plugin, the custom loader that beats ad blockers, and a stack of pre-built tag templates. For most WordPress sites the monthly fee is cheaper than the engineering time self-hosting demands. Self-host when you have a platform team who will own it and your request volume is genuinely large. Otherwise, let Stape run it.

For the deeper background on Google’s side of this, the official server-side tagging documentation is worth a read before you commit to either path.

What Server-Side GTM Costs

Stape’s free tier covers roughly 10,000 requests a month, enough to test. Paid plans start around 30 AUD per month and scale with request volume; a typical WordPress business site lands in the 30 to 75 AUD per month band. Self-hosting on a small cloud instance can be cheaper on paper, perhaps 15 to 40 AUD per month in compute, but only if you ignore the cost of the person maintaining it.

One-off setup is the other line. Doing it yourself is an afternoon. Having it set up, tags migrated, and verified across GA4, Google Ads, and Meta runs roughly 1,500 to 4,000 AUD depending on how many destinations you need.

When Server-Side GTM Is Not Worth It

We talk people out of this regularly. Skip it, or wait, if:

• You do not run paid ads and do not make decisions on analytics. The biggest payoff is cleaner conversion data for ad platforms. No ads, much smaller win.
• Your traffic is low. The data recovered is real but too small in absolute terms to change anything, and the maintenance is not free.
• Nobody can own the container. An unmaintained server-side setup that quietly stops forwarding is worse than honest client-side data, because you will trust it.

If you spend real money on ads and your reported conversions look low against actual leads or sales, that is the signal it is time. Below that, client-side GTM with consent mode is usually enough. For non-GTM platforms, the same logic applies in our WordPress server-side tracking and TikTok server-side tracking guides.

Frequently Asked Questions

What is a server-side GTM server?

It is a Google Tag Manager container that runs on a server you control rather than in the visitor’s browser. The browser sends events to the container, which then forwards them to GA4 and other platforms server to server. This improves page speed, data completeness, and your control over what data is shared.

Do I need Stape for server-side GTM on WordPress?

No, but it is the easiest path. Stape hosts and manages the container and provides a WordPress plugin, a custom loader that beats ad blockers, and tag templates. You can self-host the same Google container on your own cloud, which is cheaper at high volume but means you own scaling, SSL, and uptime.

Is there an open-source GTM server?

The server-side container itself is Google’s software, distributed as a Docker image you can run anywhere, so it is free to self-host even though it is not strictly open source. Stape and similar services charge for hosting and management, not for the container software. If you want full control and have the ops capability, running the image yourself is a valid option.

Will server-side GTM speed up my WordPress site?

Usually a little. Moving tags off the browser means less JavaScript executes on the page, which can improve Core Web Vitals like Largest Contentful Paint. The forwarding work happens on the server container instead of the visitor’s device. The gain is real but modest; do not expect it to fix a slow theme or unoptimised images.

How much does server-side GTM cost in AUD?

Stape paid plans start around 30 AUD per month, with most WordPress business sites between 30 and 75 AUD depending on request volume. Self-hosting compute can be 15 to 40 AUD per month but adds maintenance time. One-off professional setup with tags migrated and verified runs roughly 1,500 to 4,000 AUD.

Do I still need cookie consent with server-side GTM?

Yes. Server-side tagging changes where data is processed, not whether you need permission to collect it. You still need consent where it applies and should implement consent mode so tags respect the visitor’s choices. The upside is that you have more control over exactly what data leaves your server once consent is given.

Which tags should stay client-side?

Keep anything that modifies the page or reacts to the user in real time on the client side: A/B testing tools, chat widgets, and scripts that read the DOM. Move data-only tags like GA4, Google Ads conversions, and the Meta Conversions API to the server. Running both in parallel briefly during the switch avoids gaps and double-counting.

Server-side GTM is straightforward to stand up and easy to get subtly wrong, and the subtle errors cost you accurate data right when a campaign is live. If you would rather have it set up, migrated, and verified properly, get in touch with our team. We are based in Brisbane and work with businesses across Australia.