The product site, the documentation domain, a status page, a blog that ended up on its own subdomain, the marketing site from the company you acquired, and a landing page built for a conference in 2022. Six properties. Nobody can say which of them produced an enquiry last quarter, and two of them are competing with each other for your own brand name.
Technology companies accumulate domains faster than almost any other kind of business, and for reasons that are individually sound. Documentation gets its own domain for deployment independence. Status goes on a separate host so it stays up when the product does not. An acquisition arrives with its own presence. Each decision was correct in isolation; the aggregate is a set of properties nobody has ever looked at together.
The question that has never been asked is not how each performs. It is whether any two of them are taking positions from each other — and that cannot be answered one report at a time.
What six separate views cost per month
While every property sits in its own account, an overhead accrues that no invoice records: assembling the picture. Six logins, six exports, a worksheet where somebody matches up column headings by hand, and a total whose derivation nobody else can reproduce.
In a company where marketing is one or two people, half a day a month spent on reconciliation is a meaningful proportion of the available capacity — and it produces no output, only data in a comparable shape. Worse, the resulting figure is hand-made, which means it cannot be checked and therefore cannot safely be put in front of an investor.
The second effect does more damage and is invisible in separate reports. Where two of your own properties contest the same terms, attention divides between them. Each individual report reads acceptably. Only side by side does it become apparent that one is suppressing the other — and in a technology company the pair is frequently the documentation domain and the product site, both answering the same question in slightly different words.
Consolidating the view without consolidating the properties
What the Semalt workspace does is keep multiple domains, multiple Google logins and multiple people in one place, with filtering that spans the lot — and it leaves each property exactly as separate as it was.
Three mechanisms, three separate purposes
None of them merges anything. All three make a scattered estate legible.
- Joining the Google accounts. Once the logins are connected, the search properties no longer sit in isolated boxes. In most companies this is the moment somebody sees the full set on one screen for the first time.
- Granting a single property to an outside address. The agency handling the acquired brand receives that property and nothing else. This matters less for secrecy than for the fact that access can be withdrawn precisely when a contract ends.
- Labels that hold across the whole interface. Marking a property as product, documentation, acquired or retired takes effect everywhere at once. Reporting divides along those lines while the data behind it stays whole.
Day to day, the labelling does the heavy lifting. A single dataset can be presented several ways without anyone maintaining several reports — everything for an investor summary, one label for the product review, another for whoever still owns the acquired brand. Same underlying numbers, three framings, and no manual step joining them up.
Five patterns from the first joint review
Docs domain against product site
Both answer the same question. Search engines choose, and documentation frequently wins because it is updated more often.
- Visible immediately in the ranking view
- Decision: one explains, one converts
The brand still on its old domain
Untouched since the deal, still holding references and still ranking for terms you now want elsewhere.
- Count references before deciding
- Redirect beats leaving it running
The conference microsite
Built for one event, never retired, occasionally ranking above the page it was meant to support.
- Zero maintenance, non-zero effect
- Redirect and be done with it
Six properties, six configurations
Different frameworks, different address conventions, different analytics setups — assembled over five years.
- Align before comparing anything
- Otherwise a quarter goes on artefacts
A fifth pattern is specific to companies with a documentation domain and causes the most confusion when it surfaces: the status page outranking everything for your brand name during an incident. That is arguably correct behaviour and it means that on the day you least want it, the first result for your company describes a degradation. Nothing about this is fixable by configuration — it is a consequence of the status page being the most linked-to property you own during an outage — but knowing it happens changes what you put on that page.
The consolidated ranking table
One table covers every domain under observation. Against each property sits a consolidated score, the average position it holds, its term count and a line showing how the past four weeks went. Described that way it sounds like more numbers; used in practice it is where the argument about what to work on next gets resolved.
| View | Question it settles | Consequence |
|---|---|---|
| Score per property | Which of the six stands best overall? | Effort follows the leverage, not the org chart |
| Term count per property | How broadly is each positioned? | Breadth against depth, per property |
| Each property's leading page | Which single page is carrying the outcome? | Secure it first, before commissioning anything further |
| The other domains on these terms | Who is competing with us for this vocabulary? | Some of the answers turn out to be yours |
| Movement over four weeks | Where is the estate heading? | Response within weeks, not at year end |
The fourth row is where the uncomfortable finding lives. Every domain contesting the same terms appears, yours included. In a technology company this is usually the first hard evidence that the documentation domain has quietly become the primary property — which may be fine, may be exactly wrong, and is in either case a decision somebody should now make deliberately rather than continue to inherit.
Who holds which key
Estates of this shape almost always involve outside parties: an agency on the acquired brand, a contractor on the blog, a technical writer on documentation. The default arrangement is a shared account whose credentials circulate, and it works until somebody's engagement ends.
- External agency. Holds the one property it works on, under its own address. Ending the engagement removes that grant alone; nobody rotates a credential that five other properties depend on.
- Technical writer or contractor. Sees the documentation property and its reporting. Understanding whether a reference page is retained does not require access to the commercial site.
- Founders and investors. Need the consolidated view and nothing beneath it. A PDF of up to 250 rows, in the company's own mark, covers that entirely.
- Whoever runs the next diligence process. Needs periods that can be compared and figures whose derivation is traceable. A scheduled quarterly export serves that far better than a live account nobody opens.
Where that record needs to hold up under external scrutiny, the campaign side of My SEO is the half that matters, because it shows how placements were acquired rather than only what resulted. The last item is worth planning for before it becomes urgent. During a funding or acquisition process, somebody will ask how the traffic was acquired and how the links were built. An answer assembled from six exports the week it is asked looks assembled. An answer produced from one workspace with a dated record behind it does not — and the difference is noticed.
Reports that reach their audience
Report layouts are configurable and can carry the company's own mark and palette. More consequential than appearance are the row limits on each output path, since those dictate what can travel by which route.
Which settles the allocation. Whatever a person will actually read belongs in the printable document, under the 250-row ceiling. Whatever will be fed into something else belongs in the machine-readable file, where there is room for ten thousand rows. The available components are identical on both routes — change over time, headline numbers, tables that sort, condensed trend lines, splits by country and by device. All that differs is the destination.
One login shared by four people and two agencies
Credentials handed on at each change. No way to establish who altered what, or when.
- Every departure forces a rotation
- Contractors hold the same keys as staff
One identity per participant
Each person or agency operates under their own login and sees only the properties assigned to them.
- Assignments revoked individually
- Changes remain attributable later
One detail that saves recurring trouble: one authorisation step is enough for all three Google connections rather than three separate ones. What used to be three configuration exercises becomes a single action, and the most common way a property quietly loses a data feed — an authorisation that expired months ago while the other two continued working — disappears along with them.
What survives the next reorganisation
What each project keeps is a chronological log. Onto it go the assistant's answers, reports produced automatically, freshly created placements together with the score and traffic of whatever site carries them, work items both outstanding and finished, plus notices from the campaign itself. The log can be filtered four ways, and every work item sits in one of three conditions: running, postponed or dropped.
One property you remember; six you do not
In a company where marketing ownership turns over every eighteen months, undocumented reasoning has a short half-life.
- Replies built on this project's figures. A routing step runs first and works out which material bears on the question — search reporting, ranking figures, the campaign's current state, or data you added yourself — then retrieves anywhere between nothing and three of them.
- Output as it is written, twenty messages retained. Enough to carry a line of enquiry across several questions, deliberately short of becoming an archive.
- Placements listed with their own numbers. Alongside every placement stand two figures: how authoritative the hosting domain is and how much traffic it receives — so nobody has to look each one up by hand.
- Searching the whole record as text. Ignored entirely at the outset and indispensable a year and a half later, when whoever took the job over has to reconstruct what was concluded about the acquired domain and on what basis.
Of those three conditions, "postponed" is what keeps the log from becoming unreadable — and it is the reason the record in My SEO remains something people open rather than a backlog they avoid. A great deal of work across an estate is not wrong, only not now — restructuring the acquired brand while the product team ships a release, for instance. Deferred items remain findable without occupying the active list. The alternatives both fail: leave everything open and within a year nobody opens the list; cancel instead and the reasoning leaves with the entry.
Bringing an accumulated estate under control
| Step | Action | Result |
|---|---|---|
| 1 | Write down every domain the company owns, including renewals nobody recognises | a verified list rather than an assumed one |
| 2 | Join the separate Google logins into one group | every property on a single screen |
| 3 | Apply labels that mirror the business, not the tech stack | one filter working across the whole interface |
| 4 | Read the ordered table and the column of shared terms | every point at which two properties of yours overlap |
| 5 | Fix one standing report per audience | an end to the monthly circular |
| 6 | Record the decisions in the project timeline | reasoning that survives a change of owner |
Step one is less trivial than it looks. In most companies of this size at least one live domain turns up that no current employee can account for — usually a defensive registration that somebody built a page on. Step four is where the actual work is, because deciding that documentation explains and the product site converts requires agreement between two teams that have never had to agree about it. Which property should own which term is settled during keyword research, the editorial division in our content strategy, and the technical alignment that has to precede any comparison under technical SEO.
The estate listing, consolidated ranking, tagging and report definitions can be applied to your own domains in the Semalt dashboard rather than rebuilt in a spreadsheet each month, with synchronisation running in the background.
Open the estate listing in the dashboard
Questions from marketing and platform teams
Should documentation move onto the main domain?
Where it is possible, usually yes, because a folder inherits considerably more than a subdomain does. Where it is not — and deployment independence is a legitimate reason it often is not — heavy cross-linking in both directions narrows the gap without closing it. What matters more than the answer is making the choice deliberately and then deciding which of the two properties owns which terms, rather than letting them contest each other by default.
What should happen to the domain from an acquisition?
Measure before deciding. Find out two things: what visitor numbers it still attracts, and whether anything out there still links to it. Should either turn out to be non-trivial, a page-by-page redirect preserves more than switching it off. If neither does, it is costing a renewal fee and some attention. Either way, record the decision — within a year nobody remembers why the redirect exists and somebody removes it while tidying up.
Can an agency see only the property it works on?
It can. One property gets assigned to the agency's own login; everything else in the estate simply does not appear for them. The less obvious gain is that the shared password stops circulating altogether, and when the engagement finishes you revoke one assignment rather than rotating a credential that five other properties are also using.
How many tags does an estate this size need?
Three to five, drawn along whatever line the business is actually run by. Product, documentation, acquired and retired covers most companies at this stage. Going beyond a dozen recreates the confusion the tags were introduced to remove, and it tends to happen when each property is tagged by whoever set it up rather than once, centrally, by somebody looking at the whole list.
Does every property need its own campaign?
Purchase happens at domain level while the reporting remains common to all of them. Practically, that allows one property to receive active work and the rest to be watched, with nothing lost from the combined picture. Given that a single property carrying the bulk of the result is the usual situation rather than the exception, this asymmetric arrangement is generally the cheaper one — and it stays invisible until somebody looks at everything together.
What is the most common mistake when consolidating?
Pulling a property down before establishing what links to it. A domain can see no visitors at all and still hold references that disappear the moment it goes. Sequence prevents this: catalogue, measure, decide, redirect — and only then retire, which frequently turns out to be unnecessary. The runner-up mistake is completing the technical tidy-up while skipping the editorial agreement, which yields a neatly organised view of precisely the same overlap you started with.