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 one or more images carry disproportionately large embedded metadata such as EXIF data, thumbnails, color profiles, geolocation, and camera information. This metadata is rarely useful on the web and adds bytes to every request without any rendering benefit. Fixing this issue means stripping the metadata as part of your image processing pipeline.

Where to make the change

• Image build pipeline: use a tool such as ImageMagick (mogrify -strip image.jpg), jpegoptim --strip-all, or oxipng --strip all to remove metadata at build time.
• WordPress: a media optimization plugin will strip metadata automatically on upload.
• Shopify, Wix, Squarespace: the platforms strip most metadata server-side. Failures usually point to images served from external sources you control.
• Image CDN: Cloudflare Images, Cloudinary, and Imgix strip non-essential metadata by default during transformation.

Common causes and how to resolve them

• Original camera files uploaded as-is: camera files contain large EXIF blocks (lens, GPS, embedded JPEG previews). Strip during upload or build.
• Color profile larger than the image: embed a small sRGB profile or strip the profile entirely if the image is meant for the web.
• Stock photo metadata: stock images often carry copyright notices, IPTC blocks, and watermarks larger than the image data itself.
• Geolocation in personal photos: beyond bytes, EXIF GPS can leak the photographer's location. Strip for privacy as well as performance.

Best practices

• Strip metadata on upload: make it part of the asset pipeline so no human action is required.
• Preserve only essentials: a small ICC color profile is occasionally worth keeping for accurate color rendering; everything else can usually go.
• Verify with a quick check: tools like exiftool image.jpg show what is left after stripping, so you can confirm only what you want remains.

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.

This test fails when the page is being excluded from search engine indexes via a noindex directive in the robots meta tag or X-Robots-Tag HTTP header. A noindex on the wrong page is one of the most common ways important content silently disappears from search results. Fixing this issue means removing the directive from any page that should rank.

Where to make the change

• Raw HTML: remove <meta name="robots" content="noindex"> from the <head> of pages you want indexed.
• Server configuration: remove or update X-Robots-Tag: noindex response headers for affected URL paths.
• WordPress: in the post or page editor, your SEO plugin has a "Search engine visibility" toggle. Make sure it is set to allow indexing. Also check Settings, Reading, "Discourage search engines" — this site-wide flag must be off.
• Shopify: certain templates and resource types (search results, cart) are noindexed by default and should stay that way. For other URLs, edit theme.liquid to remove the conditional noindex.
• Headless or framework sites: remove the meta tag from the page's metadata configuration or layout file.

Common causes and how to resolve them

• Site-wide noindex left over from staging: the most common cause. Disable the global setting after launch.
• Per-page noindex set in the CMS by mistake: review the page's SEO settings and toggle indexing back on.
• X-Robots-Tag header set by server config: check the server or CDN rules; remove the header for production URLs.
• Noindex on category or tag pages that should rank: some SEO plugins noindex archives by default. Override the setting for archives that earn organic traffic.

Best practices

• Verify with URL Inspection in Search Console: the live test confirms whether Google currently sees the page as indexable.
• Audit after migrations: staging sites are usually noindexed; verify the directive is removed before traffic resumes.
• Keep noindex for thin or duplicate pages: not every page should rank. Internal search results, paginated archives, and login pages benefit from noindex.

This test reports on whether the page applies a nofollow directive that tells search engines not to follow outbound links. The nofollow attribute (and the related sponsored and ugc values) controls how link equity flows from your page. Fixing this issue means using the right rel value on each external link based on its purpose so signals are passed only where you intend.

Where to make the change

• Raw HTML: add rel="nofollow", rel="sponsored", or rel="ugc" to specific outbound links rather than blanket-applying them site-wide.
• WordPress: the block editor offers a "mark as nofollow" option per link, and SEO plugins can auto-tag external links by domain.
• Shopify, Wix, Squarespace: editor-generated links allow rel attribute toggles; manual HTML embeds need them set explicitly.
• Headless or framework sites: wrap external links in a component that decides the rel based on the link's classification.

Common causes and how to resolve them

• Site-wide nofollow on every external link: overly aggressive. Reserve nofollow for sponsored, untrusted, or user-generated content.
• Sponsored content not labeled: use rel="sponsored" on paid placements and affiliate links to comply with Google's link spam policy.
• User-generated content unmarked: comments, forum posts, and review user submissions should use rel="ugc".
• Trusted editorial links nofollowed: these should pass equity. Remove the nofollow.

Best practices

• Use the most specific value: sponsored for paid links, ugc for user content, nofollow for everything else you want to disclaim. They can be combined: rel="sponsored noopener".
• Do not nofollow internal links: "PageRank sculpting" with internal nofollow no longer works and just wastes crawl signal.
• Audit periodically: as content ages, sponsored relationships change. Review affiliate and partner links once a year.