A domain estate in a Stockholm software company is rarely a portfolio anyone designed. It is sediment left by acquisitions, launches and rebrands, and the useful question about any address in it is not which brand it belongs to but whether a named person will still be answerable for it next quarter.
Ask an engineering-led company here how many hostnames it answers on and the first number is too low. The corrected number, twenty minutes later, surprises the person who gave the first one. That gap is what happens when addresses are created by company events rather than marketing decisions.
Nobody held a meeting called "let us operate nine domains". There was a funding round, an acquisition, a developer conference and a repository that got popular. Each left an address behind, and each kept serving traffic long after its reason for existing had lapsed.
Nobody decided to run nine domains
The composition is consistent across firms of this shape, and reconstructing it is worth an hour — the reconstruction is also the first draft of the responsibility map.
- The product site. Owned, staffed, redesigned every few years. The only address named in the first answer.
- A second product that came with an acquisition. Bought for the team or the technology, never folded into the main brand because that was always next quarter's work. It still ranks, on the stack the acquired team preferred.
- The open-source project on its own domain. Split out so the library would not look like a vendor product. It now outranks everything else the company owns for one technical term.
- The developer portal. Its own host and its own release cadence, maintained by whoever last needed a change shipped.
- A conference microsite from a launch two years ago. Agenda, speaker photographs, a registration form pointing at a service nobody pays for. Still indexed under the event name.
- The previous brand. Whatever the company was called before the round that renamed it. Redirected in principle; in practice for some paths only.
None of these arrived through a channel strategy; they arrived through corporate biography. The distinction matters operationally: a portfolio built by decisions has an owner per decision, one built by events has an owner per event — and events end.
Is anyone answerable for this address next quarter?
Most advice on managing several websites asks you to organise them by brand, market or business unit. Where the median stay is a small number of years, that answers a question nobody is stuck on: everyone knows which product is which. What nobody can answer is who is on the hook for the conference microsite now that the person who built it has moved to Berlin.
The concrete version is verification. Search Console properties are verified by a person, under whatever Google identity was signed in at the time, frequently a personal one. Verification persists after that person leaves; account access does not, once IT disables it. A year on, the company owns the domain, pays the hosting, ranks for the term — and cannot read a row of its own search data without starting over.
So the sorting question is not "which brand is this" but: if the person closest to this address gave notice tomorrow, what still works in three months? Access, if it does not depend on their account. Reporting, if it lives in a shared workspace rather than their bookmarks. History, if a successor can search it. The rest degrades until someone notices a form has been broken for a year.
The four constructs that survive a departure
The reason to run the estate from one shared workspace rather than nine browser tabs is not convenience. Four of its constructs are defined at company level rather than individual level, and those four are what a departure normally destroys.
One project per address
Each hostname gets its own keyword set, campaign state and history, held apart from the rest.
- Acquired product stays intact
- No merging of unlike query sets
- Reporting scoped to one estate item
Team seats inside the workspace
Colleagues work in the environment rather than receiving screenshots from whoever holds the login.
- Two readers per property minimum
- Handover means adding a seat
- No shared password anywhere
Per-site sharing to an address
A single site is shared with a named e-mail instead of handing over the account, and the grant can be withdrawn.
- Contractor sees one property
- Withdrawn without touching Google
- Survives an agency change
Linked Google account groups
Several account groups attach at once, so properties verified under different identities read side by side.
- Legacy verifications still readable
- One authorisation, not nine
- Search Console and Analytics together
Tag by who is answerable, not by what it is called
Site tags act as a filter applying across every view at once, which makes the vocabulary consequential. The instinct is to tag by brand or product; in an estate assembled from company events that yields one tag holding everything and five holding one item each, and no view becomes more readable.
A vocabulary that describes the state of custodianship earns its keep instead, because it changes when circumstances do rather than staying fixed for the life of the domain.
| Tag | What it asserts | Review rhythm | What a change in state looks like |
|---|---|---|---|
| staffed | A named person has this in their objectives | Weekly | That person leaves; retag the same day |
| inherited | Came with an acquisition, never integrated | Monthly | Integration decided, or explicitly deferred again |
| community | Traffic driven by contributors, not campaigns | Monthly | The library is deprecated upstream |
| dormant | Serving, ranking, nobody editing it | Quarterly | A form breaks, or a fact on it becomes false |
| legacy-redirect | Former brand, expected to forward everywhere | Quarterly | A path is found that still serves old content |
| event-archive | Finite purpose, concluded, kept deliberately | Twice a year | The decision to keep it is not renewed |
Two benefits follow. Aggregates stop mixing unrelated populations — a community domain and a product site have query profiles so different that averaging them describes neither. And the tag list becomes the review agenda: anything in dormant or event-archive across two consecutive reviews is a decision waiting to be made.
What a single number across nine domains is made of
The rank-tracking section produces a score per site alongside average position and tracked keyword count, then a global ranking across the whole portfolio with a twenty-eight-day trend curve. Anyone who reads aggregated telemetry for a living will ask what that roll-up is doing before letting it near a board slide.
The honest description is structural rather than formulaic. A per-site score summarises positions across that site's tracked keywords; the portfolio figure summarises the sites. Its movement therefore has three possible sources, indistinguishable from the number alone.
- Positions moved. The only source that reflects work. Confirm it in the per-site views before claiming it.
- The tracked keyword set moved. Terms added or dropped change a property's score with nothing changing in the results themselves.
- Portfolio membership moved. Attaching the conference microsite moves the global figure on the day you attach it. Nothing ranked differently; the population is simply larger.
The third source catches estates like these, because membership genuinely does change. A portfolio metric over a stable set is a measurement; over a set that gains an inherited domain every few months it is an index whose basket keeps being rebalanced, and it needs the disclosure an index carries.
The competitor view has the same shape: domains sharing your keyword space, with an authority figure and an overlap count. Where an open-source domain ranks for a technical term, the names returned are mostly package registries and technical publications — an accurate statement about who occupies that half of the results. The generative market research views extend the idea a layer up.
Who gets the indexing budget when two teams submit on the same day
Submission capacity is an account-level resource, not a per-property one. That single design fact causes most of the operational friction in a multi-site workspace, and it is worth stating before anyone builds a habit around it.
The submission pipeline and its published ceilings
For estates whose properties ship on separate release cadences.
- A daily ceiling owned by the account. One thousand addresses a day, from a single pool whichever project submits them.
- Batch size is a separate limit. Ten thousand go into one batch; accepting them is not processing them that day.
- Sitemaps by upload or address. Parsed recursively to three levels, up to a thousand sitemaps in one job.
- Job concurrency is bounded. Two sitemap jobs run at once and twenty may wait in line — the real constraint when several teams start at nine.
- A per-address record. Bot visit with timestamp, status and error detail, beside live counters for submitted, discovered and failed.
Hence the question a technical reader asks first: when one team pushes a thousand changed pages on the morning another relaunches a section, how is the pool divided? By arrival, not importance. Nothing in the pipeline knows the community domain earns qualified attention while the conference microsite was finished two years ago.
That is a boundary rather than a deficiency, and it tells you where the policy has to live. Allocation is yours to decide and write down; the simplest workable form is a standing rota with an exception path.
| Slot | Default claim | Typical use | Who can override |
|---|---|---|---|
| Monday | Product site | Weekend releases, changed landing pages | Nobody; fixed slot |
| Tuesday | Developer portal | Reference pages regenerated by a build | Product, for a launch week |
| Wednesday | Community domain | New contributor pages, version docs | Maintainer on request |
| Thursday | Inherited product | Whatever the acquired team shipped | Their lead |
| Friday | Held in reserve | Incidents, restored pages, migrations | Anyone, first come |
| Any day | Dormant properties | Nothing routine; only after a change | Needs a written reason |
Per-project reporting exists because the audiences do not overlap
One consolidated monthly report satisfies nobody. The maintainer of the community domain does not care about the inherited product's conversion pages; the person who inherited that product cares about nothing else; whoever presents to the board wants one page, not forty. Per-project reporting lets those three documents come from one dataset without three spreadsheets behind them.
What comes out, and in which shape
For teams that need one artefact for a meeting and another for a query.
- Machine-readable exports. CSV and JSON carry up to ten thousand rows — the format to take when someone will join this against internal data.
- Rendered documents. PDF is produced server-side and holds up to two hundred and fifty rows — a meeting artefact, deliberately not a data dump.
- A configurable builder with your branding. Logo and colours applied, so a report forwarded outside needs no reformatting.
- Visualisation that suits the question. Time series, metric cards, sortable tables paging at fifty to two hundred rows, sparklines, and country and device heatmaps.
Background workers keep the data current, so a dashboard opened cold reflects recent state without a manual refresh. That matters most for the occasional visitor: the successor opening an inherited property, who cannot tell a fresh view from a stale one.
Making the workspace outlive the individual
Everything above converges on one requirement: when a person goes, the estate loses their judgement and nothing else. Not the access grants, not the reasoning behind last spring's decisions, not the ability to read a property's data. The project feed addresses the second, and it is the least obvious of the three.
Stream — a searchable record, not a chat box
For estates where the person who made a decision will not be there to explain it.
- One chronological column per project. Model answers, generated reports, new links with donor authority and traffic, to-dos and campaign news in one ordered feed.
- Answers bound to real project data. A router model decides per question which blocks to load — Search Console, rank data, campaign or custom — taking none, one, two or three by relevance.
- Streaming output with retained context. Replies arrive token by token and twenty messages are kept, so a line of enquiry survives an interruption.
- Filters and states that map to work. All, links, files or to-dos; items sit in active, deferred or discarded, which is enough to answer "what did we decide not to do".
- Full-text search across every message. What makes it a handover artefact — a successor searches it instead of interviewing people who have left.
Before the last day
Find every property where the leaver is the only verified owner or the only workspace seat.
- Add the second owner first
- Re-verify under a company identity
- Note the method used
Write the state down
What is in flight, what was deliberately abandoned, when the next review falls.
- Deferred to-dos, with reasons
- Open decisions, with dates
- Anything running on a personal key
Withdraw and re-issue
Remove the individual grants, then re-issue only what the successor needs.
- Grants, not passwords
- Verify the removal worked
- Retag the property's state
The review that catches drift
Walk the tag list and put the sorting question to every address again.
- Any property with one owner
- Any tag unchanged for two reviews
- Any form pointing at a dead service
Campaign automation sits on top of this and is priced per domain, which forces the decision this article has been circling: which addresses deserve active work and which deserve custody alone. The automated tier finds and prioritises keywords, builds links against a partner network of more than 230,000 sites and proposes on-page changes; the higher tier adds keyword approval with automatic fallback, directed placement against an authority target, a review gate before wording reaches a page, and specialists, developers and writers behind it. First movement generally appears between the fourth and eighth week. The upper tier covers the rest, and our notes on the measurement stack cover how it meets the analysis views.
Frequently asked questions
Should the acquired product's site be a separate project or merged into the main one?
Separate, almost always: its keyword set, audience and release cadence differ, and merging produces averages describing neither. Merge only when one domain is genuinely being retired into the other.
Our open-source domain gets more traffic than the product site. Does it belong in the portfolio figure?
Yes, tagged distinctly and read separately too. Its volume dominates any aggregate it joins, which is fine provided readers know that. Keep the per-site view primary and the portfolio figure as context.
Two teams submitted large batches this morning and one says nothing happened. Which is right?
Both, probably. Acceptance into a batch and departure from the daily pool are different events, and the pool is account-wide. Check the per-address log for timestamped bot visits rather than the submission receipt, then agree an order.
The colleague who verified half our properties left a year ago. What can be recovered?
The data, in full. History belongs to the property rather than the verifying account, so re-verifying under an identity the company controls restores the record. Do it for every hostname, add a second owner, and note the method used.
How many domains is too many for one workspace?
The count is rarely the constraint. The number of addresses with nobody named against them is, and the ceiling is however many your review routine walks on schedule. Nine tagged domains with owners beat four without.
An estate grown by acquisition, spin-out and rebrand cannot be organised around brand hierarchy, because hierarchy is not what created it. It can be organised around custodianship, because custodianship is what keeps failing — and the constructs holding it are projects, seats, withdrawable grants, account groups, state tags and a searchable record of decisions.
The first move is small: list every hostname the company answers on, name a person against each, and mark the ones with exactly one. That list is uncomfortable, and it is the most valuable artefact the exercise produces. From there you can set up the workspace and attach the first property through one Google consent flow, adding the rest as the map fills in. Platform changes appear in the product site, and more of our English writing sits in the blog archive.
