Ask a San Francisco software company how many websites it runs and the answer is usually "one." Then somebody remembers the docs subdomain, the changelog, the status page, the engineering blog, two microsites from a conference push, and the product acquired eighteen months ago that still serves its own marketing site. The count is eight, and there is no owner.
None of that happened by decision. Each surface was stood up by whoever needed it, in the week they needed it, on whatever stack was closest to hand. Docs went up with the developer portal. The changelog came free with a release tool. The careers page sits on a recruiting vendor's domain because that was the fastest path to a job posting. Every one of those choices was locally cheap and correct at the time, and the sum of them is a web presence nobody has looked at whole in years.
The surface multiplied and no one was assigned to it
The pattern is specific to engineering-led companies, and the fix differs from the one for a company that deliberately runs several brands. A holding company knows it has six domains; it has a spreadsheet. A software company frequently does not, because each surface arrived as a side effect of shipping something else.
- The marketing site. Owned by whoever is doing growth this quarter, rebuilt roughly every two years, and the only surface anyone thinks of as "the website."
- Documentation on a subdomain. Usually the largest property by page count, often generated from a repository, and frequently the highest-traffic thing the company operates.
- Changelog, status and the engineering blog. Three small properties on three different tools, each publishing regularly, none in anyone's reporting.
- Campaign leftovers. A launch microsite and a conference landing page that were never taken down and never redirected, still indexed, still describing a version of the product that no longer exists.
- The acquired product's site. Bought with the company, kept alive to avoid breaking customer links, and quietly competing with your own pages for the same terms.
What makes this a search problem rather than an inventory problem is that the surfaces are not independent. They compete. They inherit each other's authority. They send crawlers in circles. And because each one was configured by a different person, they disagree about basics: canonical hosts, whether there is a trailing slash, which pages are meant to be indexed at all.
Instrumented to the millisecond, and unmeasured at the front door
Here is the asymmetry that defines this city's version of the problem. The same company that traces every request through four services, alerts on p99 latency, and can tell you the conversion rate of a single onboarding step has no idea which of its eight web properties earns impressions, or which pages of those properties rank for what.
The reason is not negligence. The product has an owner; the marketing surface only has an audience. Engineering instruments what it is accountable for, and nobody is accountable for the search behaviour of a documentation site that was never treated as a marketing asset.
The consequence is a familiar and slightly embarrassing outcome: the documentation site outranks the product page for the product's own category term. It has more pages, more inbound links from developers quoting it, and more regularly updated content. So a buyer searching for the category lands on a reference page for an API endpoint, reads a parameter table, and leaves. The marketing site — the one with the pricing, the case studies, the trial button — never entered the conversation.
One workspace, several projects, one login
The organising idea is straightforward: a single workspace holds many projects, one per property, and everything above the project — accounts, seats, connected Google data, reporting — belongs to the workspace rather than to any individual site.
One dashboard per site
Each property carries its own login, its own connected Google account and its own idea of who is allowed in.
- Comparison happens in a spreadsheet
- Access dies with the person
One workspace, many projects
Properties become projects under one account, and everything shared — identities, seats, reporting — moves up a level.
- Portfolio views come for free
- Seats granted per property
The account level — Google connections, seats and tags
What you configure once and never repeat per property.
- Linked Google account groups. More than one Google identity can hang off the same workspace — which matters when Search Console verification is scattered and cannot be consolidated immediately.
- One consent flow. Search Console, Analytics and Gmail are authorised together through a single OAuth2 grant rather than three separate connection dances per property.
- Site tags as a global filter. Tags applied to properties act as a filter across the whole workspace, so "customer-facing" or "acquired" becomes a lens you can apply to any view.
- Sharing by email address. An individual site can be shared to a specific address without handing over the workspace — how a contractor gets exactly one property.
The per-property level — data, campaign and assistant
What each property gets on its own, independent of the others.
- Its own Search Console and results-page views. Site overview, keywords with position history, pages, devices, countries and traffic, scoped to that property alone.
- Its own keyword pool and approval queue. Candidates from Search Console, live results and your seed list, each one accepted, refused or deferred for that property specifically.
- Its own Stream feed. The assistant runs per project, with the conversation, the automated reports, the newly placed links and the to-dos for that site in one chronological feed.
- Its own campaign tier, or none. A property can sit in the workspace purely for measurement without any paid campaign attached to it.
That last point does most of the work here. Eight properties do not need eight campaigns; they need eight measured properties and, realistically, one or two funded ones. The workspace makes that separation cheap, because the reporting layer does not care whether a project pays for automation.
Access archaeology, which is half the actual job
Now the second thread, and the one that consumes more calendar time than anyone budgets for. The person who verified Search Console for the main domain in 2021 has left. The verification is attached to their personal Google account, which was deprovisioned, or worse, was never a company account at all. The docs site was verified by an engineer who is still here but does not remember doing it. The acquired product's property is inside the acquired company's Google organisation, which nobody has logged into since the deal closed.
| Property | Who verified it | Where access lives | What it blocks |
|---|---|---|---|
| Marketing site | Former growth hire | Deprovisioned account | All historical query data |
| Docs subdomain | Current engineer | Personal Google account | Nothing, until they leave |
| Changelog | Never verified | Nowhere | Any measurement at all |
| Launch microsite | Agency, contract ended | Agency's workspace | Removal and redirect decisions |
| Acquired product | Acquired company's admin | Separate Google organisation | Consolidated reporting |
Two of these are quick. Re-verification through DNS is a ten-minute change wherever somebody controls the zone file, and it does not require finding the original person. The others take longer, and the delay is administrative rather than technical: waiting on a former employer's IT contact, or a vendor with no reason to answer email.
The multi-account handling matters precisely here. Because a workspace can carry more than one linked Google account group, you do not have to finish the consolidation before you start reading data. The engineer's personal-account verification can feed the workspace today while the company-account re-verification proceeds in parallel, and the reporting does not have a hole in it during the transition.
Which properties deserve a project, and which just deserve a look
Not every surface is worth the same treatment, and the per-domain pricing forces the question early. A useful sorting runs on two axes: whether the property can win search demand you want, and whether you control it enough to change anything.
Properties that can convert
The marketing site, and — more often than teams expect — the documentation site, which already has the traffic and needs only to stop being a dead end.
- Own the category terms deliberately
- Route docs readers toward the product pages
- Worth a campaign tier
Properties that inform
Changelog, engineering blog and status page. They accumulate links and impressions and tell you what developers search for, but they are not where you spend.
- Verified and reported, no campaign
- Watched for accidental cannibalisation
- Tagged so they filter out of the main view
Campaign leftovers
Launch and conference microsites describing a product generation that has passed. Their value is the links pointing at them, not the pages themselves.
- Redirect to the closest live page
- Preserve inbound authority
- Remove from the index deliberately
Pages on vendor domains
The careers page on a recruiting platform's domain and anything hosted inside a third party's URL structure. You cannot verify what you do not control.
- No project, no verification
- Track as a competitor-shaped entity
- Link to it, do not rely on it
The shared quotas that only bite when you run several properties
Single-site users never meet this. The moment you hold eight properties in one workspace, account-level limits become a scheduling problem, and indexing is where that shows up first.
Read the first tile carefully: the daily tracking budget is per account, not per project. A documentation site regenerated from a repository can produce a few thousand changed URLs in a single merge, and if you push all of them, the marketing site's newly published pages wait behind them. The queue holds up to twenty sitemap jobs while two run, so nothing is lost — but the ordering is a decision somebody has to make, and by default that decision is "whoever submitted first."
The practical arrangement is a rota rather than a race. Give the property with genuinely time-sensitive pages first call on the daily budget, and let the large generated one submit in batches on days when nothing else ships. Submission goes out through IndexNow to Google's and Bing's crawlers, and each URL carries its own log line — bot visit with a timestamp, status, error detail — so you can see which property consumed the day.
The acquired site, which nobody wants to touch
The acquired product's website is the most common unresolved item on the list, and the reason is reasonable caution. Its pages carry links, its URLs sit in customers' bookmarks and in other people's documentation, and whoever understood its content structure did not come with the acquisition. So it stays up, unchanged, and increasingly wrong.
Bringing it into the workspace does not mean merging it into your domain. It means holding it as its own project, with its own keyword set and its own reporting line, and then answering one question with data instead of instinct: is it competing with you, or is it feeding you? The competitors view answers the first half by showing which domains occupy your keyword space — and it will sometimes name your own acquisition, which is the moment the conversation changes.
| Finding | What it means | Reasonable response |
|---|---|---|
| Ranks for terms you also target | Two of your pages split one demand | Consolidate content, redirect the weaker page |
| Ranks for terms you ignore | It holds a distinct audience | Keep it, fund it separately, link it inward |
| Strong inbound links, thin traffic | Authority without relevance | Redirect selectively, preserve the link equity |
| Neither ranks nor earns links | It is costing hosting and confusion | Redirect wholesale to the closest live page |
Once several properties are in place, the workspace-level views become the ones you actually open. The Search Console dashboard spans every verified site with clicks, impressions, click-through rate and health flags side by side; the rank tracking carries a global ranking score across the entire domain portfolio with a twenty-eight-day trend. That portfolio number is the first metric most of these companies have ever had for their web surface as a whole, and it is usually the one that finally gets the attention of somebody senior. The cross-property analytics view is where the docs-outranks-product problem becomes visible in about four seconds.
Questions engineering-led teams ask
Do we need a paid campaign on every property we add?
No. Campaign tiers are priced per domain, but a property can be verified, connected and reported on without one. Most companies here start with everything measured and one or two properties funded, then move the funding once the portfolio view shows where demand actually is.
Our Search Console access is spread across three Google accounts. Do we have to fix that first?
Not before you start. A workspace supports linked Google account groups, so several accounts can feed it at once. Consolidating onto company-controlled accounts is still worth doing — it removes a dependency on individuals — but it can run in parallel rather than blocking measurement.
Can a contractor see one site without seeing everything?
Yes. Individual sites can be shared to specific email addresses, so an agency working on the documentation site gets that project and nothing else. This is also the cleaner arrangement for an acquired product's remaining staff, who often need their own site and no visibility into yours.
Our docs site is generated. Does anything here assume a CMS?
No. Measurement, rank tracking and indexing submission are all external to how pages are produced. What changes with a generated site is the volume of URLs arriving at once, which is why the daily indexing budget matters more for you than for a twenty-page brochure site.
How long before the portfolio view tells us anything useful?
The inventory and access picture is useful immediately — often the first complete list the company has had. Ranking movement from campaign work typically takes four to eight weeks to register, and Search Console data runs about two days behind, so read the first fortnight as description, not progress.
Start with the list, not with the strategy
The temptation for a technical team is to design the end state first: which properties merge, which subdomains become subdirectories, what the canonical architecture should be. That conversation is enjoyable and it will stall, because it depends on facts nobody has yet. Each property's traffic, its ranked terms and the true overlap between them are all unknown when the debate starts.
So invert it. Spend the first week producing the honest inventory and verifying everything you control the DNS for. Spend the second reading the portfolio view with all of it connected — the cross-site dashboard, keyword movement into and out of the top three, ten and thirty, and the competitors list that occasionally names your own acquisition. By then the architecture argument resolves itself, because the numbers make two or three options obviously wrong.
One more thing, for companies whose buyers are themselves technical. The docs site outranking the product page is not always a fault to be corrected — sometimes it honestly reflects how your market evaluates software, and the right response is to make the documentation a better front door rather than suppress it. You can only make that call with both properties in one view. Our other pieces on reading query and position data are in the articles index, and the scope of work outlines cover running the portfolio pass for you.
If it is easier to judge with your own domains on screen, connect the first property and open the workspace, then add the rest as verification allows. The projects and seats configuration sits alongside the indexing submission tools and the per-project assistant, which takes URL and keyword lists in batches — useful on day one, when the thing you have is a list of eight domains and no idea which of them is carrying the company.