Search Console for three brand domains: properties, sitemaps and what the reports said

One domain property per brand

Search Console reports per property, and a property is a domain, not a Shopify store. Three brand domains on one store are three properties, and nothing in Search Console joins them up. We have sc-domain:diviartsstudio.com, sc-domain:shopfernandnest.com and sc-domain:foreverartify.com.

We used domain properties, verified by a DNS TXT record, rather than URL-prefix properties. A domain property covers www and bare, http and https, in one report. With URL-prefix properties, a brand served on www but linked without it is split across two reports, and on three brands that is six chances to read the wrong half. The general case.

Which sitemap to submit

Not /sitemap.xml. That is Shopify’s whole-catalogue file, the same on every domain, and our robots.txt now disallows it. Each brand’s property gets that brand’s own index and nothing else.

Umbrella serves its sitemaps from a separate host, so they stay up if the app does not. That adds a step the app spells out:

We took the other route the app offers: the same index is also served on each brand’s own domain under /a/umbrella/, so the sitemap and its URLs share a host. That is what we submitted, on 22 October 2026:

Umbrella counts 214 URLs for Fern & Nest and Search Console discovered 211. We have not chased the difference of three. The index lists child sitemaps whose contents change on rebuild while the index URL stays the same, so there was nothing to resubmit afterwards.

Reading the Page indexing report

This is the report that alarms people on a multi-brand store, so it is worth reading slowly. Fern & Nest’s, last updated 15 October 2026:

“936 not indexed” looks bad until you open the reasons:

• Alternate page with proper canonical tag, 581. The largest row, and the one we wanted. Every product on the store can be opened on every domain. When Google reaches a DiviArts Studio print through shopfernandnest.com, the page names diviartsstudio.com as its canonical, so Google files it here. This row is the canonical doing what it says.
• Page with redirect, 225. URLs that redirect somewhere else, such as the bare domain to its www form.
• Blocked by robots.txt, 20. Paths the robots rules disallow: Shopify’s standard ones, such as cart and internal search, and Shopify’s own sitemap files, which we now disallow on purpose.
• Not found, Soft 404, noindex. Small numbers, worth working through, and not related to brands.
• Discovered and Crawled, currently not indexed, 78 together. These are Google’s own decisions. Nothing in this setup controls them, and we are not going to pretend otherwise.

The rows to watch are the last ones, not the first. A large “alternate page” row on a brand domain is the expected shape of a store whose catalogue is reachable everywhere and credited in one place.

What we did not do

• Hide other brands’ products from a domain. They are still reachable everywhere, because it is one store. The canonical says which domain each belongs to; hiding them would need per-domain logic that Shopify does not support.
• Use the Removals tool. It hides URLs from results for a while. It is not a way to say which domain owns a page.
• Request indexing page by page. The sitemaps are the discovery path; requesting hundreds of URLs by hand would not tell Google anything the sitemap does not.

Next

Part 4 is about Umbrella’s own site, where a setting in Cloudflare served a different robots.txt from the one in our repo, and nothing in the deploy showed it.

• Previous: Part 2. Setting up Umbrella on a live store: per-brand sitemaps, canonicals and robots.txt
• Next: Part 4. The Cloudflare setting that overrode our robots.txt
• The series and the full checklist

Install on Shopify