GA4, Search Console and Bing: the setup explained

By Idea to Traffic Editorial Team · Published August 31, 2026 · Last updated September 27, 2026

Where our search traffic actually came from

We measured 28 days of organic traffic across a network of small utility sites and the split was not close. Roughly 92 percent came from the Bing family, meaning Bing, DuckDuckGo and Yahoo, and about 6 percent from Google. Read in isolation, the near-silent Google report looks like a broken site.

It was a timeline rather than a fault. Bing indexes new sites markedly faster, Google is conservative with domains that have no history and no inbound links, and no amount of resubmitting a sitemap changes that. The value of connecting both instruments early is that you can tell the two situations apart.

A site can be fully live, fast, and well-built, and still be functionally invisible to Google and Bing for weeks, simply because a few specific setup steps never happened. None of these are hard individually. They're just scattered across different products with confusingly similar names.

Google Analytics: the two IDs that get confused constantly

When you install GA4, you get a measurement ID, which looks like G-XXXXXXXXXX. This is what goes in your site's tracking snippet.

Separately, every GA4 property also has a numeric property ID, which is just a plain number, like 123456789. This is a completely different identifier, and it's the one you need for anything involving the Analytics reporting API rather than just the tracking snippet itself. Mixing these two up is one of the most common points of confusion in the entire setup process.

Google Search Console: verification, and what it actually unlocks

Search Console is not analytics. It's how you tell Google "this domain exists, here's what's on it," and it's how you see actual search performance data (what you rank for, impressions, clicks) that Analytics doesn't show you.

The cleanest verification method is a domain property using a DNS TXT record. This covers every subdomain and protocol (http, https, www or not) under one verification, instead of verifying each URL variant separately. Add the TXT record your DNS provider gives you, wait for it to propagate (usually minutes, not hours), then verify.

Once verified, submit your sitemap.xml through Search Console directly. Having the file exist on your server is not the same as submitting it. This step is easy to genuinely forget because nothing visibly breaks if you skip it; your site just gets discovered slower.

The indexing reality check

Even with everything set up correctly, don't expect instant results. A newly submitted page commonly sits in a "discovered, not yet indexed" state for days before Google actually crawls it. This is normal, not a sign something's broken, and there is no legitimate way to force it faster for regular content.

Bing: the step almost everyone skips

Bing still represents real search volume, and setup is genuinely fast if you've already done Google Search Console: Bing Webmaster Tools has a feature that lets you import already-verified sites directly from Google Search Console, skipping DNS verification entirely a second time. Sign into Bing Webmaster Tools, look for the import option, and authorize it with the same Google account that owns your verified Search Console properties.

There is a third ID, and it is the one that breaks API work

The third identifier is the stream ID, also a plain number, belonging to the individual data stream rather than the property.

It is almost never the one you want, and it is easy to copy by mistake because it appears next to the measurement ID in the stream details panel while the property ID is on a different screen entirely. A Data API call sent a stream ID returns a permission error rather than a helpful one, which sends people off checking service account access for a problem that is a wrong number.

The reliable way to get the property ID without hunting: it is in the Analytics URL, after /p, whenever you are looking at a report. Grab it from there and write it down alongside the measurement ID the first time. On a network of sites, that one line of notes is worth far more than the minute it takes.

Confirm the tag is firing before you trust an empty report

An empty property looks identical whether the tag was never installed, was installed with the wrong ID, or is installed correctly on a site nobody has visited. Rule out the first two in ten seconds.

curl -s https://yourdomain.com/ | grep -o 'G-[A-Z0-9]\{10\}' | sort -u

That reads the ID out of the shipped HTML rather than your source files, which matters because the two can differ. The specific failure this catches on a multi-site network is a copied template carrying the previous site's measurement ID, which quietly routes one site's traffic into another site's reports. From inside Analytics that is close to invisible: you see traffic, it just belongs to the wrong site.

Then open the site yourself and check the Realtime report. If Realtime shows nothing while you are demonstrably on the page, the problem is the tag and nothing downstream will help.

IndexNow: what it is for and what it is not

Since you are already in Bing Webmaster Tools, IndexNow is worth setting up, and worth being precise about.

It is a simple protocol for telling a search engine that a URL has changed, without an account or an API key negotiation. You generate a key, host a text file at your site root whose filename is the key and whose contents are the key, and then submit URLs by hitting an endpoint. It takes about five minutes.

It reaches Bing and Yandex. Google does not participate. That single sentence prevents the most expensive misunderstanding here, which is treating an IndexNow submission as your indexing step and then wondering why Google never showed up. If IndexNow is your only submission route, your Google path is zero.

The key file is also worth flagging for a completely different reason: it must keep matching what was registered. If a deploy removes it, or you regenerate a key, previous submissions stop being trusted. It is a few bytes and it belongs in version control alongside your search engine verification files, because it is the kind of file that lives only on the live site until the day a deploy replaces the site.

Set up both engines and expect them to disagree

New domains are treated very differently by Google and Bing, and knowing that in advance stops you misreading your first three months.

Bing indexes new sites markedly faster and starts sending traffic sooner. Google is conservative with domains that have no history and no inbound links. That conservatism is not a fault in your site and it is not something a sitemap resubmission fixes.

Measured across 28 days on a network of small utility sites, roughly 92 percent of organic traffic came from the Bing family, meaning Bing, DuckDuckGo, and Yahoo, and about 6 percent from Google. That split does not persist as a site matures, and it is not an argument for ignoring Google. It is an argument for having both instruments connected, so that a quiet Google report can be read as a Google timeline rather than as evidence that the site is broken.

A note on requesting indexing

URL Inspection in Search Console has a Request Indexing button, and it is fine to use it on a handful of important pages when a site first launches. It is a nudge, not a queue jump, and using it on fifty pages does nothing that using it on three would not.

The Indexing API is a different thing and it is worth not reaching for. It is officially restricted to job posting and livestream event pages, and using it for general content violates the terms. Various tools and plugins offer to do it anyway. The upside is unproven and the downside is a policy problem attached to the property you rely on for data.

The things that actually move indexing along for a small site are unglamorous: pages worth indexing, internal links so nothing is orphaned, a sitemap whose URLs all return 200 in canonical form, and time.

What a correct setup still will not show you

Verification, a submitted sitemap and an IndexNow key get your pages announced. They do not get them indexed: a new page commonly sits in "discovered, not yet indexed" for days, IndexNow reaches Bing and Yandex while Google does not participate, and Request Indexing is a nudge rather than a queue jump. None of it confirms the tag on your site is firing or carries the right measurement ID, none of it links Analytics to AdSense, and none of it survives a deploy that quietly drops your key file or verification files.

Questions about GA4, Search Console and Bing