Website

why adding a last updated date to your content improes seo, trust, and ai visibility

Why Adding a “Last Updated” Date to Your Content Improves SEO, Trust, and AI Visibility

Reading Time: 5 minutes

Adding a last updated date to your website content is a small change, but it can send a strong signal to readers, search engines, and AI systems. For content that covers SEO, analytics, AI, digital marketing, and other fast-changing topics, showing that a web page is actively maintained can help reduce doubt before someone even starts reading.

I resisted this idea for a long time because I do not like dating content. A publish date can make something useful look old even when the guidance is still accurate. A last updated date feels different. It does not emphasize age. It emphasizes maintenance.

why adding a last updated date to your content improes seo, trust, and ai visibility

Why a Last Updated Date Matters

When someone lands on a blog post, they often make a quick judgment before reading the first paragraph. They scan the title, the topic, the reading time, and any other metadata near the top of the article. If they see a clear last updated date, that helps answer an immediate question: is this still relevant?

That same signal can also help search engines and AI-driven retrieval systems better understand that your content is current enough to consider. It is not the only factor that matters, but it is a useful one, especially for topics where recency can influence trust and rankings.

Benefits of Showing a Last Updated Date

A visible last updated date can help in several ways:

  • It gives readers a quick trust signal that the content is being maintained.
  • It supports freshness signals for search engines on topics where recency matters.
  • It may improve the likelihood that AI systems view the content as current and relevant.
  • It gives you a better alternative to a publish date if you want content to feel maintained rather than aged.
  • It creates a natural reason to review and improve older web pages over time.

For evergreen content, that last point matters more than it might seem. Even foundational articles usually need updates over time. A framework web page may still need a revised example, a new screenshot, a better internal link, or a more current explanation. A last updated date supports that reality better than a static publish date.

Why This Can Matter for AI Visibility

As more people use AI tools to research, compare, and summarize information, signals of maintenance are becoming more important. These systems are not just evaluating relevance. They are also trying to determine which sources are current enough to trust.

In many cases, your content is not competing against one clearly better result. It is competing against several sources that are all “good enough.” When that happens, smaller signals can influence which source gets selected.

If two articles are similarly relevant, similarly structured, and cover the same topic, the one that appears more current may have an advantage. A clear last updated date does not guarantee selection, but it can help break ties.

This is not about chasing freshness for the sake of it. It is about making real maintenance visible. If you are already improving your content over time, a last updated date is one of the simplest ways to signal that.

Why I Prefer Last Updated Over Publish Date

A publish date tells readers when a piece of content first went live. Sometimes that is useful, especially for news, announcements, and time-sensitive commentary. But for many educational articles, a publish date can work against you. It may create the impression that the content is outdated, even when it has been improved several times since then.

A last updated date shifts the emphasis. Instead of saying, “this was created a long time ago,” it says, “this has been reviewed and improved.” That is a better fit for many how-to articles, resource web pages, and evergreen blog posts.

How to Add a Last Updated Date in WordPress

If your website runs on WordPress, this can usually be done automatically. WordPress already stores the modified date for posts and web pages. The main decision is whether you want to display it with a plugin, a theme setting, or a custom snippet.

One easy option is to use a code snippets plugin such as WPCode Lite. That lets you add a small PHP snippet without editing your theme files directly. It is a practical approach if you want control over the wording, placement, and formatting.

Here is the PHP snippet I used to add a “Last updated” line above the content while excluding the front page and blog index:

add_filter( 'the_content', 'mwd_add_last_updated_date' );

function mwd_add_last_updated_date( $content ) {

    // Only run on the main front-end content area
    if ( ! is_main_query() || ! in_the_loop() || is_admin() ) {
        return $content;
    }

    // Show only on single posts and regular pages
    if ( ! ( is_single() || is_page() ) ) {
        return $content;
    }

    // Exclude front page and blog posts index
    if ( is_front_page() || is_home() ) {
        return $content;
    }

    $updated_date = get_the_modified_date( 'F Y' );

    $updated_html = '<p style="font-size:13px; color:#777; margin-bottom:16px; line-height:1.4;">Last updated ' . esc_html( $updated_date ) . '</p>';

    return $updated_html . $content;
}

This version uses the modified date, formats it as month and year, and places it above the article content. Because it pulls from the modified date, it updates automatically whenever the post is meaningfully revised and saved.

Other Implementation Choices to Consider

There is more than one way to handle this, and the best approach depends on your goals. Here are a few decisions worth thinking through:

  • Whether to show only the last updated date or also keep the original publish date.
  • Whether to use a full date or just month and year.
  • Whether to place the date near the top of the article or farther down the web page.
  • Whether to style it as a quiet metadata element rather than a prominent content block.
  • Whether to use a plugin or a custom PHP snippet.

In my case, I preferred month and year because it feels cleaner and less rigid than a specific day stamp. I also preferred the top-of-article placement because that is where readers already expect to see metadata like category and reading time.

A Few Best Practices

If you add a last updated date, it is worth using it thoughtfully. A few simple rules can help:

  • Only refresh the date when you make a real improvement to the content.
  • Keep the format simple and easy to scan.
  • Make sure the styling does not compete with the title.
  • Use the date as a maintenance signal, not a gimmick.
  • Review older content periodically so the signal reflects actual work.

This is especially important if you want the date to build trust. Readers do not need to know every edit you made, but the signal should still be honest.

Final Thoughts

If you have avoided dating content because you do not want your articles to look old, a last updated date may be the better compromise. It keeps the focus on maintenance rather than age, supports trust, and may help your content stay more competitive in both search and AI-driven discovery.

It is not a magic fix, and it does not replace good content, strong internal linking, or meaningful updates. But it is one of those small changes that can quietly strengthen the way your content is perceived.

For many websites, that makes it worth considering.

Why Adding a “Last Updated” Date to Your Content Improves SEO, Trust, and AI Visibility Read More »

Infographic on 404 tracking in GA4 showing capturing URLs and referrers with GTM, including steps for fixing broken links and setting up 301 redirects for SEO.

404 Page Not Found Tracking in GA4: Capture Broken URLs and Referrers with GTM

Reading Time: 3 minutes

When traffic reaches a web page titled “Page not found” in Google Analytics 4, you know something went wrong, but you usually do not know much else.

Which URL was requested? Did the visitor come from your own website, another website, or bot traffic? Was it a real broken link or just noise?

That is the gap this setup solves. With a small Google Tag Manager and GA4 configuration, you can capture the attempted URL and referrer whenever a 404 web page loads. That gives you the context needed to diagnose the issue and decide what to do next.

404 tracking in ga4 - capture urls and referrers with google tag manager

What this setup captures

This setup sends a custom GA4 event called page_not_found whenever a 404 web page loads.

Along with the event, it sends the full attempted URL, the requested path, and the referrer. That means you can see what the visitor tried to access and where they came from.

Instead of seeing only a generic “Page not found” title in your reports, you can see the actual destination that was requested.

Why better 404 tracking matters

Some 404s are real problems. They can reveal broken internal links, outdated destinations, or incorrect external links that cost traffic and hurt user experience.

Others are just noise, such as bots requesting junk URLs that never existed.

The goal is not to treat every 404 the same. The goal is to capture enough context to know which ones deserve action.

How to set up 404 tracking in Google Tag Manager

The first step is identifying your 404 web page condition. On many WordPress websites, the browser title contains the phrase “Page not found.” If that is true on your website, you can use it as your trigger condition.

If you do not already have a Page Title variable available, create one in Google Tag Manager as a JavaScript Variable using:

document.title

Next, create a new trigger in Google Tag Manager.

Name the trigger something like:

404 - Page Not Found

Set the trigger type to:

Page View

Choose:

Some Page Views

Then use this condition:

Page Title contains Page not found

That tells GTM to fire only when a 404 web page loads.

How to send the 404 event to GA4

After the trigger is in place, create a new GA4 Event tag in Google Tag Manager.

Name it something like:

GA4 - 404 Error

Use your existing GA4 configuration tag.

Set the event name to:

page_not_found

Then add these event parameters:

page_location = {{Page URL}}

page_path = {{Page Path}}

referrer = {{Referrer}}

Attach the 404 - Page Not Found trigger to the tag and publish the container.

At that point, GA4 will start receiving a dedicated 404 event with enough context to investigate what happened.

How to build the GA4 report

The easiest long-term approach is to build an Explore report in GA4 focused only on the page_not_found event.

Go to Explore and create a Free Form exploration.

Add these dimensions:

Event name

Page path and screen class

Add this metric:

Event count

Then apply a filter where:

Event name exactly matches page_not_found

This gives you a simple report showing which broken URLs are being requested most often.

Once data is flowing, add referrer-related dimensions if they are available in your property.

How to interpret the data

Once 404 tracking is live, the next step is deciding what kind of problem each broken URL represents.

If you see a clean-looking path that resembles a real article, category, or resource, that is often a legitimate issue. It may be an outdated internal link, a changed URL, or an old destination that still receives traffic.

If you see a bad path with an external referrer, that usually points to an incorrect backlink. In many cases, a redirect is the right fix.

If you see bizarre paths that never looked like real website content, especially with no meaningful referrer, that is often just spam or automated scanning. In those cases, the right action may simply be to ignore it.

What action you can take from this data

The value of better 404 tracking is that it gives you a short list of decisions instead of a vague warning.

If the broken URL is caused by a bad internal link, fix the source link.

If the URL used to exist and still gets meaningful traffic, consider a 301 redirect.

If the request comes from another website, decide whether the traffic is worth recovering with a redirect.

If the path is obvious junk, treat it as noise and move on.

Why this setup is worth it

Out of the box, GA4 can tell you that a 404 happened. This setup tells you what was requested and where it came from.

That makes it easier to fix broken internal links, recover traffic with redirects, and ignore junk requests that do not matter.

It is a small implementation, but it turns vague 404 reporting into something you can actually use.

404 Page Not Found Tracking in GA4: Capture Broken URLs and Referrers with GTM Read More »

categorizing referring domain data in ga4 using google tag manager 1

Categorizing Referring Domain Data in GA4 Using Google Tag Manager

Reading Time: 4 minutes

Google Analytics (GA4) provides useful traffic source reporting, but referring domain data can quickly become messy. The same platform may appear in multiple forms such as linkedin.com, www.linkedin.com, or lnkd.in. Google referrals may appear as google.com, mail.google.com, or docs.google.com.

When these variations are not cleaned up, referral reporting becomes fragmented. Instead of clearly seeing which platforms drive traffic, analytics reports fill up with dozens or even hundreds of inconsistent domains.

This article explains how to categorize referring domain traffic in GA4 using Google Tag Manager. The approach normalizes messy referrer values and assigns them to clear traffic categories such as social platforms, search engines, internal traffic, AI tools, or spam domains.

The result is much cleaner referral reporting and a much easier way to analyze where your traffic actually comes from.

The Problem With Referring Domain Data in GA4

Referring domains represent the website that sent a visitor to your website. In theory this sounds simple, but in practice the data can become messy very quickly.

One platform may appear under multiple domain variations. Mobile apps, redirect services, and shortened links can all generate slightly different referrer values. The result is fragmented reporting that makes it harder to compare traffic sources over time.

For example, LinkedIn traffic may appear under several variations.

linkedin.com
www.linkedin.com
lnkd.in

Each variation appears as a separate referrer in GA4, even though they all represent the same platform.

The same issue appears across many other platforms including Google, Pinterest, Medium, and social networks.

Normalization and Categorization Explained

This solution uses two related steps.

First, referring domains are normalized. This means multiple domain variations are cleaned into a single consistent value.

Second, those normalized values are categorized into meaningful traffic groups.

The workflow looks like this.

Raw referrer
→ Normalized domain
→ Traffic category

For example.

lnkd.in
→ linkedin
→ social

mail.google.com
→ google
→ search

marketingwithdave.com
→ internal
→ internal

startraffic.online
→ spam
→ spam

This process dramatically simplifies referral reporting.

Why Categorizing Referrers Is Valuable

GA4 already identifies traffic channels such as Organic Search, Social, and Referral. However, those channels do not always show which specific platform generated the visit.

Categorized referring domains allow you to see traffic at a much more meaningful level.

Instead of only seeing social traffic, you can more clearly separate traffic from platforms such as LinkedIn, Instagram, Pinterest, or X.

This is especially helpful if you promote content across multiple platforms and want to measure which ones actually drive visits.

It also allows you to quickly separate legitimate traffic from spam referrals or internal visits.

Categories Worth Tracking

A good first implementation should classify several common types of traffic.

Search engines such as Google, Bing, DuckDuckGo, and others.

Social platforms such as LinkedIn, Instagram, Pinterest, TikTok, Medium, Reddit, and X.

AI tools such as ChatGPT, Claude, and Perplexity. These platforms are increasingly appearing in referral data as AI assistants begin linking directly to websites.

Internal traffic coming from your own domain.

Spam domains that generate junk referrals.

Any domain not yet reviewed should fall into a category called not-classified. This makes it easier to identify domains that need to be reviewed later.

When This Approach Is Especially Useful

This setup is particularly helpful if you publish content regularly across multiple platforms.

It is also valuable if you want to identify AI-generated traffic, remove spam domains from reports, or clearly separate internal traffic from real visitors.

If you build dashboards in Looker Studio or export traffic data to spreadsheets, normalized referrer categories make analysis much easier.

Creating the Referrer Normalization Variable in GTM

The normalization logic is implemented using a Custom JavaScript variable in Google Tag Manager.

Create a new variable using the Custom JavaScript variable type and paste the following script.

function() {
  var ref = document.referrer;

  if (!ref) return 'direct';

  var host = '';
  try {
    host = new URL(ref).hostname.toLowerCase();
  } catch (e) {
    return 'not-classified';
  }

  host = host.replace(/^www\./, '');

  if (host.indexOf('marketingwithdave.com') > -1) return 'internal';

  if (host.indexOf('google.') > -1) return 'google';
  if (host.indexOf('bing.com') > -1) return 'bing';
  if (host.indexOf('duckduckgo.com') > -1) return 'duckduckgo';

  if (host.indexOf('linkedin.com') > -1 || host.indexOf('lnkd.in') > -1) return 'linkedin';
  if (host.indexOf('facebook.com') > -1) return 'facebook';
  if (host.indexOf('instagram.com') > -1) return 'instagram';
  if (host.indexOf('pinterest.com') > -1 || host.indexOf('pin.it') > -1) return 'pinterest';
  if (host.indexOf('tiktok.com') > -1) return 'tiktok';
  if (host.indexOf('medium.com') > -1) return 'medium';
  if (host === 't.co' || host.indexOf('twitter.com') > -1 || host === 'x.com') return 'x-twitter';

  if (host.indexOf('chatgpt.com') > -1 || host.indexOf('chat.openai.com') > -1) return 'chatgpt';
  if (host.indexOf('claude.ai') > -1) return 'claude';
  if (host.indexOf('perplexity.ai') > -1) return 'perplexity';

  if (host.indexOf('startraffic.online') > -1) return 'spam';

  return 'not-classified';
}

Name the variable something descriptive such as JS – Referrer Normalized.

Adding the Variable to Your GA4 Tag

Open your GA4 Google Tag or page_view tag in Google Tag Manager.

Add a configuration parameter with the following values.

Parameter name: referrer_normalized
Value: {{JS – Referrer Normalized}}

This sends the normalized value to GA4 with each page view.

Test the implementation in GTM Preview mode before publishing.

Creating the GA4 Custom Dimension

After publishing the GTM changes, create a custom dimension in GA4.

Use the following settings.

Dimension name: Referrer Normalized
Scope: Event
Event parameter: referrer_normalized

This allows the normalized value to appear in GA4 reports and explorations.

Important GA4 Limitation

GA4 custom dimensions are not retroactive. Historical referral data will not be reprocessed.

The categorized values will only appear for traffic collected after the implementation goes live.

Expanding the Classification Over Time

Your first version does not need to classify every possible domain.

Start with the platforms you already know are important. Over time, review domains that appear under not-classified and add additional rules as needed.

This gradual approach allows the classification system to evolve alongside your traffic patterns.

Visualizing the Workflow

A simple diagram can help illustrate the process.

Raw Referrer
→ Normalized Domain
→ Traffic Category

This visual representation works well as a blog image and helps readers quickly understand how the transformation occurs.

Final Thoughts

Referring domain data in GA4 often becomes fragmented and difficult to analyze. Normalizing and categorizing referrer values provides a simple way to transform messy domain data into clear traffic insights.

With a small amount of logic in Google Tag Manager, referral traffic can be organized into meaningful categories that are much easier to analyze in GA4 dashboards and reports.

If you regularly share content across multiple platforms or want to better understand where your visitors originate, categorizing referring domain traffic is one of the most useful analytics improvements you can implement.

Categorizing Referring Domain Data in GA4 Using Google Tag Manager Read More »

track page types in google analytics 4 using google tag manager

Track Page Types in Google Analytics 4 Using Google Tag Manager

Reading Time: 6 minutes

If you want better content analysis in Google Analytics 4, tracking just URLs is not enough. A list of individual web pages can tell you what got traffic, but it does not make it easy to understand which kinds of content are actually driving your website forward.

That is where page type tracking can help. Instead of only measuring individual URLs, you can classify each web page by format and send that value into GA4 as a custom parameter. This makes it possible to analyze performance by content type, such as case studies, book summaries, calculators, site search, the home page, and anything that does not yet fit into a defined bucket.

In my case, I used Google Tag Manager to identify page types based on URL patterns and page titles, then passed that value to GA4 using a custom parameter called page_type.

What page type tracking does

Page type tracking adds a structural content layer to your analytics. Instead of only seeing that a specific web page got traffic, you can now understand whether that traffic came from a case study, a calculator, a book summary, a home page visit, or some other kind of content.

Examples of page type values might include:

home-page
case-study
book-summary
calculator
site-search
404
not-classified

Once the custom dimension had been collecting data for a few months, I could finally analyze traffic by page type instead of individual URLs. Here’s what that report looks like on my own site.

Table showing page type data for March to June, including not-classified, 404, book-summary, calculator, case-study, comparison, review, site-search, the-a-to-z, the-evolution-of, and grand total.
Notice that “not-classified” is the largest bucket today. As I create more page type rules over time, I expect that category to continue shrinking.

Why page type tracking is useful in GA4

Once page type is available as a custom dimension, GA4 becomes much more useful for content analysis.

You can answer questions like:

  1. Which page types attract the most sessions?
  2. Which page types drive the strongest engagement?
  3. Which page types are most likely to bring in organic traffic?
  4. How much of my website still falls into a general not-classified bucket?

This becomes even more powerful when combined with topic tracking, because you can analyze both the format of the web page and the subject of the content.

Before you start

This walkthrough presumes:

1. You are using Google Tag Manager.

2. Your GA4 page_view event is firing through GTM.

3. Your website has consistent URL patterns or titles that can be used to identify different page types.

4. You want page types to be stable over time and mutually exclusive.

Why page type rules need to be precise

A page type should describe the format of the content, not the topic. For example, case study is a page type. Martech is a topic. Those are different things and should be tracked separately.

The goal is to give each web page one clear page type value. That keeps the classification stable and makes reporting easier to trust.

It is also important not to create too many page types too quickly. A small, meaningful set is usually better than trying to classify every edge case on day one.

Step 1: Define your page type values

Start by deciding which page types your website actually needs. In my setup, I used these values:

home-page
case-study
book-summary
calculator
site-search
404
not-classified

The first several values represent meaningful content structures. The final value, not-classified, acts as an intentional catch-all bucket.

Why not-classified matters

If no matching rule is found, the script returns not-classified.

This is not a mistake. It is a useful fallback. It gives you a deliberate “other” bucket so that uncategorized web pages do not get confused with GA4 system labels like not set. Over time, monitoring the percentage of sessions tied to not-classified can help you decide whether more page types are needed or whether the current taxonomy is already healthy.

Step 2: Create a Custom JavaScript Variable in Google Tag Manager

In GTM, create a new User-Defined Variable using the Custom JavaScript variable type.

Name it something like:

Page Type

Then use logic that checks the current URL path and page title to determine the correct page type.

Here is an example:

function() {

var path = window.location.pathname.toLowerCase();
var url = window.location.href.toLowerCase();
var title = document.title.toLowerCase();

if (
  title.includes("marketing with dave - all things digital marketing") ||
  title.includes("marketing with dave | all things digital marketing")
) {
  return "home-page";
}

if (title.includes("404")) {
  return "404";
}

if (url.includes("/search/?q=")) {
  return "site-search";
}

if (path.includes("case-study")) {
  return "case-study";
}

if (path.includes("book-summary")) {
  return "book-summary";
}

if (path.includes("the-a-to-z")) {
  return "the-a-to-z";
}

if (path.includes("the-evolution-of")) {
  return "the-evolution-of";
}

if (
  path.includes("calculator") ||
  path.includes("analyzer") ||
  path.includes("tools")
) {
  return "calculator";
}

return "not-classified";

}

How the script works

This script checks a small set of rules in order.

1. It looks for the home page title.

2. It checks for a 404 title.

3. It checks for a site search URL pattern.

4. It checks for specific URL structures like case-study, book-summary, the-a-to-z, and the-evolution-of.

5. It checks for calculator-related words in the URL.

6. If no match is found, it returns not-classified.

The order matters. More specific rules should always come before the fallback bucket.

Step 3: Add page_type to your GA4 page_view tag

Once the variable is created, open the GA4 page_view tag in Google Tag Manager.

If you have both a standard page_view tag and an internal version, update both so the data stays consistent.

In Event Parameters, add:

page_type = {{Page Type}}

This tells GTM to send the resolved page type value with each page_view event.

Step 4: Preview your changes in GTM

Before publishing, use Preview mode in GTM.

Visit several web pages on your website and verify that the variable returns the right values.

Examples:

A case study URL should return case-study.

A book summary URL should return book-summary.

A calculator or analyzer web page should return calculator.

The website home page should return home-page.

A regular article that does not match any defined rule should return not-classified.

Step 5: Publish the GTM container

Once Preview mode confirms the values are correct, publish the GTM container.

At that point, GTM is sending the page_type parameter to GA4, but GA4 still needs one final setup step before you can use it in reporting.

Step 6: Register the custom dimension in GA4

In GA4, go to Admin, then Custom definitions.

Create a new custom dimension with these settings:

Dimension name: Page Type

Scope: Event

Event parameter: page_type

Save the dimension.

From that point forward, GA4 will store and report on the page_type parameter.

Important note about historical data

GA4 custom dimensions are not retroactive.

This means page type data will only be available for traffic collected after the GTM changes are published and the custom dimension is created.

If you want a historical view, you would need to recreate it manually using existing URLs in a spreadsheet or another reporting layer.

How to analyze page type in GA4

Once the data starts flowing, one of the simplest and most useful reports is an Exploration showing sessions by page type.

A basic starting point is:

Rows: Page Type

Values: Sessions

This quickly shows what percentage of traffic is going to case studies, calculators, book summaries, site search, and everything else.

You can also combine page type with content topic to build a matrix like:

Rows: Content Topic

Columns: Page Type

Values: Sessions

That helps you understand both what the content is about and what format it takes.

Why this works well for content-driven websites

If your website includes multiple recurring content formats, page type tracking gives you a much better structural view of performance.

Instead of relying only on individual URLs, you can now see how the website performs by content model.

That is useful for editorial planning, content investment decisions, and identifying which kinds of web pages are becoming your strongest entry points.

Final takeaway

Page type tracking is one of the most useful content upgrades you can make in GA4. It adds a structural layer that makes your reporting far more meaningful than a simple list of URLs.

If your website already has recognizable URL patterns or stable page titles, Google Tag Manager can classify those web pages automatically and send the values into GA4 with very little maintenance required later.

And by keeping not-classified as an intentional fallback, you retain visibility into the portion of your website that still sits outside your current content taxonomy.

Track Page Types in Google Analytics 4 Using Google Tag Manager Read More »

Analyzing content trends infographic showing WordPress category tracking with GTM and GA4 for marketing analytics and data-driven insights.

Setting Up WordPress Category Tracking in Google Tag Manager for GA4

Reading Time: 5 minutes

If you run a content-heavy WordPress website, there is a good chance you care about more than just web page views. You may also want to know which content topics actually drive sessions, engagement, and returning visitors.

That is where category tracking can help. In my case, I wanted Google Analytics 4 to capture the WordPress Category assigned to each article so I could analyze traffic by topic. This is especially useful when your content spans areas like analytics, martech, paid advertising, SEO, content marketing, and more.

The important detail is that WordPress Categories and WordPress Tags are different. If your website uses Categories as the main topic label on articles, your Google Tag Manager setup needs to pull from the Category link, not from a Tag link.

What this setup does

This approach reads the article’s visible WordPress Category from the web page, normalizes it into a GA4-friendly value, and sends it with your page_view event as a custom parameter.

For example:

Martech becomes martech

Paid Advertising becomes paid-advertising

Search Engine Optimization (SEO) becomes search-engine-optimization-seo

Artificial Intelligence (AI) becomes artificial-intelligence-ai

Why use Category tracking in GA4?

Once this is set up, you can analyze website performance by topic instead of just by URL.

This lets you answer questions like:

Which categories attract the most sessions?

Which categories drive the longest engagement time?

Which categories perform best for case studies, calculators, or other content types?

If you already have page type tracking in place, category tracking becomes even more powerful because you can compare format and topic together.

Before you start

This walkthrough presumes:

1. You are using WordPress.

2. Your article category appears visibly on the web page as a link.

3. The category link uses a URL structure containing /category/.

4. You already have Google Tag Manager installed.

5. Your GA4 page_view tag is firing through GTM.

Step 1: Confirm that your website uses Categories, not Tags

This part matters more than people realize.

If your website displays the topic label under the title and that label links to a URL like /category/martech/, then your GTM script should look for Categories.

If your setup uses WordPress Tags instead, the link would usually contain /tag/.

Step 2: Create a Custom JavaScript Variable in Google Tag Manager

In Google Tag Manager, go to Variables and create a new User-Defined Variable.

Choose Custom JavaScript as the variable type.

Name it something like:

Content Topic

Then use this script:

Some tutorials detect categories using URL patterns like /category/. That works on some WordPress websites, but many themes remove the category base from URLs. A more reliable approach is to target the category element directly in the HTML.

function() {
  var category = document.querySelector('.ast-terms-link a');
  if (!category || !category.textContent) return 'not-classified';

  return category.textContent
    .trim()
    .toLowerCase()
    .replace(/[()]/g, '')
    .replace(/\s+/g, '-')
    .replace(/[^a-z0-9-]/g, '')
    .replace(/-+/g, '-')
    .replace(/^-|-$/g, '');
}

Note: The selector .ast-terms-link a works for Astra theme. If you are using a different theme, inspect the category link on the web page and adjust the selector accordingly.

How the script works

This script does five things:

1. It looks for the first link on the web page that contains /category/.

2. It grabs the visible text of that link.

3. It trims extra spaces.

4. It converts the value to lowercase.

5. It removes special characters and replaces spaces with hyphens.

If no category is found, it returns not-classified.

This acts as a deliberate “other” bucket. Instead of mixing uncategorized traffic with GA4 labels like not set, you can clearly see what portion of your content taxonomy is missing or incomplete. Over time, the goal is not to eliminate not-classified, but to keep it at a healthy percentage.

Step 3: Add the parameter to your GA4 page_view tag

Next, open the GA4 page_view tag in Google Tag Manager.

If you have a standard page_view tag and a separate internal version, make sure you update both so the data stays consistent.

In the Event Parameters section, add a new parameter:

content_topic = {{Content Topic}}

That tells GTM to send the normalized category value with every page_view event.

Step 4: Preview the changes in GTM

Before publishing, use Preview mode in Google Tag Manager.

Open a few different article web pages and confirm that the Content Topic variable returns values you expect from your WordPress Categories.

For example, on a Martech article, the variable should return:

martech

On a Paid Advertising article, it should return:

paid-advertising

If you see a value that does not match one of your approved categories, your selector may be pulling from the wrong part of the web page.

Step 5: Publish the GTM container

Once preview mode looks good, publish the container.

At this point, GTM is sending the custom parameter to GA4, but Google Analytics 4 still needs one more step before you can use it in reports.

Step 6: Register the custom dimension in GA4

In GA4, go to Admin, then Custom definitions.

Create a new custom dimension with the following settings:

Dimension name: Content Topic

Scope: Event

Event parameter: content_topic

Save the custom dimension.

From that point forward, GA4 will store and report on the content_topic parameter.

Important note about historical data

GA4 custom dimensions are not retroactive.

That means this setup will only classify data collected after the custom dimension is created and GTM is published.

If you want historical analysis, you will need to build it manually using a spreadsheet or another reporting layer.

How to use the data in GA4

After the data starts flowing, the easiest place to analyze it is in Explorations.

A simple starting report is:

Rows: Content Topic

Columns: Page Type

Values: Sessions

This makes it easy to see which topics are driving traffic and how those topics map to different kinds of content.

Examples might include:

Case studies in martech

Book summaries in leadership

Articles in analytics

Calculators in website-related topics

Why this works well for WordPress websites

The biggest advantage of this setup is that it uses the taxonomy you already maintain in WordPress.

You are not inventing a separate analytics classification system. You are simply exposing your existing editorial structure to GA4.

That makes the reporting much easier to trust.

Can this work outside WordPress?

Yes, but the implementation details change.

The broader concept is the same: identify the topic label on the web page, extract it with GTM, normalize it, and send it to GA4 as a custom parameter.

What changes is the selector. Instead of looking for a WordPress Category link containing /category/, another platform might use a different class name, data attribute, or metadata element.

So the process is portable, but the selector is platform-specific.

Final takeaway

If your WordPress website uses Categories as the primary topic label for articles, GTM should pull from Categories and not Tags. That one detail can be the difference between clean, trustworthy GA4 topic reporting and a messy dataset you cannot rely on.

Once you set this up, GA4 becomes much more useful for understanding what your content is really doing by subject area, not just by individual URL.

Setting Up WordPress Category Tracking in Google Tag Manager for GA4 Read More »

Cookie consent banner for privacy compliance on a website, featuring accept, reject, and manage preferences options.

Cookie Consent Management and Privacy Compliance Platform

Reading Time: 5 minutes

Most websites are running more trackers than their owners realize.

I scanned my own website and found 279 cookies across 262 pages, including 148 unclassified.

If you do not know what is running on your website, you are not actually managing it.

See how this score is calculated

Here’s how to interpret this score:

The overall score reflects both product quality and how compelling the current deal is.

A score in the high 4 range reflects a strong product with clear value and only minor limitations.

See the AppSumo Deal

Affiliate disclosure: If you buy through my AppSumo link, I may earn a small commission at no additional cost to you. I only share tools I believe are worth your time and consideration.

Real Results From My Implementation

These are the results from my own website after implementing Consently, not a demo or sample environment.

Full scan results: Total cookies, pages analyzed, and category breakdown from my website.
Consent rate: How users actually respond to the cookie banner after implementation.
Live banner experience: What users see when they visit the website.

The 30-Second Decision

Best for: websites that want full consent coverage without turning compliance into a project

Not ideal for: enterprise teams with complex, multi-region compliance requirements at scale

Entry price: $39 lifetime for 1 domain and 100,000 monthly page views

Risk window: 60-day refund through AppSumo, versus a 14-day trial on Consently’s own website

My take: a practical “get compliant fast” tool for most websites and lean teams. Not an enterprise privacy platform, and that is exactly why it fits.

What I Found When I Scanned My Website

Here’s what Consently surfaced on my own website, and it was more than I expected.

The 148 unclassified cookies meant there was real work ahead to properly categorize them.

Consently helps close that gap with scanning, consent control, consent logging, and policy generation in one place.

This is exactly the kind of visibility most websites are missing.

See the AppSumo Deal Before It Ends

What Consently Actually Does

Consently takes you from “I do not know what is running on my website” to visibility and control.

It scans your website for cookies and third-party scripts, blocks non-essential cookies until visitors give consent, logs consent decisions in an audit-ready dashboard, and generates privacy, cookie, and terms policy pages.

It also connects with Google Analytics 4 and ad platforms so opt-outs are actually respected.

Most consent tools stop at displaying a banner. Consently lets you define which cookies are essential and which require consent, including analytics, advertising, performance, and social. That is a governance decision, not a design choice.

Consently is not just a banner tool. It is visibility into what is actually happening on your website.

Doesn’t Google Analytics 4 Already Handle This?

Not really.

Google Analytics 4 and Google Tag Manager can help configure how Google tags behave after consent is given through Consent Mode. That is useful, but it is not a consent management system.

Google Analytics 4 and Google Tag Manager Consently
Consent Mode configuration only Full consent management system
No automatic cookie scanning Automatic cookie scanning
No cookie categorization dashboard Category-level cookie classification and control
No built-in policy generator Built-in policy generation
No centralized consent log dashboard Audit-ready consent logs
Manual configuration across tools Scanning, blocking, logging, and policy generation in one dashboard

Google Analytics measures what happened. Consently controls what is allowed to happen.

Setup in Minutes

Add your website name and URL, customize your banner and preference center, then drop a single script into your website header. I deployed mine through Google Tag Manager. After that, Consently scans, logs, and generates your policy pages automatically.

Why I Would Recommend This

  1. Compliance is based on data collection, not traffic size. If you collect data, you are responsible for it. At a lifetime price, this is inexpensive risk reduction.
  2. Tracking drift is real. Expired tags linger. Short-term tests become permanent. Third-party tools introduce cookies you did not explicitly plan for. On my own website, Consently surfaced 148 unclassified cookies. That is exactly the kind of thing that accumulates without you realizing it. Regular scanning restores visibility and control.
  3. It compresses complexity for lean teams. You could try to manage consent through multiple tools and manual processes. Most teams do not. Consently centralizes scanning, consent control, logging, and policy generation into one operational layer.

What Works Well

  • Live in under 30 minutes with minimal setup
  • Automatically scans your entire website for cookies across all pages
  • Control exactly which cookies are allowed and when
  • Audit-ready consent log dashboard
  • Built-in policy page generation
  • Google Analytics 4 and ad platform compatibility
  • 60-day AppSumo refund window

Watch Out For

No CSV export for your cookie list. This is the one thing I would change and have recommended to the team. With 148 unclassified cookies, being able to export, sort, and bulk classify in a spreadsheet would save real time. Right now you are doing it one by one inside the dashboard, which becomes tedious fast at scale. That is the gap between a 4-star and 5-star tool for me.

Validate PageSpeed and overall performance impact if your website is performance-sensitive.

Some manual review is still required as your tech stack evolves.

Not built for complex, multi-region enterprise compliance.

Plans and Pricing

Tier 1 starts at $39 lifetime for 1 domain and 100,000 monthly page views. Higher tiers add more domains and more page view capacity for teams managing multiple websites.

The AppSumo 60-day refund window gives you more runway than Consently’s standard 14-day trial to test it on your own website before committing.

Check Current Pricing and Tiers

Bottom Line

Privacy compliance is rarely urgent until it is.

For a $39 lifetime starting tier, Consently is a fast, centralized way to get cookie banners, scanning, consent logs, and policy pages in place without turning it into a legal or engineering project.

The one gap, no CSV export for bulk cookie classification, is a real friction point if your website has a lot of unclassified cookies. But at this price point, and with the core functionality it delivers, it is still the right tool for most websites and small teams.

If you want full visibility and control over what’s running on your website without turning compliance into a project, this is one of the easier decisions you’ll make.

Get Consently Lifetime Access

Disclaimer: I am not a lawyer. This content is for educational purposes and reflects my experience and research. Always validate privacy and compliance requirements based on your specific business and jurisdictions.

Looking for more marketing software reviews? See my full list of marketing tools and software I recommend.

Cookie Consent Management and Privacy Compliance Platform Read More »