Your privacy policy versus what your page loads: the Me...

Near the bottom of the Trust + Conversion completeness card, under "Contact + conversion mechanics", the Mega Analyzer prints a short run of rows that have nothing to do with conversion: Privacy policy link resolves, Privacy policy names the trackers this page loads, No pre-ticked consent checkboxes, Session-replay recorder detected and, on medical sites only, Advertising pixel fires on a healthcare-provider page. Together they ask one question. Does the page's disclosure agree with the page's behavior? The analyzer already knows which pixels and recorders the HTML loads. These rows go and read the document that is supposed to admit to them.

What the check actually tests

Privacy policy link resolves. The analyzer takes the first <a href> in document order whose href contains "privacy" or whose link text is exactly "Privacy", "Privacy Policy", "Privacy Notice" or "Privacy Statement" (ignoring case), resolves it against the page URL and fetches it through the site's fetch proxy with a 10 second timeout. It strips <script> and <style> blocks and every tag from the response and collapses whitespace, then decides. A 404, a 410, any 5xx, a final URL whose path is / (the link redirects to the home page) or fewer than 400 characters of remaining text all count as dead. The fail wording spells out which one it was: "Privacy policy link is dead or empty (HTTP 404)", "(HTTP 200, redirects to home)" or "(HTTP 200, 212 chars of text)". The pass wording reports the status and a rough word count: "Privacy policy link resolves (HTTP 200, 1842 words)". A 401, 403 or 429 from the policy URL is not a fail. It becomes an info row, "could not verify: HTTP 403", because the analyzer got blocked, not the visitor. The same info treatment applies when the proxy times out. If the page has no link that matches at all, none of these rows render; the separate "Privacy Policy linked from landing page" row under "Legal + consent surface", lower on the same card, catches that case.

Privacy policy names the trackers this page loads. This row only appears when the policy fetched cleanly and the page loads at least one tracker from the analyzer's list. The tracker scan reads three things in the raw HTML: every script[src] value, every img[src] that points at a pixel-image endpoint (facebook.com/tr, bat.bing, ct.pinterest, analytics.tiktok) and the text of every inline <script>. Fourteen signatures are matched against that haystack, in three kinds. Advertising: Meta Pixel, Google Ads, TikTok Pixel, LinkedIn Insight, Pinterest Tag, Microsoft Advertising UET and Snap Pixel. Analytics: Google Analytics and Google Tag Manager. Session replay: Microsoft Clarity, Hotjar, FullStory, LogRocket and Mouseflow. The signatures are loader URLs and global function names: fbevents.js or an fbq( call for Meta, gtag/js or a G- measurement id for Google Analytics, a GTM- container id for Tag Manager, clarity.ms/tag for Clarity. Each vendor found is then looked for in the policy text with its own pattern. For Meta that pattern is "meta pixel", "facebook pixel", "meta platforms" or plain "facebook"; for Google Analytics it is "google analytics" or "GA4"; for Clarity it is the word "clarity" anywhere. Every loaded vendor with a match turns the row green with the count in parentheses. Any vendor without one fails the row and gets named: "Privacy policy does not mention 2 loaded tracker(s): Meta Pixel, Microsoft Clarity".

Two things do not trip it. Tags that a Tag Manager container injects at runtime are invisible, because the analyzer parses the HTML and never executes it; it sees the container, not the pixels the container adds. And the mention test is a word match, not a reading. A policy that uses "clarity" as an ordinary noun, or says "we share data with Facebook" in a sentence about a Like button, satisfies the pattern. Green here means the vendor's name appears somewhere in the policy. It does not mean the paragraph is adequate.

No pre-ticked consent checkboxes. The analyzer collects every input[type="checkbox"] that carries the checked attribute in the served HTML, then gathers the text around it: the <label for> that points at its id or the <label> that wraps it, plus its name, id, aria-label and the first 120 characters of its parent element's text. If that text matches newsletter, marketing, subscribe, consent, agree, terms, promotional, offers or updates, the box counts, and its name (or id, or the word "checkbox") is printed: "1 pre-ticked consent checkbox(es): newsletter". The row renders only on pages that have a <form> containing a textarea or an input that is not type="hidden", so a bare marketing page never shows it in either state. A box ticked by JavaScript after load is not seen; only the HTML attribute counts. A checked "Remember me" box does not match any of the words and is ignored.

Session-replay recorder detected. This one never fails. Whenever any of the five replay signatures matched, an info row lists them and appends "on a page with form inputs" when the form test above is true, with the advice to confirm input masking, name the tool in the policy and load it after consent where consent laws apply.

Advertising pixel fires on a healthcare-provider page. The row exists only when the analyzer's vertical classifier read the page as healthcare. That is true when the declared JSON-LD types include MedicalBusiness, Physician, MedicalClinic, Dentist, Hospital, Pharmacy or MedicalOrganization, or when the YMYL vertical starts with YMYL-Health. The classifier assigns that from a medical schema type, or from clinical keywords in the title, meta description and first 5,000 characters of body text; a page that reads as editorial or a tool needs at least five of those keywords before it is classified. Dental, mental-health, chiropractic, optometry and podiatry pages get their own YMYL-Health subverticals and count too. On such a page the row fails if any advertising-kind tracker loaded, naming it: "Advertising pixel fires on a healthcare-provider page (Meta Pixel)". Analytics and replay tools do not trip it; Google Analytics on a patient page passes this row even though it is inside the scope of the HHS guidance discussed below. The pass wording is "No advertising pixel on this healthcare page".

Why it matters

The first two rows test the minimum that two statutes and the vendors' own terms agree on. California Civil Code 1798.130(a)(5) tells a business to disclose in its online privacy policy, and update at least once every 12 months, a description of consumers' rights, the categories of personal information collected, sold or shared, and the items listed in Section 1798.110(c), one of which is "the categories of third parties to whom the business discloses personal information". GDPR Article 13 requires that at the time data is collected the controller provide, among other things, "the recipients or categories of recipients of the personal data, if any" (Article 13(1)(e)). Neither can be satisfied by a link that 404s, and neither is satisfied by a policy that never mentions the ad platform receiving the page views. The vendors say the same thing in their own terms. Google Analytics' terms of service require that "You must disclose the use of Google Analytics, and how it collects and processes data", in a privacy policy that gives notice of your use of cookies and device identifiers. Meta's Business Tools terms, Microsoft's Clarity terms and Hotjar's terms each carry a comparable notice requirement.

The pre-ticked row rests on one ruling. In Planet49 (Case C-673/17, judgment of 1 October 2019) the Court of Justice of the European Union held that consent to storing cookies on a user's device "is not validly constituted" when it is given "by way of a pre-checked checkbox which the user must deselect to refuse his or her consent", and that this holds whether or not the information stored is personal data. The court also held that the notice accompanying the consent has to say how long the cookies operate and whether third parties can access them. In the United States, CAN-SPAM does not require opt-in for commercial email at all, while the FCC's TCPA rules require prior express written consent before autodialed marketing texts to a mobile number; under either regime a box the visitor never touched is a poor record of anything.

The healthcare row is where the money is. The HHS Office for Civil Rights bulletin on online tracking technologies, first published in December 2022 and updated in March 2024, says that a HIPAA regulated entity may not disclose protected health information to a tracking vendor without a business associate agreement or an authorization, and it treats an appointment scheduling page, a patient portal and a page a logged-in patient uses as places where a pixel is handling PHI. In June 2024 a federal district court in Texas vacated one part of that bulletin, the part that said an IP address combined with a visit to an unauthenticated public page about a health condition is itself PHI; HHS notes the decision at the top of the page, and the guidance on authenticated pages stands. The FTC has a parallel lever for the businesses HIPAA does not reach. Its Health Breach Notification Rule (16 CFR Part 318) covers vendors of personal health records and related entities, and the final rule the Commission published in the Federal Register on May 30, 2024 made explicit that an unauthorized disclosure counts as a breach of security. The FTC's first action under that rule, on February 1, 2023, was against a telehealth and prescription discount service whose pixels and SDKs had sent users' medication and condition data to advertising platforms, and the counseling and fertility-app complaints that followed that year described the same mechanism: an ad pixel or SDK on a page that handles health information.

How to fix it

Step 1: publish the policy and fix the link. If the row says dead or empty, that is the whole job for now. Legal Pages Generator drafts a privacy policy from a short form, including a CCPA rights section, a GDPR rights section and a "Third-party services" list built from the vendors you tick; give it a real URL such as /privacy/, server-render it (the analyzer, a regulator's crawler and a screen reader with scripts off all read the same 400 characters), and point every footer at that URL. Re-run Legal Pages Audit to confirm the page is discoverable from the footer and dated.

Step 2: add one paragraph per vendor. Run Privacy Disclosure Audit on the page; its fix prompt drafts a paragraph for every vendor the policy does not name, in this shape, and asks you to put them under one heading. Fill in the vendor's legal entity and its current policy URL from the vendor's own site rather than from memory.

<h2 id="third-party-tools">Third-party tools we use</h2>

<p><strong>Meta Pixel.</strong> We use Meta Pixel, provided by Meta Platforms, Inc.,
to measure the results of our advertising and to show ads to people who have visited
this site. It sets cookies and collects device identifiers, IP address, the pages you
view and actions such as form submissions, and sends them to Meta Platforms, which may
also use that data for its own purposes as described in its privacy policy at
[link to the vendor's current privacy policy]. You can opt out of this sharing through
the <a href="/do-not-sell/">Do Not Sell or Share My Personal Information</a> link on
this site.</p>

<p><strong>Microsoft Clarity.</strong> We use Microsoft Clarity, provided by Microsoft
Corporation, which records how visitors interact with our pages (mouse movement,
scrolling, clicks and typing in fields that are not masked) to produce session
recordings and heatmaps. Text you type into forms is masked. Microsoft's privacy
policy is at [link to the vendor's current privacy policy].</p>

<p>Last updated: September 21, 2026.</p>

The vendor names in those paragraphs are what the analyzer's mention patterns look for, so the row goes green on the next run. More useful than the color: a visitor can now find the right opt-out. When the page loads an advertising pixel, the same audit also checks for the "Do Not Sell or Share My Personal Information" footer link that Cal. Civ. Code 1798.135(a) describes, and drafts it. Third-Party Data Leakage Audit classifies a wider set of vendors by what they can see, which is the list you want when writing the "what it collects" clause honestly.

Step 3: untick the box. Remove the checked attribute and leave the wording next to the control. Do not replace the attribute with a script that ticks it on load; that hides the row and changes nothing.

<!-- Before: ticked before the visitor does anything -->
<label><input type="checkbox" name="newsletter" checked> Send me tips and offers</label>

<!-- After: an empty box with the same wording -->
<label><input type="checkbox" name="newsletter"> Send me tips and offers by email (optional)</label>

Step 4: mask the recorder and admit to it. The replay vendors each document a marker for sensitive elements: data-clarity-mask="true" for Clarity, data-hj-suppress for Hotjar, the fs-exclude class for FullStory. Put it on the form, not on individual fields you will forget to tag later, and turn on the vendor's project-level masking mode as well. Then add the replay paragraph from Step 2. Where consent laws apply to your visitors, load the recorder from the consent platform's callback instead of the page head.

<form action="/contact" method="post" data-clarity-mask="true" data-hj-suppress class="fs-exclude">
  <label for="msg">How can we help?</label>
  <textarea id="msg" name="message"></textarea>
  <button type="submit">Send</button>
</form>

Step 5: take the pixel off healthcare pages, or gate it. The clean fix is a template split: the advertising snippet lives in a marketing-page layout and never in the layout used by scheduling, portal, condition and provider pages. If the business insists on keeping it, it loads only after explicit consent with no health data in the payload. For Google tags, the Consent Mode documentation has the default command run before the Google tag and warns that a default set out of order does not work, so the block below goes in <head> above any googletagmanager.com script. This is the snippet the Privacy Disclosure Audit emits when it finds a Google tag without a v2 default:

<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'wait_for_update': 500
});
</script>

Your consent banner then calls gtag('consent', 'update', ...) with granted values after the visitor chooses, and the Meta snippet's fbq('init', ...) and fbq('track', 'PageView') calls move inside the same callback. Re-run the Mega Analyzer and read the row in its pass wording, "No advertising pixel on this healthcare page", before you tell the client it is done.

When to leave it alone

An info row that says "could not verify" is the analyzer being blocked, not the policy being broken. Open the link in a browser; if it loads, the finding is about your bot challenge, which has its own row elsewhere in the report, and the policy needs nothing.

A green tracker row that you know predates the pixel is a word match, not a disclosure. Treat it as unverified and write the paragraph anyway.

A pre-ticked box whose label says "order status updates" or "send me shipping updates" matches the word list without being marketing consent. The honest fix there is a clearer label rather than a legal change; unticking it costs nothing either way.

The replay row is informational by design. If masking is on, the policy names the tool and consent gating is in place where it applies, there is nothing to change; the row will keep appearing and that is fine.

The healthcare row deserves the most judgment. The HHS bulletin itself says tracking on a page that has no access to PHI, its examples being a regulated entity's location, visiting hours, employment opportunities and policies, is not a HIPAA disclosure. The analyzer classifies from the page's own schema and copy, and a hospital careers page carries the same Hospital node and the same clinical vocabulary as the rest of the site, so a recruiting pixel there gets the red row even though the bulletin excuses it; leave it, and keep the pixel out of the appointment and portal templates. The same applies when the classifier has read a medical billing vendor, a health publisher or a clinical-research page as a provider: HIPAA is not the frame there, although the FTC's Section 5 authority and the Health Breach Notification Rule can still be, so the question becomes what the page collects rather than what the row says. If you audit sites for other people, this is the row where a one-line note explaining why you left it red is worth more than the fix; it is the kind of judgment call a client pays for, and the reason The $20 Dollar Agency treats an audit as a document, not a score.

Fact-check notes and sources

Source: https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?sectionNum=1798.130.&lawCode=CIV establishes that Cal. Civ. Code 1798.130(a)(5) requires the online privacy policy to describe consumers' rights and the designated request methods, to carry the disclosures of Section 1798.110(c), and to list the categories of personal information collected, sold or shared and disclosed for a business purpose, updated at least once every 12 months.
Source: https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?sectionNum=1798.110.&lawCode=CIV establishes that Cal. Civ. Code 1798.110(c)(4) is the disclosure of "the categories of third parties to whom the business discloses personal information".
Source: https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?sectionNum=1798.135.&lawCode=CIV establishes that Cal. Civ. Code 1798.135(a)(1) describes the "Do Not Sell or Share My Personal Information" link.
Source: https://eur-lex.europa.eu/eli/reg/2016/679/oj is the GDPR text in the Official Journal; Article 13(1)(e) requires the controller to provide "the recipients or categories of recipients of the personal data, if any" at the time the data is obtained.
Source: https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business establishes that CAN-SPAM requires an opt-out mechanism, not prior opt-in, for commercial email.
Source: https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B/part-64/subpart-L/section-64.1200 is 47 CFR 64.1200; paragraph (a)(2) requires prior express written consent for autodialed or prerecorded telemarketing calls, which includes texts, to wireless numbers.
Source: https://curia.europa.eu/juris/liste.jsf?num=C-673/17 is the case file for Planet49 (judgment of 1 October 2019), which held that consent given by way of a pre-checked checkbox the user must deselect is not validly constituted, that this applies whether or not the stored information is personal data, and that the required information includes the duration of the cookies and whether third parties may access them.
Source: https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-online-tracking/index.html is the HHS OCR bulletin on the use of online tracking technologies by HIPAA covered entities and business associates (December 2022, updated March 2024). It establishes the business associate agreement and authorization requirements, the treatment of authenticated pages such as patient portals, the exclusion for pages with no access to PHI (location, visiting hours, employment opportunities, policies), and carries the note on the June 20, 2024 district court decision that vacated the guidance as it applied to unauthenticated pages.
Source: https://www.ftc.gov/legal-library/browse/rules/health-breach-notification-rule establishes that the Health Breach Notification Rule (16 CFR Part 318) requires vendors of personal health records and related entities to notify consumers after a breach of unsecured information, and lists the Federal Register notice of May 30, 2024 for the amended rule that treats unauthorized disclosure as a breach of security.
Source: https://www.ftc.gov/news-events/news/press-releases/2023/02/ftc-enforcement-action-bar-goodrx-sharing-consumers-sensitive-health-info-advertising is the FTC's February 1, 2023 announcement of its first Health Breach Notification Rule action, against a telehealth and prescription discount provider, for sharing users' health data with advertising platforms through pixels and SDKs.
Source: https://marketingplatform.google.com/about/analytics/terms/us/ establishes, in the Privacy section of the Google Analytics Terms of Service, that "You must disclose the use of Google Analytics, and how it collects and processes data" and must post a privacy policy that gives notice of your use of cookies and device identifiers.
Source: https://developers.google.com/tag-platform/security/guides/consent is Google's Consent Mode setup guide; it defines the default command with ad_storage, ad_user_data, ad_personalization, analytics_storage and wait_for_update, has the default run before the Google tag, and states that consent defaults do not work when the consent code is called out of order.
Source: https://learn.microsoft.com/en-us/clarity/setup-and-installation/clarity-masking documents the data-clarity-mask attribute and Clarity's project-level masking modes.

Your privacy policy versus what your page loads: the Mega Analyzer disclosure rows