Google Analytics 4 is a free measurement platform that records visitor behavior, traffic sources, and conversion data. Installing it does not directly affect rankings, but the data it produces is essential for measuring SEO performance, identifying high-value pages, and prioritizing future optimization work. Fixing this issue means installing the GA4 tag site-wide and confirming events appear in your reports.

Example

<!-- Place inside <head> on every page -->
<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 to make the change

• Raw HTML: paste the GA4 snippet into the <head> of every page. A shared layout file is the cleanest place.
• WordPress: use a site-kit or analytics plugin, or paste the snippet into your theme's header file. Avoid duplicating the tag across multiple plugins.
• Shopify: add the GA4 measurement ID under Online Store, Preferences, Google Analytics, or install the official Google channel app.
• Wix or Squarespace: both platforms offer a GA4 measurement ID field in their analytics settings panel.
• Headless or framework sites: install via Google Tag Manager or use the framework's analytics integration so the tag fires on every route change.

Common causes and how to resolve them

• Tag not installed at all: install GA4 using the snippet above or the platform-specific path.
• Universal Analytics tag still in place: Universal Analytics stopped processing data on July 1, 2024. Replace any UA tag (UA-...) with a GA4 measurement ID (G-...).
• Tag fires only on the homepage: ensure the snippet is in a shared template loaded by every page, not pasted into one post.
• Cookie banner blocks the tag before consent: integrate Consent Mode v2 so GA4 receives anonymized signals before consent and full data after.
• Tag duplicated: two snippets on the same page double-count sessions. Audit with the Tag Assistant browser extension and remove duplicates.

Best practices

• Verify with real-time reports: after installing, open GA4's Realtime view and load the site to confirm events arrive.
• Use Google Tag Manager: for any site beyond the simplest, GTM gives you a single place to manage analytics, conversion tags, and third-party scripts without code changes.
• Configure key events: mark conversions (purchase, lead, signup) as key events so reports highlight what matters for SEO ROI.
• Link to Search Console: connecting GA4 to Search Console surfaces organic queries alongside on-site behavior in the same reports.

This test fails when image responses lack caching headers that allow browsers to store them for repeat visits. With proper caching directives, returning visitors retrieve images from the local cache instead of refetching them, producing noticeably faster subsequent page loads. Fixing this issue is a server or CDN configuration change.

Where to make the change

• Server configuration: add Cache-Control headers to image responses. A common setting is Cache-Control: public, max-age=31536000, immutable for versioned assets.
• CDN configuration: Cloudflare, Fastly, CloudFront, and similar offer rules to set long cache lifetimes for image MIME types.
• WordPress and plugins: a caching plugin or a CDN integration handles cache headers without server changes.
• Shopify: Shopify serves images with appropriate cache headers automatically; failures usually point to externally hosted images.

Common causes and how to resolve them

• No Cache-Control or Expires header: add one. Browsers will revalidate every request without it.
• Cache-Control: no-cache or no-store: these are correct for HTML responses but wrong for static images. Set a long max-age instead.
• Short max-age (under a day): images change rarely; a max-age of months or a year is typical.
• Cookie-bearing image requests: if the image URL sets cookies or varies by user, browsers cannot cache effectively. Serve images from a cookie-free subdomain or your CDN.

Best practices

• Use versioned filenames: renaming the file when the content changes lets you set near-permanent cache lifetimes without ever serving stale files.
• Mark immutable assets as such: the immutable directive tells browsers to skip even revalidation requests.
• Serve from a CDN: CDNs add caching, compression, and edge delivery in one step.

This test fails when external JavaScript files are served without caching headers that allow browsers to store and reuse them. Cached scripts skip the network on repeat visits, reducing load time and bandwidth for returning users. Fixing this issue is a server or CDN configuration change.

Where to make the change

• Server configuration: add Cache-Control: public, max-age=31536000, immutable to JavaScript responses, paired with versioned filenames.
• CDN configuration: set a default cache rule for *.js assets at the edge.
• Build pipeline: emit hashed filenames (for example app.7f3c1e.js) so cache lifetimes can be long without risking stale code.
• WordPress and plugins: caching and CDN plugins handle JS cache headers automatically.

Common causes and how to resolve them

• No Cache-Control header: add one. Without it, browsers revalidate on every page load.
• Short max-age: bump to a year for versioned files. Use a shorter lifetime only for unversioned scripts that may change in place.
• no-cache or no-store on static JS: remove these directives; they belong on dynamic responses, not static assets.
• Cookies on script requests: serve scripts from a cookie-free subdomain or a CDN to enable shared caching.

Best practices

• Versioned filenames: hashed file names plus immutable caching is the gold standard for cache effectiveness.
• Self-host critical scripts: hosting third-party scripts yourself lets you control cache headers and avoid vendor outages.
• Audit with DevTools: the Network panel's "Disk cache" column shows whether each script is genuinely served from cache on repeat visits.

This test fails when external CSS files are served without caching headers that allow browsers to store and reuse them. Cached stylesheets skip the network on repeat visits, reducing load time for returning users while still allowing updates through versioned filenames. Fixing this issue is a server or CDN configuration change.

Where to make the change

• Server configuration: add Cache-Control: public, max-age=31536000, immutable to CSS responses, paired with versioned filenames.
• CDN configuration: set a default cache rule for *.css assets at the edge.
• Build pipeline: emit hashed filenames so cache lifetimes can be long without risking stale styles.
• WordPress and plugins: caching plugins handle CSS cache headers automatically.

Common causes and how to resolve them

• No Cache-Control header: add one. Without it, browsers revalidate on every page load.
• Short max-age: bump to a year for versioned files; keep it shorter only for unversioned files that may change in place.
• Stylesheets behind authentication: private styles cannot use public caching. Move shared styles to a public path.

Best practices

• Versioned filenames: hashed names plus immutable caching is the gold standard.
• Inline critical CSS: the styles needed for above-the-fold rendering can be inlined while the rest is cached and loaded asynchronously.
• Audit with DevTools: confirm that on repeat visits, the stylesheet is served from disk cache rather than the network.

This test fails when the page exposes one or more email addresses in plain text. Spam-harvesting bots scrape pages for plaintext addresses and add them to bulk mailing lists. Fixing this issue means obfuscating contact addresses, using a contact form, or rendering them via JavaScript so simple scrapers cannot read them.

Where to make the change

• Application code or templates: replace plain contact@example.com text with one of the obfuscation techniques below.
• WordPress: a contact form plugin handles email submissions without exposing the address. Some SEO and security plugins also offer email obfuscation.
• Shopify, Wix, Squarespace: use the platform's built-in contact form blocks rather than displaying the email address directly.

Common causes and how to resolve them

• Plain text address in a paragraph or footer: replace with a contact form, an obfuscated rendering (HTML entities, CSS reversal), or a JavaScript-built mailto link.
• Mailto link with the address visible: the visible text is what bots read. Make the visible text a label like "Email us" while the href still works.
• Address baked into images is fine for SEO but bad for accessibility: screen readers cannot read it. Pair an image with a contact form instead.

Best practices

• Prefer contact forms: they reduce spam and make analytics easier.
• Use HTML entity encoding: writing co... for the address defeats the simplest scrapers, though sophisticated ones decode it.
• Render via JavaScript: building the mailto link client-side blocks scrapers that only read static HTML.
• Consider a Cloudflare-style email obfuscation: some CDNs automatically rewrite plaintext emails to obfuscated equivalents.