Direct traffic is supposed to mean people who typed your URL or used a bookmark. In practice it means traffic that arrived without enough information for GA4 to tell where it came from.
If Direct sits at 30%, 40% or 50% of sessions, that isn't how many people type your URL from memory. It's attribution loss: campaigns, emails, social posts and referrals that arrived without a readable source.
What "Direct" means in GA4.
GA4 works out where a session came from using two signals: UTM parameters in the URL, and the referrer header the browser sends when someone follows a link.
If neither is present, GA4 records the session as Direct, with source (direct) and medium (none). That's correct behaviour. GA4 is reporting that it doesn't know.
The problem is upstream: somewhere between the click and the landing, the information was lost. The fix depends on why.
If GA4 does have a source but can't fit it to a channel, the session is Unassigned instead. That has different causes, covered in Unassigned traffic in GA4.
Cause 1: Missing UTM parameters on campaign links.
The most common cause and the most fixable. Emails, social posts and campaigns sent without UTM parameters give GA4 no campaign data. If the referrer is also stripped, which happens a lot in email clients, messaging apps and some social apps, the visit lands in Direct.
How to diagnose it: If Direct spikes on days you sent emails or launched campaigns, the links are almost certainly untagged. You can also open Reports → Acquisition → Traffic acquisition, add Session source / medium, and look for (direct) / (none) volumes that don't match what you'd expect from real direct visits.
How to fix it: Tag every external link to your site with utm_source, utm_medium and utm_campaign: every email, social post, partner link and QR code. Use a URL builder with approved values so the tags stay consistent. This does more to reduce unexplained Direct than anything else.
For values and naming conventions, see the UTM parameters guide.
Cause 2: Referrer stripping in email clients.
Email clients routinely strip the referrer. In GA4, UTM parameters take precedence over the referrer, so correctly tagged email links still attribute properly.
The trouble is the links nobody tags: email signatures, automated transactional emails and PDFs attached to emails. They arrive with no referrer and no UTMs, so they show as Direct.
How to fix it: Treat email as a place with no referrer at all. Tag every link in every email, including transactional sends, signatures and automations.
Cause 3: Dark social and messaging apps.
"Dark social" is traffic from links shared in channels that pass no referrer: WhatsApp, Telegram, Signal, Slack, iMessage, Facebook Messenger and similar. When someone pastes your URL into a chat and a friend clicks it, the visit usually arrives with no referrer and no UTMs, and GA4 records Direct. You can't fully recover this, because the information was never sent.
How to diagnose it: In an Exploration, check which landing pages get the most Direct traffic. If it's mostly the home page, expect a mix of real direct visits and dark social. If specific articles, guides or product pages get far more Direct than their overall traffic would suggest, that points strongly to private sharing.
What you can do: Add UTMs to links you share yourself, in Slack, LinkedIn messages and email threads. For content that gets passed around privately, a share button with pre-tagged URLs captures at least part of the chain.
Cause 4: HTTPS to HTTP referrer loss.
Browsers don't send a referrer when a user goes from an HTTPS page to an HTTP page. If any part of your site is still on HTTP (rare now, but it happens on subdomains, staging sites and old microsites), visits from HTTPS sources lose their referrer and show as Direct.
How to diagnose it: Check whether any entry points are HTTP. If an HTTP landing page gets an unusually high share of Direct, this is a likely cause.
How to fix it: Serve the whole site over HTTPS, including subdomains and every step of any redirect chain. Don't put production UTMs on links to HTTP staging or test environments.
Cause 5: Redirect chains stripping UTM parameters.
This one is often missed. When a tagged URL passes through redirects, the UTMs can be dropped, depending on how each redirect is set up.
The usual case: the team tags a short link or redirect URL, the redirect sends the user on without the query string, and GA4 sees a clean URL and records Direct.
How to diagnose it: Click your own tagged links and check the address bar on the final page. If the UTMs are gone, a redirect is removing them. A redirect checker, or following the chain manually, shows where.
How to fix it: Make every redirect pass the full query string. If you use a URL shortener, choose one that keeps parameters. If the redirect is on your own server or CMS, check it's a 301 that passes the query string rather than one that hardcodes a destination without it.
Cause 6: Safari tracking protections.
Safari's Intelligent Tracking Prevention (ITP) and, more recently, Link Tracking Protection can push traffic into Direct, particularly for iPhone, iPad and Mac users.
Link Tracking Protection strips certain URL parameters that Safari treats as tracking. Standard UTM parameters are generally left alone, but some third-party click IDs are removed before the user lands.
Safari also hides the referrer in some cross-site navigation, particularly in Private Browsing. If a large share of your audience uses Safari (common for consumer and luxury brands), this can add noticeably to Direct.
How to diagnose it: In an Exploration, filter to Direct and break it down by browser. If Safari's share of Direct is much higher than Chrome's or Firefox's for similar traffic, Safari's protections are contributing.
What you can do: Standard UTMs survive Link Tracking Protection in most cases, so consistent tagging still matters most. Server-side tagging can help keep returning visitors recognised, because cookies set by your own server last longer than those set by scripts in the browser.
It won't bring back a referrer Safari has hidden. For more, see the Link Tracking Protection article.
Cause 7: Cross-domain tracking not configured.
If the journey spans more than one domain (a main site and a booking platform, a marketing site and a payment gateway, or a subdomain with its own cookie), sessions can break at the crossing and restart as Direct.
A user arrives from a Google Ads campaign, browses, then clicks through to a checkout on another domain. The checkout sees a new session with no referrer and no UTMs, and records Direct. If the purchase is measured there, Direct gets the credit whatever campaign brought the user in.
How to diagnose it: Look at Direct on your confirmation or thank-you pages. If Direct's share of key events is higher than its share of entry pages, cross-domain loss is the likely cause.
How to fix it: Configure cross-domain tracking so GA4 adds the _gl parameter to links between your domains and joins the session up. See the cross-domain tracking guide.
Cause 8: Session timeout.
GA4 sessions end after 30 minutes of inactivity by default. When a user comes back to an open tab after that, GA4 starts a new session. They didn't click a new link, so there's no referrer or UTM, and the new session records as Direct.
That's why considered purchases and content people read in stages often show high Direct: the user first came from a paid campaign, but buys on a later session after a tab return.
How to fix it: Extend the session timeout to 2 to 4 hours in Admin → Data Streams → Configure tag settings → Adjust session timeout. This cuts timeout-driven restarts without badly distorting session counts. Sessions restarted this way often show a (not set) landing page. More detail is in the unassigned traffic guide.
Cause 9: Bots and automated traffic.
Some Direct traffic isn't human. Crawlers, uptime monitors and security scanners visit without a referrer or UTMs and record as Direct unless filtered.
GA4 excludes known bots automatically, and you can't switch that off. It won't catch everything, particularly internal tools and custom monitoring scripts.
How to diagnose it: Look for odd patterns in Direct: very short sessions, lots of sessions on pages people rarely visit directly, or spikes at regular intervals that match a monitoring schedule.
How to fix it: Point internal monitoring tools away from your live property, or define them as internal traffic (Admin → Data Streams → Configure tag settings → Define internal traffic) and activate the internal traffic filter. If a monitoring service can send a custom user agent, you can also block it in GTM.
A systematic diagnosis.
Before choosing a fix, run this in GA4.
Go to Explore → Blank. Add the dimensions Landing page, Session source / medium, Browser and Device category, and the metric Sessions. Filter to (direct) / (none). Then:
- If Direct is concentrated on the home page and a few popular pages, with a normal browser mix, a good part of it may be real direct visits, bookmarks and dark social. Tagging your own outbound links is what you can control.
- If it's concentrated on campaign landing pages, confirmation pages or pages nobody visits directly, suspect lost UTMs, cross-domain gaps or redirects. All fixable.
- If Safari has a disproportionate share, Safari's tracking protections are contributing. Consider server-side tagging.
- If Direct spikes on campaign send dates, the campaign links aren't tagged.
Summary.
Missing UTMs are by far the most common cause of high Direct. The rest (redirects, cross-domain gaps, timeouts, Safari) each have a specific fix once you know which applies.
Start with the exploration above and fix one cause at a time, so you know which change made the difference.
If Direct stays high after that, Marc Alexander, a GA4 consultant, can trace the rest.