Search Console Subdomain Tracking & Monorepo SEO Tool: Monitor Multiple Websites in One Dashboard

How Google Search Console mixes root domains and subdomains

Google Search Console offers two property types: URL-prefix properties (which match only a single protocol and host, like https://example.com/) and Domain properties (sc-domain:example.com, verified once via DNS TXT record). Most technical founders prefer Domain properties because one DNS record covers http, https, www, and every current or future subdomain.

However, when you query the Search Console Search Analytics API against sc-domain:example.com, Google returns rows for every hostname under that apex domain together. That creates three immediate headaches for multi-project founders and agencies:

• Polluted average position and CTR: Branded navigational searches for a web app subdomain (app.example.com) mix with informational blog queries on example.com.
• False orphan and missing-from-sitemap warnings: If your root crawler inspects example.com/sitemap.xml, it won’t find URLs belonging to docs.example.com/sitemap.xml—causing naive SEO tools to flag hundreds of subdomain URLs seen in Search Console as “unindexed orphan pages.”
• Mixed content repositories: Even when two subdomains share a single Git monorepo, their Markdown files and public assets live in separate app directories.

How Searchbop partitions parent and child hostnames

Instead of forcing you to set up separate Search Console properties for every sub-project, Searchbop uses deterministic URL-scope rules (belongsToSite) when importing Search Console queries, sitemaps, and crawl results:

1. Before you split a subdomain: An unsplit root workspace (https://tengrx.com) monitors the apex domain and discovers active child subdomains that appear in your Search Console data or links, surfacing them as candidates you can split out.
2. After you split a subdomain into its own workspace: The child workspace (for example, https://amin.tengrx.com) claims all URLs on amin.tengrx.com. Simultaneously, the parent workspace (https://tengrx.com) automatically excludes amin.tengrx.com URLs from its own daily metrics, sitemap checks, and open opportunity queue.
3. No double-counting: When a subdomain is split out, Searchbop immediately prunes any open parent opportunities that belonged to that child hostname and triggers a clean visibility refresh so neither workspace lists the other’s issues.

Parent Workspace:  https://tengrx.com
├── GSC Property:  sc-domain:tengrx.com (excluded child hosts: amin, versea)
├── Sitemap:       https://tengrx.com/sitemap.xml
└── Repo Path:     apps/web/content  →  https://tengrx.com/{path}

Child Workspace 1: https://amin.tengrx.com (parentSiteId → tengrx.com)
├── GSC Property:  sc-domain:tengrx.com (scoped strictly to amin.tengrx.com)
├── Sitemap:       https://amin.tengrx.com/sitemap.xml
├── Repo Path:     apps/amin/content →  https://amin.tengrx.com/{path}
└── Initial Mode:  "report" (read-only until explicitly enabled)

Child Workspace 2: https://versea.tengrx.com (parentSiteId → tengrx.com)
├── GSC Property:  sc-domain:tengrx.com (scoped strictly to versea.tengrx.com)
├── Sitemap:       https://versea.tengrx.com/sitemap.xml
├── Repo Path:     apps/versea/content → https://versea.tengrx.com/{path}
└── Initial Mode:  "report" (read-only until explicitly enabled)

Automatic apps/<subdomain> folder discovery in monorepos

If you build multiple products or content hubs inside a single Git repository, each subdomain typically maps to its own package under apps/. When you split a subdomain like amin.tengrx.com in Searchbop, the app inspects your connected GitHub or local repository for a matching apps/amin/content directory.

When found, it automatically pre-configures:

• contentDir → apps/amin/content
• publicDir → apps/amin/public (so llms.txt and IndexNow key files go to the right app’s static root)
• urlPattern → /{path}
• Shared credentials → Inherits the parent site’s Google Search Console property, repository connection, branch, language, country, and AI model selection without re-entering keys.

Why new subdomain workspaces always start in Report-Only mode

Even if your main site is configured to open daily GitHub pull requests, a newly split subdomain might be a web application, a documentation portal with custom build scripts, or an experimental project. To make sure nothing is modified by surprise, Searchbop enforces two strict safeguards whenever you split a subdomain:

• mode: "report" by default: The new subdomain workspace immediately crawls its pages, checks its independent robots.txt and sitemap.xml, and imports its Search Console metrics, but makes zero repository commits or pull requests until you deliberately switch its mode.
• maxNewPostsPerWeek: 0 initially: Automated article generation remains off until you verify the subdomain’s content folder and set a weekly allowance.

When should you split a subdomain into its own SEO workspace?