Your GA4 is probably broken — here's how to tell

Why GA4 looks broken when it isn’t

Most teams notice the problem inside GA4. The conversions look too high. The direct traffic makes no sense. The number on the dashboard doesn’t match the number in the export. The natural conclusion is that GA4 is broken and needs fixing.

GA4 is rarely the thing that’s broken. It’s the thing that shows you something else is.

Analytics isn’t one system. It’s seven, chained together, and GA4 sits in the middle of the chain. Three systems feed data in: the tag manager that decides what gets sent, the pixels and scripts that actually fire, and the consent layer that decides whether any of it is allowed through. GA4 itself is the fourth, the property configuration that turns incoming signal into the numbers everyone reads. Then three systems read data back out: the dashboards your team looks at every week, the attribution model that assigns credit, and the BigQuery export you reconcile against when you stop trusting the dashboards.

When a number looks wrong, it usually went wrong somewhere in that chain before GA4 displayed it. The report is honest. It’s faithfully showing you the consequence of a trigger that was right in 2022, a data layer that thins out at checkout, a consent handshake that never fired, or a dashboard built to reassure leadership rather than inform a decision.

The cost of getting this backwards is real. A team decides GA4 is the problem, brings someone in to “fix the analytics,” and that person re-tags events, rebuilds reports, and tidies the property. The dashboard looks healthier for a quarter. Then the same wrong numbers come back, because the cause was a consent handshake that never fired or a container full of triggers keyed to a URL structure that changed two redesigns ago. The work landed on the one system that wasn’t broken. Meanwhile the actual decisions — what to spend, what’s working, which channel to cut — kept getting made on data nobody had reason to trust.

So you’re not auditing GA4. You’re auditing seven systems, and GA4 is the one that makes the other six legible. Three sit upstream, GA4 is the pivot, three sit downstream. Walking them in that order matters, because that’s the order the data moves and the order the problems compound.

Start by finding your symptom.

The symptoms that brought you here

You arrived with a specific symptom, not a general worry about your configuration. Seven of them account for most of what we get called about on GCC marketing sites, and each one points at a different link in the chain.

• Reports full of “(not set).” Dimensions come back blank where you expect a value: landing pages, campaign names, form IDs, product details. GA4 writes “(not set)” when a dimension received no value, so the gap opens before the report does: a data layer that doesn’t expose the values the tags are reaching for, or a session that never sent the page view GA4 takes its landing page from.
• Implausible direct traffic, with your own domain in the referral report. Half your traffic looks like people who typed your URL from memory. They didn’t. Either sessions are being split as visitors cross between separate domains, or campaigns are landing without UTM parameters and the source is genuinely unknown to GA4. On a site running Arabic and English on separate domains, the split is the default behaviour rather than an edge case.
• Conversion counts you don’t believe. Every form submit is a “conversion,” a single purchase shows up as three, or page views are being counted as key events. The number inflates against the business reality you can feel, and both halves of the cause sit upstream: how key events are defined in GA4, and how triggers fire in the tag manager.
• A vendor list nobody can explain, on a site that got slower. The page source or the tag report turns up scripts from companies nobody on the current team chose — a retargeting pixel from a campaign that ended, a session recorder from a test that finished a year ago. That’s pixel sprawl, and on a site whose buyers shop by phone it costs you performance before it costs you privacy.
• More “modeled” traffic than measured traffic. GA4 is filling gaps with statistical estimates, or in some configurations dropping the events entirely, because consent signals aren’t reaching it. A banner that never reports the visitor’s choice leaves every visit on the consent state the page started with, and if that state is denied, the whole site reads as declined.
• Three tools, three different numbers. GA4, the Data Studio dashboard, and the BigQuery export disagree on something as basic as last month’s users, and you can’t tell which one belongs in the board deck. That’s the whole downstream layer at once: dashboards, attribution, and reconciliation each transforming the same data differently.
• Meta says 200, GA4 says 80, and the gap is widening. Your ad platforms report dramatically more conversions than your analytics property does, and the discrepancy isn’t a one-off. Different attribution windows, different click-versus-view rules, browser-level tracking prevention, and platform-side modeling are all pulling the two numbers apart at once.

These aren’t seven unrelated faults. They’re seven windows onto the same chain, which is why a site rarely has just one of them. A consent gap that inflates modeled traffic also widens the GA4-versus-BigQuery gap and the GA4-versus-Meta gap. A messy container is usually the same container loading half the unexplained pixels. Find one and you’ve usually found a thread that pulls two more.

If you want a fast read before working through the sections below, the Site Audit at the foot of this page checks whether analytics and a tag manager are reaching the page at all, alongside the performance and findability signals that surround them. It cannot see inside your GA4 property. Nothing that crawls a public URL can, which is why it tells you whether the plumbing arrives rather than whether it’s configured correctly.

GA4 setup quality

GA4 starts collecting the moment it’s installed. It starts producing trustworthy data only when someone configures it deliberately. The gap between those two states is where several of the symptoms above are born, because this is the single node where raw upstream signal becomes the numbers the whole organisation reads.

Two things go wrong here. The first is conceptual: Google renamed “conversions” to “key events” in 2024, and a new label doesn’t change the mental model underneath it. A key event is a marker that something happened, not a measurement that it mattered. When every form submit and newsletter signup is flagged as a key event, the reporting inflates against anything the business would actually call a result. Enhanced measurement adds events of its own: a scroll the first time 90% of a page is visible, a click on every link that leaves your domain. They record activity, and once one of them is marked as a key event, activity is what your key event count measures.

The second is structural: cross-domain measurement. A bilingual GCC site can run English and Arabic on separate domains, and the boundary that matters is which kind a visitor crosses. Subdomains take care of themselves, because the Google tag writes its cookie at the highest level of domain it can, so ar.example.ae and www.example.ae already share a visitor. Separate root domains do not. Each writes its own cookie with its own ID, so the client identifier resets at the boundary, one visit becomes two users and two sessions, and the second session arrives with your other domain as its referrer, so your own domain turns up in the referral report. If the referrer gets stripped on the way, the same session lands in “(direct)” instead. This isn’t a rare misconfiguration you might have. It’s the normal failure state of analytics on a split-domain GCC site, and it runs unflagged until someone checks for it.

Inflated “(direct)” traffic has another cause, and it sits one layer further upstream: campaigns that arrive without UTM parameters. An influencer link that went out untagged, a paid social ad whose tracking template was never updated after a platform migration, a QR code printed without utm_source. GA4 can’t credit a source it was never told about, so the traffic lands as direct. The fix belongs to whoever builds the campaign links, not to the property, but the report is what tells you there’s a problem to fix.

Underneath both sits a category of setting that stays exactly as it was at launch. Custom parameters get sent but never registered as custom dimensions, so the data is technically arriving and appears in no report. It doesn’t even show as “(not set)”, which GA4 writes only for a dimension that exists and received no value. Data retention on a standard property offers exactly two settings, two months or 14 months, and new properties arrive on the two-month one. That setting governs explorations and funnel reports — standard aggregated reports aren’t affected — so the cost is invisible until the first time someone tries to build a year-on-year exploration and finds there’s nothing behind it. The 14-month maximum is enough to set one month against the same month last year, but a full year against the year before needs 24 months, and a standard property can’t keep that much for explorations. None of these throw an error. They just cap what the property can ever tell you, and our stance is blunt: a GA4 property is either configured on purpose or it is misconfigured by default. There is no neutral middle where the defaults happen to be right for your business.

The configuration audit that follows from that — every key-event definition, the custom dimensions that make parameters visible, and the cross-domain and data-retention settings nobody revisits after launch — is a page of its own, because it’s a checklist you work through rather than an argument you read.

Tag management and the data layer

The tag manager decides what gets sent to GA4 in the first place. It’s the first system upstream, and it’s usually the messiest, because containers accumulate. Tags get added during launches, agency handovers, and one-off experiments, and they almost never get removed. By year three, a container carries tags whose original purpose isn’t documented anywhere, triggers nobody can fully explain, and variables pointing at things that no longer exist.

Underneath the container sits something the container is supposed to read from: the data layer. This is a structured object the site exposes — what page this is, what product is being viewed, what step of checkout the user is on, what the order total was. When the data layer is complete, tags fire with clean parameters and survive redesigns. When it isn’t, GTM falls back to scraping the DOM for CSS selectors and text values, which is brittle by definition: change a class name or restructure a checkout page and tags break with no error anywhere. A data layer usually holds up where it was built, on the homepage and product pages, then thins out across cart, checkout, and post-purchase, which is exactly where the conversion data lives. Those flows change most often, and analytics is rarely in the room when they do. The triggers look fine; the parameters they’re capturing are wrong or missing. When checkout stops sending a value, the e-commerce reports show “(not set)” where it should be.

The damage in triggers compounds the data layer problem. A trigger that was correct in 2022 keeps firing after a site redesign changes the URL structure or the button copy it was keyed to. Nothing errors. The tag just fires on the wrong pages now, or stops firing on the right ones, and the data drifts. Trace a “GA4 is wrong” complaint far enough and it usually ends in one of two places: a trigger that was right when it was built and wrong after a change nobody connected to analytics, or a data layer that was right at launch and never updated through three feature releases.

The container is also where the consent layer breaks without anyone noticing. Variables that read cookies or pull user data without checking consent state will fire regardless of what the banner told the user, which is both a measurement inconsistency and a compliance gap hiding in plain sight.

Server-side tagging deserves its own beat here because most teams ask about it. The engineering case is real: server-side gives you cleaner first-party data, control over what gets sent to which vendor, more durable measurement against browser tracking prevention, and a smaller client-side payload. It also costs more to run and maintain. Our position is the same one you’d take with any infrastructure decision — clean what you have first. A mid-market site running a messy client container should fix the data layer, prune dead tags, and tighten the trigger model before moving to server-side. Server-side is an upgrade, not a remediation; it carries the existing mess across cleanly if you don’t fix it first.

Which makes the order you clean a container in, and what you leave alone the practical question, and it’s a different one from whether the container is messy. It usually is.

If you walked into this role and inherited the container rather than building it, start with inventory rather than cleanup: what’s in here, what does each tag do, what data layer does it read from, who owns it. That audit-on-arrival is its own discipline, and it’s the same one the new-digital-lead playbook covers from the other direction — what to check first when the setup isn’t yours.

What’s actually firing on your site

Most teams can’t list the third-party scripts running on their own site. Open the network panel on a marketing site that’s been live for a few years and the vendor list is longer than anyone currently on the team would guess, with a good share of it predating them. Pixels sprawl the same way containers do, and nobody runs the inventory because nothing forces them to.

There are two stakes, and the order matters here. The privacy stake is real: every pixel is a data-sharing decision, and the cookie banner that declares five vendors while twenty-five are firing is making promises the site doesn’t keep. That feeds directly into the consent problem in the next section.

But in the UAE, at least, the performance stake comes first. A Visa and PYMNTS Intelligence survey run at the end of 2024 found 67% of UAE consumers used a phone as part of their latest retail purchase, a 23% increase since 2022, and put the UAE’s rate of online shopping on mobile, at 37%, ahead of the other seven countries it covered. So the cost of third-party scripts doesn’t land on a desktop visitor with a fast connection and patience. It lands on a phone, on the channel more of your buyers have moved to since 2022.

LCP isn’t the metric to watch first. A pixel loaded asynchronously doesn’t block rendering, though a long task it runs before the largest element paints can still hold LCP back. The metrics that move most directly are total blocking time during initial load and INP for every interaction, because pixels are JavaScript that runs on the same main thread your site uses to respond to taps. A handful of “lightweight” pixels can add up to a measurable INP regression on exactly the sessions you can least afford to slow down. That makes pixel hygiene load-bearing performance work rather than housekeeping, and it runs into the same main-thread budget that decides whether the site feels fast in the performance pillar.

Not every pixel costs the same, and the way to think about it is a ledger: what does each script cost in performance, and what does it return in business value. Marketing analytics tags usually earn their place. Retargeting pixels get added one campaign at a time, each bringing its own JavaScript to the same main thread. Chat widgets sit at the far end of the ledger: the Web Almanac describes them as generally heavier in weight than other third parties. A session recorder’s cost is harder to see. Microsoft reports no measurable load-time impact from Clarity for the vast majority of its users, but the recording takes in clicks, scrolls, mouse movement and every change to the page. The value of both is lumpy, worth it on the pages where you’re actively diagnosing something and dead weight on every other page they’re left running.

The discipline that prevents the next three years of sprawl is small and almost nobody runs it: when you add a pixel, you write down who owns it and when it gets reviewed. A tag with no owner and no review date is a tag that will still be firing long after the reason for it is gone, which is how an inventory nobody has run in three years becomes a performance problem rather than an admin one.

Consent, signal loss, and PDPL

The third upstream system decides whether data is allowed through at all, and it filters your numbers whether or not anyone is watching it. The browser is a fourth filter, stripping data even when consent works perfectly.

Consent Mode v2 governs four signals (analytics storage, ad storage, ad user data, and ad personalization), and you can implement it in one of two modes. Basic mode holds the Google tags back until the visitor answers the banner, and blocks them entirely on a denial; nothing reaches GA4 from that session, and GA4’s behavioural modeling has nothing to work from. Advanced mode loads the tags immediately with denied defaults, so a denied visitor still sends cookieless pings. Which one you run was decided when the banner and the tags were wired together, so check yours before reading anything into the numbers.

The two modes mean different things for your reporting. Under basic mode, a denied user is a missing session. Under advanced mode, GA4 can model that session, but only once the property qualifies: at least 1,000 events a day with analytics storage denied, for at least seven days, and at least 1,000 consenting users a day on seven of the previous 28 days. Even then, the modeled numbers appear only under the Blended reporting identity. A property that doesn’t qualify reports the denied user as missing in either mode.

A banner can also fail to send any signal back to GA4 either way. Then the defaults hold, and the share of your reporting that is modeled or simply absent is whatever those defaults produce. Nobody can read that share from outside the property, and every downstream report depends on it. The modeling itself is real and genuinely useful. It is not a substitute for a consent flow that works, and treating it as one is how a team ends up reporting estimates as if they were counts.

Here’s the part that matters for everything downstream. On a site whose banner never sends an update, modeled or missing data isn’t an occasional event that happens when a user declines. If the page’s default is denied, it is the state of all your traffic. Every dashboard, every attribution model, and every reconciliation you run sits on top of that share, whatever it turns out to be. A team reading its reports as if the numbers were measured, without knowing how much of them is modeled or missing, is making confident decisions on a foundation it has never inspected.

Browsers add a layer on top of consent, and Safari’s is worth stating precisely, because it changed in 2022. That year, Safari’s Intelligent Tracking Prevention dropped its old seven-day expiry cap on JavaScript-set cookies. What replaced it bites in a different way: everything a script can write, cookies included, is deleted after seven days without the visitor interacting with your site, and it’s capped to 24 hours outright when they arrive from a domain ITP has classified as a tracker on a URL carrying query parameters. Neither cares what your consent flow returned. So returning-user measurement on iOS is structurally undercounted: a visitor who comes back a fortnight later looks like a new user, and the conversion path that crosses their iOS visits gets attributed to whatever channel re-touched them most recently.

Size that effect before you act on it, because it depends on the country. StatCounter’s August 2026 figures for mobile page views put iOS at 53.85% in Bahrain and 51.96% in Saudi Arabia, 44.81% in Kuwait, and between 20% and 23% in the UAE, Oman and Qatar. Wherever your share lands, the undercount compounds with the consent gap instead of overlapping with it, and it falls hardest on exactly the returning-visitor and multi-touch paths that ad platforms bill you for.

The compliance picture isn’t uniform either. UAE PDPL and Saudi PDPL are similar but not identical, so a single banner deployed across the GCC has to be checked against each law it serves, and a setup built for the UAE doesn’t answer for Saudi traffic on its own. Companies operating from DIFC or ADGM sit under separate, stricter, GDPR-aligned regimes that don’t share federal PDPL’s lighter touch.

For a long time the honest read on PDPL was that enforcement hadn’t arrived yet, so consent infrastructure was a cost you could defer outside DIFC, ADGM, healthcare, financial services, and government work. That read expired. Saudi’s compliance grace period ended in September 2024, and by January 2026 SDAIA’s specialised committees had issued 48 enforcement decisions in a year, under a law that allows fines of up to SAR 5 million, which can be doubled for a repeat violation. One of the violation categories is marketing communications sent without the required consent, which is the exact ground a marketing team stands on.

So the deferral argument is gone, and what replaces it is a sequencing argument. Consent infrastructure bought as insurance, before anyone has measured what the current setup actually does, is how teams end up paying for a platform that produces the same broken handshake with a nicer banner on top. What we do first is audit the handshake: does the consent signal actually fire, does GA4 receive it, what share of your traffic is modeled or missing as a result. That tells you what you’re exposed to and what your data is worth, and both numbers are ones you’ll want before you buy anything.

Dashboards: trustworthy or theater?

Now the data starts flowing back out, and the first place it gets distorted is the dashboard. A dashboard’s job is to surface the few decisions you can act on this week. The failing kind does the opposite: it presents every metric the team can pull, looks professional doing it, and informs nothing, fourteen tiles for a reader who acts on three.

Data Studio, which Google called Looker Studio until April 2026, is a reasonable place to build one: it’s free, it connects to GA4, and it shares easily. Its specific failure modes are worth knowing. Blended data sources drop rows that don’t match across datasets, without saying so. A ratio worked out row by row is right in every row of a table and wrong in the summary row, which adds the ratios up. Date controls apply to some tiles and not others, so two numbers on the same screen describe different time ranges.

The deeper problem is what gets put on the tiles in the first place. Sessions, pageviews, and average session duration get presented as performance, but they don’t connect to a decision anyone makes. Bounce rate is back on dashboards too, which sounds fine until you notice that GA4 defines bounce rate as the inverse of engagement rate — the percentage of sessions that were not engaged, not the UA-era metric people remember. Same label, different mechanic. Teams read the new number as if it were the old one and reach conclusions about content quality that don’t follow from what GA4 actually measured. Average session duration counts time only in engaged sessions but divides by every session, so a rise in quick exits drags it down whatever the engaged visitors did.

Our test for every tile is one question: if you deleted it, what decision would get worse? If the answer is none, the tile is decoration, and decoration is what makes a fourteen-tile dashboard. A dashboard is a decision document or it’s theater, and theater can take someone a week to build. Which makes the work of cutting a dashboard back to the tiles that change a decision less a design job than an editorial one.

Then there’s the comparison trap, which has a regional shape. Year-on-year is the comparison leadership asks for, and Ramadan moves enough — in timing, traffic pattern, and conversion behaviour — that a naive year-on-year spanning it compares two genuinely different periods and reads the difference as performance. Without seasonal adjustment, the dashboard isn’t measuring your work. It’s measuring the calendar.

Attribution: stop pretending

The second downstream system assigns credit, and the model doing it tells one story about a multi-touch journey. Budget follows that story, whether or not anyone chose the model.

The menu used to be longer. GA4 today gives you three choices in a property’s attribution settings: data-driven, last click across paid and organic channels, or last click restricted to Google paid channels. First click, linear, position-based, and time decay were removed in November 2023, from the comparison and paths reports as well as the settings, and data-driven was already the default by then. If you want one of the retired models now, you rebuild it yourself in BigQuery, where you can read the logic. The implication: if you haven’t touched your property’s attribution settings, you’re reporting on data-driven, a model Google trains on your own property’s converting and non-converting paths, so its credit shifts as your data does. Last click hands all the credit to the bottom-funnel channels that close, paid search and retargeting; data-driven spreads credit using machine learning your team can’t inspect. Both are legitimate. Neither is defensible if you can’t say which you’re using or why.

Then there’s the cross-tool problem, which produces the most common attribution complaint we see: Meta says you got 200 conversions, GA4 says 80, and the gap keeps widening. Both numbers are right, and they’re not measuring the same thing. Meta credits conversions within its own attribution window using its own modeling, including view-through conversions that GA4 never sees: GA4’s cost data import carries other ad networks’ clicks, cost and impressions, not their conversions. GA4 credits each key event with the property’s own attribution model and lookback window, after the consent and ITP filters above have already pulled events out of the dataset. Ad platforms are also biased toward over-claiming, because their job is to justify spend. The reconciliation isn’t fixable with a better attribution model. It’s a question of which framing you defend in the board deck, and whether you’ve built leadership’s tolerance for the fact that Meta’s number, GA4’s number, and the truth are three different things.

The harder truth underneath it: a B2B sale can run for weeks and pass through a WhatsApp thread and an in-person meeting that analytics never sees. Any single attribution model compresses that path into a story it can tell in one channel. None of them is right. The real question isn’t which model is accurate, it’s which misrepresentation you can defend to the person asking where the budget went.

GA4 vs BigQuery: why your numbers never match

The third downstream system is the one you reach for when you’ve stopped trusting the dashboard: the raw BigQuery export. And it won’t match GA4 either, which can send a team on a week-long hunt for the bug.

There is no bug. They’re not supposed to match in a naive comparison. At least three transformations sit between the raw events and what GA4 shows you: sampling, thresholding that withholds data below privacy minimums, and the modeling from the consent gap above. BigQuery gives you the raw events with none of those applied, and without the Google signals data behind some interface reports, which Google doesn’t export at all. “Active users” in GA4 is a specific engagement-based definition; a distinct count of user identifiers in BigQuery answers a different question entirely. Both numbers are correct. They’re answers to different questions, and the mistake is treating one as the truth that proves the other wrong.

The two transformations people conflate are worth separating, because they behave differently. Sampling starts once a request crosses roughly ten million events on a standard property: GA4 computes from a subset and scales it up, to results Google calls directionally accurate. Explorations hit that ceiling first, which is why sampling gets described as an Explore problem, but Google documents the same behaviour in standard reports: filtering a large dataset by country is its own example. Treat any filtered report on a large property as one that can be sampled, and check the icon rather than the report type. Thresholding is the opposite mechanic. When a segment is small enough that reporting it could identify someone, GA4 withholds it entirely, so totals stop adding up, and the reason sits behind the same data quality icon. It bites hardest where demographics or Google signals are involved, which covers the demographic side of audience reporting. A team comparing two numbers without knowing which transformation applied to which will find a discrepancy and chase it for a week. The discrepancy was built into the tools.

Knowing which tool answers which question is the whole skill. Most marketing reporting belongs in GA4. BigQuery earns its place for product analytics, custom funnels, the cross-tool reconciliation work above, and the questions GA4’s interface simply can’t express. That’s a different problem from the attribution bias in the previous section — that one is about which model distorts your channel credit and how external platforms add their own distortion, this one is about why two faithful measurements of the same traffic inside Google’s own stack legitimately disagree. Both resolve in the same place: deciding which question each tool is allowed to answer.

The 15-minute self-test

You don’t need a tool to find out whether you have a problem. You need fifteen minutes and the access you already have. Run these in order; each one tells you which of the seven systems to suspect. They surface problems. They don’t fix them.

1. Fire a key event yourself. Accept your own cookie banner, switch on debug mode through Tag Assistant, and open DebugView. Then trigger one important event on your own site (a form, a purchase, a key click). Does it appear, with the parameters you expect attached? If it’s missing or the parameters are blank, the problem is in GA4 setup or the data layer.
2. Read the acquisition report for one absurd number. Is “(direct) / (none)” implausibly large? Does your own domain appear as a referral source? Cross-domain session splitting and untagged inbound campaigns are the two causes, and both are visible here.
3. Scan your key events list. Does every entry correspond to something the business would act on? If page_view, scroll, or every form on the site is in there, your conversions are inflating.
4. Check whether your consent signal actually arrives. Open your site in Tag Assistant, go to the Consent tab, and work the banner three ways: accept, decline in a fresh session, and load with no choice at all. The On-page Default column shows what the page set before anyone chose, and the On-page Update column should show the choice the visitor made. If it never does, the handshake isn’t landing and your modeled or missing share is whatever your defaults set it to. DebugView can’t run this check, because it hides events from visitors who declined.
5. Count the third-party scripts and name their owners. Use the page source or your tag report. Can you account for each one? Does the count match what your cookie banner declares to users? Gaps on either side are pixel sprawl.
6. Trace one number across three places, then a fourth. Take a figure leadership quotes, like last month’s purchase conversions, and find it in GA4, in the dashboard, and in the BigQuery export. Then compare it to what Meta or Google Ads reports for the same period. Four different numbers means the downstream layer and the ad-platform reconciliation are both transforming data without anyone documenting how.
7. Check your data retention setting. If it’s still on the two-month default, the history you’ll need for a year-on-year exploration is already being discarded.

If two or three of these landed, you have the kind of problem that’s worth an hour of real attention. If five or more did, your reporting has been describing a setup that isn’t measuring what you think it is, and the decisions made on it deserve a second look.

The full audit, and where to take it next

The self-test is the manual version of the diagnosis. It’s also mostly work no crawler can do for you: five of the seven checks need a login to GA4 or your ad platforms, and a crawler has none.

What a crawl can tell you is whether the plumbing reaches the page: whether analytics and a tag manager are present, and how fast the pages it crawls load. That’s the Site Audit below. It won’t list your third-party scripts one by one, and it’s a starting point for the seven checks rather than a substitute for them.

The harder question is which findings actually matter for the decisions you’re making. A modeled-traffic share of 40% is a crisis for a team setting budget by channel and a footnote for a team that only reports total leads. A messy container is urgent if it’s corrupting your primary conversion and ignorable if it’s firing dead tags nobody reads. The audit surfaces symptoms; the judgement about which two to fix first, given what your business actually runs on, is the part worth a conversation.