A Prague firm of two hundred people can easily own six domains, no two of them trying to reach the same person. One is read by a German purchasing office, one by a developer in Brno deciding where to send a CV, one carries a partner's brand and must never mention you at all. Holding that estate in a single workspace is less an analytics problem than a question of who each address is for.
Estates like this are not planned, they accumulate. The engineering arm needed its own address because its buyers would never have found it inside the group site. Recruitment needed one because a careers page three clicks deep in an English site does not attract Czech developers. The fair pages were built by two salespeople in a fortnight; the partner-branded property arrived with a contract. Each decision was right on the day it was taken.
Six domains, no two of them selling the same thing
Take a company writing software under contract for customers in Germany and the Nordics, with a smaller engineering-services unit doing test and validation work for manufacturers, hiring twenty-odd people a year in Prague. One profit and loss account, at least five separate reading audiences.
The useful first exercise is not technical. Write down each property and finish the sentence "this exists to be found by ___". The untidiness of the result is the finding: two properties will turn out to serve the same reader badly, and one will turn out to have no reader at all.
| Property | Exists to be found by | Working language | A good month looks like |
|---|---|---|---|
| Group site | A buyer who already has your name and is checking you are real | English | The certification page read before a call, not after |
| Engineering-services site | A purchasing office that has never heard of the software business | English | Enquiries arriving with a drawing attached |
| Recruitment site | Developers and test engineers within an hour of the office | Czech | Applications that match the vacancy, not volume |
| Trade-fair landing pages | Visitors who saw a stand number and typed it half-remembered | English, sometimes German | Six concentrated weeks, then honest silence |
| Partner-branded property | The client of a company reselling your work under its name | The partner's | Enquiries you may never be shown |
Nothing in that table averages. A month in which applications double and export enquiries halve is not a neutral month, and no combined figure describes it. The case for one workspace is not a single number; it is to stop five sets of numbers living in five formats.
What a workspace is made of
The unit inside a single Semalt workspace is the project. One property, one project: its own campaign settings, keyword pool, Search Console and rank-tracking figures, reporting. The account above holds the projects together, the people who may look at them, and one or two resources that turn out to be genuinely shared.
One property, one project
For an estate where the properties have nothing in common except an owner.
- Keyword work stays inside its own project. Terms a purchasing office types and terms a job seeker types never meet — which is the point when one set is Czech and the other English.
- Analytics are read per property. Eight connected Search Console views and six rank-tracking views, each addressable for one site rather than for the estate.
- Reporting is configured per project. The recruitment report and the export report are different documents, and neither has to be extracted from the other.
- Subscriptions are counted per domain. Automation is bought for the properties that need it; a dormant fair page can sit in the account without one.
Seats matter more here than in an agency, because the readers are colleagues with different jobs rather than clients with one interest each. The recruitment lead has no use for the German phrases the engineering site is winning; the export manager has none for how many people read a salary range.
Give each person the properties they are answerable for and nothing else — a shorter list than most first propose, and easier to set at the start than after a year of "just add me to everything".
The filter that has to mean something
Past four properties you need a way to address a subset without naming each one. Tags do that: applied to sites they act as a filter carried across every dashboard view rather than as labels in a list, so the choice of axis decides which questions the account answers in one click.
The instinct is to tag by whoever pays, since that mirrors the internal structure. It is the wrong axis here: the internal structure is exactly what no reader outside the building can see. Tag by audience, and add one axis for the awkward properties.
By audience
The primary axis: who the property was built to be found by. Four or five values cover an estate of this size.
- Foreign buyer, domestic candidate, partner's client
- Values that survive a reorganisation
By whose name is on it
Your brand, a partner's brand, or unbranded event pages. This axis governs what may appear in a report.
- Separates properties with sharing restrictions
- Prevents a white-label site landing in a group deck
By expected lifespan
Permanent, campaign-length, or dormant between events. A fair page should never be judged by the standards of the group site.
- Keeps expired pages out of the weekly review
- Flags what needs indexing attention and when
By what counts as a result
Enquiry, application, or meeting booked. Stops two properties being compared on a metric only one was built for.
- Matches the report to the reader
- Makes a bad month legible rather than alarming
Combining axes is where the value sits. Audience plus lifespan answers "what is live for foreign buyers right now"; brand plus result answers "which properties earn applications under our own name". Neither breaks when the engineering unit moves under a different director.
The recruitment site and the sales site share nothing
Why audience is the right axis shows up inside every Prague software house that hires locally and sells abroad. Two properties, one company registration number, no common ground in the data at all.
The recruitment site competes in Czech against every other employer within commuting distance, for a reader comparing three job posts and a salary figure; its season follows graduations. The sales site competes in English against suppliers in Poland, Portugal and Vietnam, for a reader working through a requirement document; its season follows budget cycles in other countries entirely.
- The competitor lists do not overlap. On one property the contested domains are job boards and other employers here; on the other they are suppliers in cheaper countries and the aggregators that list them. A single competitor view would be nonsense.
- The volumes are incomparable. A Czech job phrase can outrun a specialist English capability phrase tenfold while being worth a fraction as much per search.
- The people who act differ. One report goes to somebody scheduling interviews, the other to somebody deciding which capability to describe next. Neither wants the other's appendix.
Keeping both in one account is still right. They compete for the same budget, the same developer hours, and — as the next section shows — the same daily indexing allowance. What they must not share is a scorecard.
Reporting on a site that does not name you
Prague runs on subcontracting and the estate shows it. Somewhere in a portfolio like this is a property built so a partner's customer can find something — a product page, a documentation set, a landing page for a service the partner sells and you build. Your name is not on it, and under some contracts may not be.
The arrangement itself is simple. The site is verified in the partner's Google account, and either that account is linked into a group with yours or the partner shares the single site to a named address on your side. Either way you see the figures without holding their credentials, and without your own estate becoming visible to them.
Sharing one site to one address
For properties where the relationship between the parties is itself confidential.
- The share is per site, to a registered address. The recipient sees that property. Neighbouring properties and the tag structure stay out of view.
- It can be withdrawn. The feature discussed least and needed most: access granted for a six-month engagement outlives it unless somebody removes it.
- Withdrawal belongs in the contract calendar. Tie the review to the renewal date, and check it when a named contact leaves either company.
The awkward part is not access but reporting. A quarterly deck for your own board that includes the partner-branded property tells everyone in the room who the partner's client is, which is the thing the arrangement was built to obscure.
Who may see the method
A share exposes the phrases being worked and the placements built, not just a traffic curve.
- Name the recipient, not the company
- Write down what may be forwarded on
What happens at the end
When the subcontract ends the property stays with the partner, and the access has to go somewhere.
- Withdrawal date tied to the contract
- Agree who keeps the historical export
The indexing budget is shared, and nobody expects it to be
Most things in the workspace are per project. The daily indexing allowance is not: the Indexing Hub works to a thousand URLs a day per account, submitted through IndexNow, with bulk batches of up to ten thousand, sitemap parsing three levels deep, two jobs running at once and no more than twenty waiting.
For a single site that ration is generous to the point of being invisible. Across an estate it has to be allocated, and the first time anyone notices is the week before a fair, when a salesperson wants forty new pages found at once and somebody else has already queued a catalogue refresh.
| Property | What it submits | Rhythm | Claim on the daily allowance |
|---|---|---|---|
| Group site | A handful of pages a quarter | Rare, predictable | Negligible, and never urgent |
| Engineering-services site | Capability and accreditation pages | Monthly | Small, but urgent after an audit |
| Recruitment site | Every vacancy, every closure | Weekly, sometimes daily | Steady and worth protecting |
| Trade-fair pages | A whole small site at once | Two or three bursts a year | Large, short, known months ahead |
| Partner-branded property | Whatever the partner publishes | Outside your control | Unpredictable; agree a window |
Written out, the conflict resolves itself: the bursts are the only real claimants, and both are known months ahead. What causes trouble is not the size of the ration but meeting it for the first time on a Tuesday afternoon.
Pulling scattered verification into one view
Estates like this are almost never verified in one Google account. The group site sits with whoever built it, the recruitment site with an HR manager's own login, the fair pages with an agency since replaced, the white-label property with the partner. Linked account groups exist for exactly this: several accounts joined so their properties appear in one workspace, verification staying where it is.
Linked Google account groups
For estates whose verification history is a record of past staff and suppliers.
- Nothing is transferred. Properties keep their existing verification, which matters when the account holder is a partner rather than a colleague.
- One consent covers the connected services. Search Console, Analytics and the mail address are authorised in one pass, not service by service.
- Gaps become visible. Properties no current employee can reach show up as absences — worth resolving while the person who set them up is still reachable.
- Background synchronisation keeps it current. Figures update without anyone refreshing a view — the difference between a review and a reconstruction.
What comes out matters as much as what goes in. A configurable report builder sets which blocks a document contains and carries your own logo and colours; exports run to 10,000 rows in CSV or JSON and a server-rendered PDF holds 250. The ceiling is useful: choosing which 250 rows describe a quarter is the judgement, not the export.
| Report | Reader | Cadence | What must not be in it |
|---|---|---|---|
| Export performance | Commercial management | Quarterly | Recruitment figures, which distort the averages |
| Recruitment visibility | The hiring lead | Monthly | Anything in English about foreign buyers |
| Fair campaign wrap-up | Whoever paid for the stand | Once, three weeks after | Comparison with permanent properties |
| Partner property | The partner, nobody internally | As the contract says | Any trace of your other clients |
| Estate overview | The board | Twice a year | A single blended score across the five |
Common questions
Our Czech and English sites are one domain with two directories. Is that one project or two?
One property, because verification and the subscription follow the domain, not the language. Separate the two sides with filters on the pages views. Wanting them reported wholly apart is an argument for two domains — a commercial decision, weighed against a second subscription.
Can a partner see that we manage other websites?
Not through a share. Sharing is granted one site at a time and the recipient sees that property alone — not the account list, not the tags, not the neighbouring projects. The exposure risk is a report you assemble yourself that puts several properties on one page.
We build a small site for each trade fair. Should those go in the account at all?
Yes, tagged by lifespan so they leave the routine when the event does. The reason to register them is the indexing burst: forty pages needed within days is a load you want scheduled rather than discovered. Afterwards decide deliberately whether each is retired or folded into a permanent page.
Who should hold the account when several departments are involved?
Whoever will still be answerable in two years, rarely the person who set it up. Keep ownership with a role rather than an individual, give departments seats on the projects they answer for, and review granted shares on a fixed date each quarter.
Does every property need a paid subscription?
No. Automation is priced per domain, so it is bought for the properties where campaign work actually runs — usually the two that generate enquiries. Dormant and event-length properties sit in the account for the analytics and the indexing queue. The levels and add-on slots are costed in the English articles section.
Where to start, and in what order
The common mistake is designing the whole structure before adding the second site. Do it the other way round: register two properties that genuinely differ — the export site and the recruitment site — and work only in the dashboard for a month. The axes you need surface in about three weeks, and are never the ones drawn on a whiteboard beforehand.
- List the properties and their audiences. One line each, finishing the sentence about who the address exists to be found by. A property you cannot finish it for is the real finding.
- Register two, not six. Pick the pair with the least in common. A structure proved on the hardest pair will hold for the easy ones.
- Link the accounts you can reach. Note the ones you cannot and start those conversations early — a former agency's login is a slow problem.
- Put the indexing bursts in the calendar. Fair and audit dates, marked as claims on the daily allowance rather than as marketing events.
To try this on a real estate rather than on paper, open the dashboard and add the first two properties, tag them by audience, and see whether a month later you can answer one question in under two minutes: which of our websites had a good month, and good by whose definition.