How to install Google Analytics on WordPress without a plugin, and keep it after theme updates

Last updated: November 4, 2026

Say your store runs 23 plugins already, the admin feels slow, and the last thing you want is a 24th plugin that adds its own database tables to place one script. Learning how to install Google Analytics on WordPress without a plugin takes ten lines of code and fifteen minutes, and the result loads nothing but Google's own tag. The catch is where you put the code. Paste it into the theme's header file, as most tutorials show, and it disappears at the next theme update. Put it in a child theme on the right hook and it stays for years. This guide gives the code, the test, the consent question, and the honest cases where a plugin is still the better answer.

The tag snippet and the placement rule come from Google's own instructions, read on November 4, 2026.

Why install Google Analytics without a plugin?

Three reasons come up again and again: fewer plugins to update, no extra database tables or admin pages, and full control over exactly what loads on the page. A plugin that only places the tag adds little. A plugin that also shows reports in WordPress adds a lot, and that is the trade-off you are choosing.

In a recent r/woocommerce thread titled "Google Analytics without plugin?", the top answer was to hook the scripts into a child theme and to reach for Tag Manager only if you plan to scale event tracking. That is the same advice this guide gives. The thread's starting complaint was a well-known analytics plugin that the poster found bloated and expensive. Whether that is fair or not, the no-plugin route avoids the question.

How do I get the Google tag from GA4?

In GA4 go to Admin, then Data streams, click your web stream, click View tag instructions, and choose Install manually. Google shows a script snippet containing your Measurement ID, which starts with G-. Copy the whole snippet. Per Google's instructions, it belongs "immediately after the <head> on each page of your website".

The snippet looks like this, with your own ID in place of G-XXXXXXXXXX. Do not retype it. Copy it from your own GA4 screen so the ID is right.

<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX');
</script>

Where should the code go in WordPress?

Into a child theme's functions.php, attached to the wp_head action, so WordPress prints it inside the head of every page the theme renders. Not into header.php of the theme you downloaded, because the next update of that theme replaces the file and your tag with it. If you have no child theme, make one first. It is two files.

WordPress has two kinds of themes now. Classic themes use PHP template files such as header.php and support child themes in the way described below. Block themes use HTML templates edited in the Site Editor, and while child themes still work, a header scripts box or the functions.php route is simpler. In both cases the wp_head hook exists and prints into the head, which is why the function below is the method that works everywhere.

How to add the tag with a child theme, step by step

Create a child theme with a style.css and a functions.php, activate it, then add a function that echoes the Google tag and hook it to wp_head with a low priority so it prints early. Test in a private window. The whole job is under twenty lines.

1. Take a backup of the site. Code edits are the one place a backup is not optional.
2. In your hosting file manager or over SFTP, create a folder inside wp-content/themes named after your theme with -child on the end.
3. Create style.css in that folder with a header that names the parent theme in the Template line. Example for a parent theme whose folder is storefront:

/*
Theme Name: Storefront Child
Template: storefront
*/

4. Create functions.php in the same folder and add the code below, with your own G- ID.

<?php
add_action( 'wp_enqueue_scripts', function () {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
} );

add_action( 'wp_head', function () {
    if ( current_user_can( 'manage_options' ) ) {
        return; // do not count logged-in admins
    }
    ?>
    <!-- Google tag (gtag.js) -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
    <script>
      window.dataLayer = window.dataLayer || [];
      function gtag(){dataLayer.push(arguments);}
      gtag('js', new Date());
      gtag('config', 'G-XXXXXXXXXX');
    </script>
    <?php
}, 1 );

5. In WordPress go to Appearance, Themes, and activate the child theme. The parent theme stays installed and keeps receiving updates.
6. Open the site in a private window, view the page source, and confirm the tag appears inside the head.
7. In GA4 open Reports, then Realtime. You should appear as one active user within a minute.

If your host offers a staging copy of the site, do the child theme there first and copy it over once it works. If not, do the edit at a quiet hour, keep the hosting file manager open in a second tab so you can rename functions.php back in seconds if the site goes white, and never close the editor until you have loaded the home page in a private window and seen it render.

The admin check means your own visits while logged in are not counted, which is the same behaviour most plugins give you. The priority of 1 prints the tag near the top of the head, which is as close to Google's instruction as WordPress allows without editing templates.

How do I add the tag with a code snippets plugin instead?

Install a snippets plugin, create a new PHP snippet containing the same wp_head function, set it to run on the front end, and activate it. You avoid editing theme files and the snippet survives theme changes, but you have added a plugin, which is the thing you were trying to avoid. It is the right compromise for people who are not comfortable with SFTP.

The trade-off is honest. A snippets plugin stores your code in the database and runs it on every request, much like a tag plugin would. What you gain is that the code is yours and visible, and the plugin has no interest in upselling you reports. What you lose is the clean "no plugin" claim. For a site that will be handed to someone else later, the snippets route is often kinder than a child theme, because the next person can see the code in the admin instead of hunting through theme folders.

What if my theme already has a child theme or a header scripts box?

Use what you have. If a child theme exists, add the wp_head function to its functions.php. If your theme's options panel has a "header scripts" or "custom code" box, paste the snippet there, because theme options are stored in the database and survive updates. Just make sure the box prints inside the head and not in the footer.

A worked example, not a customer result. A store on a commercial theme with a "custom scripts" panel pastes the snippet into the header box and views the source: the tag sits inside the head, Realtime shows a visitor within a minute, and nothing was edited on disk. Six months later the theme updates twice and the tag is still there, because the panel saved it to the database. The same owner's old site, where the tag lived in header.php, lost it on the first update and nobody noticed for three weeks.

Many commercial themes and most page builders offer such a box. It is the fastest route and needs no PHP. The only check is to view the page source afterwards and confirm the script sits between the head tags, because some "header" boxes print just before the closing body tag, which still works but is not what Google asks for.

How do you handle consent without a plugin?

GA4's tags use first-party cookies, per Google's documentation. Where consent rules apply to your visitors, loading the tag before they agree is a problem, and without a plugin you have to build the banner and the consent signal yourself. For most store owners that is harder than the tag itself, and it is the strongest argument for using a consent plugin even if you place the analytics tag by hand.

The minimum honest approach without any plugin is to not load the tag at all until the visitor clicks accept on a banner you wrote, and to set Google's consent mode defaults to denied before the tag runs. Google documents the consent mode calls for developers. If that sentence is unfamiliar, use a consent plugin. The cost of one plugin is smaller than the cost of getting consent wrong.

A tracker that sets no cookies and keeps data in your own database may not need the same consent setup as GA4, depending on local rules. That is how StorePinger works: no cookies set by the tracker, a random id in local storage, IP addresses used only for the location lookup and not stored. The Google Analytics alternative page covers what it does and does not replace.

How do I add WooCommerce purchase tracking without a plugin?

You write the ecommerce events yourself, starting with the purchase event on the order received page, using WooCommerce's order data and GA4's event format. It is real development work, it has to be kept in step with WooCommerce updates, and a cached thank-you page or a gateway that does not return the shopper breaks it exactly as it breaks the plugins. For a store, the free Google Analytics for WooCommerce extension is the sensible exception to the no-plugin rule.

A worked example, not a customer result, of what you are signing up for. A single purchase event needs the transaction id, the value, the currency, the shipping and tax, and an items array with id, name, price and quantity for each line. That is one function on the thank-you page hook that reads the order and prints a gtag call. Then add to cart, begin checkout and view item if you want the funnel. Then test each one on every payment method you offer. A developer can do it in a day. Most store owners should not. The main setup guide covers the extension route in detail.

How do you test that it works?

View the page source in a private window and find the tag inside the head. Then check GA4's Realtime report for an active user. Then click three pages and confirm three page views. For a store with purchase events, place a cheap real order and confirm the purchase event and its value. Standard reports lag by a day or two, so Realtime is the only immediate test.

• Tag missing from the source: the child theme is not active, or the function has a syntax error.
• Tag present, no Realtime user: an ad blocker in your test browser, or you are logged in as an admin and the check hid you.
• Two tags in the source: a theme option or another plugin is also adding it. Remove one.
• Realtime fine, reports empty: wait 24 to 48 hours.
• Realtime fine, purchases missing: the bare tag does not send them. See the purchase tracking section above, or compare with WooCommerce's own order count in the comparison guide.

One more check worth doing once: open the site on a phone over mobile data, not Wi-Fi, and confirm Realtime sees you. Some mobile browsers and carrier-level filters block analytics scripts, and a store that gets most of its traffic from phones should know what share it is missing. The guide to checking traffic explains why different tools give different counts.

When is a plugin the better answer?

When you run a store and want purchase events without writing them, when you need a consent banner and do not want to code one, or when you want to read analytics inside WordPress instead of at analytics.google.com. In those three cases the plugin is doing real work, not just placing a script.

A worked example, not a customer result. A store owner places the tag by hand in a child theme, saving one plugin. Then installs a consent plugin, because the banner is required. Then installs the WooCommerce extension, because purchase events matter. The plugin count is now one lower than the all-plugin route and the setup took three times as long. For a blog, the no-plugin route is a clean win. For a store, it is usually a draw, and the comparison of WooCommerce Analytics and GA4 explains why the store's own order data matters more than the tag either way.

If the real goal is fewer plugins and faster admin, look at what each plugin does rather than how many there are. One analytics plugin that replaces a stats plugin, a cart recovery plugin, a session recording service and an email report extension reduces the count more than removing the tag plugin does. The StorePinger features page lists what is covered in one, and the free live visitors view needs no Google account at all.

Common mistakes

• Editing the parent theme's header.php. It works until the next update, then silently stops.
• Using the theme editor without a backup. A missing semicolon in PHP takes the whole site down.
• Retyping the Measurement ID. Copy it from GA4.
• Loading the tag before consent. Where consent applies, the cookie is set before the visitor can decline.
• Leaving a second tag in a theme option. Doubled page views and purchases.
• Testing while logged in. The admin check in the code hides you by design.
• Expecting ecommerce events for free. The bare tag sends page views. Store events are extra work.

Conclusion

Installing Google Analytics on WordPress without a plugin is a child theme, a wp_head function and the snippet Google gives you. Done that way it survives every theme update and loads nothing you did not choose. The honest caveats are consent, which you now own, and ecommerce events, which the bare tag does not send. If you run a store, add the free WooCommerce extension for events and a consent plugin for the banner, and accept that "no plugin" became "two plugins" for good reasons. Then ask what GA4 still cannot tell you about yesterday's orders, refunds, live carts and cities, and read how an in-WordPress analytics plugin answers those on the alternative page.