How to Set Up Google Search Console and GA4 for Multiple Domains

If your company operates more than one domain—a .com plus a .ca, a regional split, an acquired sub-brand—there's about a 70% chance your Google Search Console and GA4 setup is suboptimal. Not broken. Just structured in a way that makes cross-domain reporting hard, attribution unreliable, and weekly check-ins more painful than they need to be.

The most common patterns: one GSC property per site, no unified reporting view, channel-level reports that miss half the traffic from the secondary domain. Or worse: GA4 set up with one cross-domain measurement stream that loses the ability to see per-site performance because everything's aggregated.

Both are fixable. The fix isn't complicated. But it requires making a few specific architectural decisions up front—and accepting that GSC and GA4 handle multi-domain differently. GSC has no native rollup. GA4 does. This post walks through those realities and how to structure reporting so executives get one view while operators still get per-site detail.

The setup mistake to avoid

The default path looks like this. A company launches its primary domain at acme.com. They set up GSC and GA4. Six months later, they add acme.ca for the Canadian market. They set up a new GSC property and a new GA4 property because that's what the platform suggests. Two years later, they acquire a smaller brand and add a third GSC property and a third GA4 property.

Now they have three GSC properties and three GA4 properties. To answer "how is our SEO doing this quarter?", someone has to:

• Pull three GSC exports
• Reconcile them in a spreadsheet
• Match up GA4 sessions to the right property (and they don't always reconcile cleanly because GA4 sessions and GSC clicks are different measurement layers)
• Build a quarterly chart that's manually updated

This is a process problem caused by a setup problem. The fix is upstream—but it looks different for GSC than it does for GA4.

GSC: property types and the rollup reality

Google Search Console has two property types. Picking the right one for each site is the first architectural call. But here's the hard truth: GSC has no native way to aggregate multiple domain properties into a single view. Unlike GA4, there's no "rollup property" or "property group" feature. Each domain is its own silo.

Domain properties vs URL-prefix properties

A Domain property (e.g. sc-domain:acme.com) captures every variation of the domain: with/without www, with/without HTTPS, every subdomain (blog.acme.com, app.acme.com, etc.).

A URL-prefix property (e.g. https://www.acme.com/) captures only that exact variation. https://acme.com/ (no www) would be a separate property.

For 90%+ of cases, Domain properties are correct. They're the modern setup. They consolidate fragmented data. They require DNS verification once and capture everything.

URL-prefix properties are appropriate when you specifically want to track sub-sections separately for reporting (e.g. https://www.acme.com/blog/ as its own property for content-team visibility). They can complement Domain properties; they shouldn't replace them.

How to get a unified GSC view

Since GSC doesn't offer native rollups, you have three options:

Option 1: Manual export and combine Pull CSV exports from each property, combine in a spreadsheet. This works but doesn't scale and introduces human error.

Option 2: Looker Studio with blended data Connect each GSC property as a separate data source in Looker Studio. Create a blended data source to combine them. This gives you a unified dashboard, but blending has limitations—you can't do complex joins, and some metrics don't blend cleanly.

Option 3: GSC API + aggregation layer Use the Search Console API to pull data from all properties programmatically, then aggregate in a database, data warehouse, or third-party tool. This is the most flexible and accurate approach, but requires technical setup.

For executive reporting, Option 2 or 3 is where you need to land. Manual exports work for one-off analysis but break down for recurring reporting.

GA4: stream architecture

GA4 handles multi-domain better than GSC. You have two reasonable options:

Option A: One GA4 property per site (separate properties)

Each site has its own property and its own measurement stream. Per-site reporting is clean and isolated. Cross-site reporting requires manual joins or Looker Studio blending.

This is the right call when:

• The sites have different user bases that don't overlap
• Different teams own each site and want independent reporting
• One site is on a sub-brand that you might divest

The trade-off: any cross-site analysis (a user who hit acme.com first, then converted on acme.ca) is impossible within GA4.

Option B: One GA4 property with multiple data streams

One GA4 property has multiple data streams—one per site. The property aggregates everything; the data streams let you filter by site.

This is the right call when:

• All sites are part of the same brand and the same business model
• Users meaningfully cross between sites
• You want a single conversion/lead funnel view

The trade-off: per-site segmentation requires filtering by stream_name (or by hostname), which works but adds friction.

Cross-domain measurement

If you go with Option B AND users genuinely cross domains, configure cross-domain measurement: GA4 admin → Data streams → Configure tagging settings → Cross-domain measurement. Add each domain. This preserves user sessions across the domains without losing attribution.

If you skip this, every cross-domain navigation starts a new session, doubles your apparent user count, and breaks funnel attribution. It's a 5-minute fix that's commonly overlooked.

A worked recommendation

For a B2B SaaS with .com (primary), .ca (regional), and a recently-acquired brand with its own domain:

GSC: Three Domain properties (one per site). Use Looker Studio or the GSC API to create a unified reporting view. Accept that this requires external tooling—GSC won't do it natively.

GA4: For .com and .ca (same brand, same product): one GA4 property with two data streams + cross-domain measurement. For the acquired brand: separate GA4 property until and unless the brand is fully merged.

Reporting:

• Executive weekly: Looker Studio dashboard pulling from all GSC properties + main GA4 property
• Per-site teams: Individual GSC properties + GA4 data stream filters
• Acquired brand team: Standalone GSC + GA4

What changes about reporting

Once the architecture is right, your reporting questions change shape—but the answers come from different places depending on the platform.

"How is our SEO doing?" → Pull from your unified Looker Studio dashboard or API-aggregated view. One chart. No manual reconciliation.

"How is the Canadian site doing?" → Pull from acme.ca Domain property directly. Separate chart, deliberately scoped.

"Which pages drive the most conversions?" → Pull from GA4 main property, segmented by host. Reveals whether your conversions are concentrated on .com or distributed.

"Did the recent algorithm update affect us?" → Compare all GSC properties pre/post update. If the aggregate is flat, no impact. If the aggregate is down but only acme.ca is down, the impact is regional.

This last question is where the unified vs per-site distinction earns its keep. A site-wide algorithm impact looks different from a single-site impact, and you can only see the difference when you have both views available.

Channel-level analysis with multiple sites

A common reporting need: "show me organic clicks by channel/source." If you're doing this in GA4 with multiple sites, the channel rollup needs to account for site mix.

The trap: a site with strong organic traffic on .com and weak organic on .ca might show "organic = 65% of traffic" at the aggregate level. But .com is 80% organic and .ca is 30% organic. The aggregate hides the imbalance.

The fix: always segment channel-level reports by host (or data stream) when comparing across multiple sites. Show two side-by-side mini-charts rather than one aggregated chart.

This is true for paid channels too. If you run Google Ads on both sites, the cost-per-acquisition might be wildly different between them. Reporting that lumps both together hides the optimization opportunity.

URL normalization across properties

A subtle but important reporting issue: GSC stores absolute URLs, GA4 stores path-only URLs. When you join GSC and GA4 data for cross-property page-level analysis, you need to normalize.

The standard approach: strip protocol, strip www., strip trailing slashes, strip query strings. Both sides reduce to a canonical path. Then they join.

In a single-domain context this is straightforward. In multi-domain, the canonical path needs to include the domain to be unique—acme.com/pricing and acme.ca/pricing are different pages but share the path.

If you're building this manually in a spreadsheet, the formula is:

canonical_url = host + path

Where host is the domain (extracted from GSC's absolute URL or set explicitly for GA4 data) and path is the path-only URL.

Most BI tools handle this fine if you set up the joins explicitly. It breaks when teams assume "URL" means the same thing across GSC and GA4. It doesn't.

What about historical data

If you're migrating from a fragmented setup to a consolidated one:

GSC: New Domain properties start collecting data from the verification date forward. There's no backfill. Older data stays in the URL-prefix properties (if those exist). You'll have a transition period of 3–6 months where you reference both.

GA4: New properties start collecting from setup forward. Older data stays in the previous properties. No merging.

Looker Studio dashboards: Can pull historical data from each underlying GSC property going back to when those properties were verified. So a unified dashboard created today can show historical data—it's just pulling from multiple sources.

The migration playbook: set up the new architecture in parallel with the old. Run both for 60 days. Confirm new is reporting correctly. Switch reporting to new. Archive old.

The MCP angle

If you've connected an AI assistant to your SEO data, multi-domain becomes easier in one specific way: you can ask cross-site questions in chat instead of building cross-site reports.

"How did organic do across all my domains last month?" → The AI calls the appropriate company-scoped tool and returns the aggregated view.

"Which of my sites had the biggest content decay this quarter?" → The AI iterates by site and returns the comparison.

The catch: the platform you're connecting to needs to support multi-domain aggregation. If your platform treats each domain as a fully isolated tenant, you can only ask one site at a time. Platforms that handle multi-domain natively can serve an aggregated view via MCP—solving the problem that GSC itself doesn't solve.

What this looks like in Algoist

Algoist's multi-domain architecture is built around the aggregation concept that GSC lacks natively. Companies can have multiple linked domains (a parent .com plus child domains for .ca, regional sites, sub-brands). Team access flows across all linked domains automatically—no re-invitations needed when you add a new domain.

For clients with multiple linked domains, the dashboard header shows a domain switcher (a globe icon next to the clock). Click it, switch context, and every report—GSC overview, GA4 dashboard, CTR opportunities, content decay, cannibalization—re-scopes to that domain. Aggregated reporting across all linked domains is available for executive-tier access.

For MCP users, the list_companies tool returns every linked domain the caller can access. Pass company_id explicitly to scope queries to a specific domain, or omit it to use the default. Cross-domain queries from a single chat are now a one-line ask.

FAQ

Should I consolidate my multiple GSC properties into one? You can't—GSC doesn't support multi-domain rollups. Keep your individual Domain properties and build a unified view in Looker Studio or via the API.

Will switching to a Domain property lose my historical data? The Domain property starts collecting from verification date forward. Your URL-prefix properties keep their historical data. You'd reference both for a transition period.

What if my domains share some content (e.g. the same blog cross-published)? Use canonical tags to designate the primary version. GSC will attribute the canonical URL. Don't try to track the same content as two separate pages on two sites—set canonical, let Google handle attribution.

How do I handle subdomains? Domain properties cover all subdomains automatically. If you have a blog at blog.acme.com and want separate reporting, add a URL-prefix property for that subdomain in addition to the Domain property.

My .ca site uses a different language. Does that change the setup? Not the GSC/GA4 setup, but you should add hreflang tags on both sites so Google knows which language version to serve to which user. Don't conflate "multi-domain" with "multi-language"—they're separate architectural decisions.

Should I run separate Google Ads accounts per domain? Different question. Usually yes, for billing isolation, budget control, and reporting clarity. The exception is when you have a unified marketing budget and a single ads team running both. Most multi-domain companies prefer separate accounts.

Can I use GA4 audiences across multiple data streams? Yes, if you use Option B (single GA4 property with multiple data streams). Audiences built at the property level include behavior from all streams. This is one of the bigger reasons to consolidate into a single property when users cross domains.

Multi-domain SEO is mostly an architectural problem, but GSC and GA4 require different solutions. GA4 can aggregate natively with multiple data streams. GSC cannot. Get the property setup right at the start; Domain properties in GSC, unified reporting via Looker Studio or API, single GA4 property with multiple data streams for shared-brand setups, separate properties for distinct brands and reporting becomes a 10-minute conversation instead of a quarterly project.