Six properties, one owner, and the one that earns most of the money ranks for almost nothing. This article is about running an estate shaped like that from a single workspace, and about why the figure at the top of a portfolio dashboard is the least useful number on the screen.
Most advice about managing several websites assumes the sites are versions of one another: branches of a chain, translations of one shop. When properties really are comparable, stacking them into one view is the point, and the ranking that sorts them tells you where to spend Monday.
The estate belonging to a Helsinki machine builder is not that. Its properties were built at different times, for different readers, by different parts of the company, and they are worth wildly different amounts. Comparing them produces a specific and expensive error: attention goes where the impressions are rather than where the margin is.
Six properties with nothing in common but an owner
The example running through this article is constructed, but the shape is ordinary in Finnish engineering. A group in Helsinki builds machinery for sawmills and paper mills. Two of its product lines were separate companies once, each with an installed base still running in the field, and each kept its site because customers knew the name on the machine rather than the one on the invoice.
| Property | What it is for | Rough size | Language |
|---|---|---|---|
| Group site | Corporate face: press, references, investor material | 90 pages | English |
| Line one site | Debarking and chipping lines for sawmills | 120 pages | English |
| Line two site | Winders and roll handling for paper mills | 80 pages | English |
| Parts and documentation portal | Logged-in access to drawings, manuals and part numbers | 4,200 URLs, 160 public | English |
| Export-market site | The largest single export market, in its own language | 45 pages | German |
| Recruitment presence | Hiring fitters and automation engineers locally | 14 pages | Finnish |
Read the language column first. Five properties work in a language nobody in the building speaks at home, and the sixth — the one that must reach a service fitter living in Vantaa — is the only Finnish one. That inversion defeats every reporting template built for a domestic business.
That last tile is not a joke. The audience is a marketing coordinator and a sales director, and neither has time to open six panels and reconcile them by hand.
The site that earns nothing and the site that earns everything
Set the group site beside the parts portal and the asymmetry is immediate. The group site collects the impressions, because company names, references and press releases are what people search for by name. It closes almost no business.
The portal is its opposite. It sits mostly behind a login, surfaces in search for almost nothing, and carries the spare-parts and service revenue arriving every year from machines commissioned two decades ago — the steadiest money in the business.
| Property | Share of impressions | Share of recurring margin | What a moving number means |
|---|---|---|---|
| Group site | Roughly two thirds | Near zero | Name recognition, rarely revenue |
| Two product-line sites | Roughly a quarter | Lumpy, project by project | One enquiry can be a year's result |
| Parts portal | Under one per cent | The clear majority | Retention, counted in logins |
| Export-market site | A few per cent | Growing, deliberately | The only growth target on the estate |
| Recruitment presence | Small and seasonal | None, correctly | Applications, in one city |
The figures are illustrative; the ordering is not unusual, and the ordering does the damage. Any view sorting properties by impressions puts the least commercially important first and the most important last. Follow that sort order for a year and your attention has followed it too.
What a project is, and where you draw its edges
A project is one property with its own instruments attached: its own Search Console history, tracked positions, campaign if it has one, submission log and feed. Everything downstream inherits that boundary, which makes it the decision worth getting right first.
A project holds one property and its full instrument set
For estates whose properties are genuinely different businesses wearing one logo.
- Analytics follow the property. Eight Search Console views and six result-page views per connected site, so the portal is never averaged into the group site by accident.
- Campaigns attach to a domain. Subscriptions are priced per domain per month, so the estate decides property by property whether one is worth running.
- The record is per project too. Logged placements, to-dos and answers belong to the site they concern, not to a company-wide inbox.
- Connection costs nothing. Verified properties can be linked and read without a campaign, which is how the portal and the recruitment pages earn their place.
Two boundary questions recur. The first is whether to split a large property into several projects — the portal by machine generation, say. The answer is no: Search Console verifies and reports at property level, so a split creates two projects reading the same data and disagreeing about it.
The second is whether to merge the product-line sites now that the companies behind them have. That is a business question in technical clothing. While each line keeps its own installed base, its own service engineers and its own name on machines in the field, the sites are separate audiences.
Site tags, and why you tag by role rather than by product
Projects give separation. Tags give the grouping back without collapsing anything: a site tag is a global filter, so applying one narrows every view to the properties carrying it.
The instinct is to tag by product line, because that is how the company is organised. Resist it — the line is already in the project name. Tag instead by what nothing else expresses: what each property is for.
Earns money directly
Where a search result plausibly sits on a path ending in an invoice.
- Both product-line sites
- The export-market site
Keeps existing owners supplied
Serving people who bought a machine and will need parts for twenty years.
- The parts and documentation portal
- Judged on access, not acquisition
Answers for the company name
Must be correct and current when somebody checks who you are before a tender.
- The group site
- Measured on presence, not growth
Competes in a labour market
The one property whose rivals are Finnish employers, not machine builders.
- The Finnish recruitment presence
- Seasonal by nature
Tagged this way, the filter earns its keep the first time somebody asks what search did for the business last quarter. Narrow to the revenue tag and the answer is short and defensible. Unfiltered, two thirds of the impressions in it come from a property never meant to sell anything.
The daily submission budget belongs to the account, not to the site
Here the estate stops being six independent things. The URL tracker allows 1,000 URLs a day per account, shared across every connected property. Bulk intake takes 10,000 URLs in one batch, released against that budget; sitemap jobs run two at a time with twenty waiting, follow index files three levels deep and accept 1,000 sitemap files per job.
For five of the six properties this is a formality: their combined public page count is under 350, so all of them could be resubmitted every morning on a third of a day's allowance. The portal is the exception.
| Property | Public URLs | What to submit | When |
|---|---|---|---|
| Group site | 90 | New references and press pages | On publication |
| Line one site | 120 | New machine and application pages | On publication |
| Line two site | 80 | New machine and application pages | On publication |
| Parts portal | 160 of 4,200 | The public catalogue layer only | When the catalogue changes |
| Export-market site | 45 | Everything, while the tree is young | On publication |
| Recruitment presence | 14 | Open vacancies | As roles open and close |
The per-URL log makes a shared budget manageable rather than mysterious. Each address carries a record — bot visit with timestamp, status returned, error detail — while live counters separate submitted, discovered and failed as a job runs. On an estate you read it to answer one question: which property consumed the allowance, and did it get anything for it.
Linked Google accounts, shared sites, and sharing you can withdraw
Estates like this are rarely run by one person. Communications owns the group site. A distributor's agency in Hamburg maintains the German one. HR updates the recruitment pages in Finnish. Sales answers for the product-line sites, service for the portal.
Two mechanisms handle that, and they are easy to confuse. Linked Google account groups connect the verified properties, so several Google logins can feed one workspace instead of everything passing through a single company account. Per-site sharing is separate: one property is granted to a named email address, and the grant can be taken back.
Give one property, not the estate
The Hamburg agency needs the German site, not the portal's figures.
- Share the single property
- Review the grant at contract renewal
Withdraw on the day, not at the audit
Access still held by a leaver is the commonest finding in any workspace review.
- Add removal to the leaver checklist
- Read the grant list quarterly
Keep the Google side tidy too. A property verified only through one employee's personal login is a property you can lose. Verify through an account the company controls, then link the groups rather than circulate passwords.
Reports that name a site, and a log that names a date
Here the second thread joins the first. At the volumes a specialised Finnish exporter deals in, aggregate figures are close to meaningless before you blend six unlike properties into them. Finnish is the working language of about five and a half million people; a specialised term in it may draw twenty searches a month, often fewer.
Add an English export site and a German one and the average spans markets sharing neither competitors nor demand. What survives is not a better average. It is per-project separation and a written record of what was done and when.
| Property | The figure worth reporting | Cadence | What to ignore |
|---|---|---|---|
| Group site | Presence for the company name and key references | Quarterly | Impression totals |
| Product-line sites | Named enquiries and the queries preceding them | Monthly | Position averaged across countries |
| Parts portal | Whether the public catalogue is findable at all | Twice a year | Click growth |
| Export-market site | New queries and first appearances in Germany | Monthly | Comparison with the English sites |
| Recruitment presence | Visibility while a vacancy is open | Per vacancy | Everything else, most of the year |
Stream — a dated record attached to the site it concerns
For estates where nobody will remember in April what changed in January.
- One chronological feed per project. Answers, automatic reports, newly placed links with donor rating and traffic, to-dos and campaign news arrive in one stream rather than across mailboxes.
- The assistant reads that project's data. A router decides per question which blocks to load — Search Console, result pages, campaign, custom — pulling none to three by relevance, so an answer about the German site stays about the German site.
- To-dos carry a state. Active, deferred or dropped, filterable alongside links and files — the difference between a decision and a vague intention.
- The record is searchable. Full-text search across messages, with twenty messages of conversation retained, means it can be interrogated rather than archived.
Board-facing reports come out of the same builder, which takes a logo and a colour set. Where two former company names are still in daily use that is more than cosmetic: a report about a line should carry that line's identity, because its readers think of themselves as working for it.
- Name the property in the title. A report headed with the group name but holding five properties' data gets quoted as though it described one.
- Date every change. At twenty searches a month, attribution is a matter of records rather than statistics.
- Split export markets by country. Country filters run across the keyword, page and traffic views, and matter more than any site-level total.
- One page per property, not one page for the estate. Six short reports are read; one long one is filed.
Semalt describes how campaigns, Google data and indexing sit behind one login, and documents the campaign levels separately: what the automatic level covers on a single domain and the tier that brings specialists, developers and writers with it. Both are per-domain decisions, so the product-line sites can run campaigns while the portal and the recruitment pages stay connected but unsubscribed.
Questions that come up
Should each property have its own campaign, or one campaign for the group?
Subscriptions attach to a domain, so the question answers itself: there is no group campaign to buy. The judgement is which domains deserve one — normally the two product-line sites and the export-market site, with the rest connected for their data alone.
Our parts portal earns most of the revenue. Should it get most of the search work?
No, and this is the trap the asymmetry sets. The portal earns that revenue because machines in the field need parts, not because anyone found it in a search result. Search work there stops at making the public catalogue findable by part number and machine name.
Can I give an external agency access without exposing commercial figures?
You can share individual properties rather than the workspace: the agency handling the German site sees that project and nothing else. What you cannot do is share a property while hiding its own numbers. Grant at the property boundary, review on a schedule, withdraw when a contract ends.
Does the 1,000-URL daily budget need managing across six sites?
Rarely, once the protected documents are excluded. The public pages come to a few hundred in total, well inside one day's allowance. The budget binds only if someone queues a login-gated tree by mistake, which is why the per-URL log is worth reading after the first large job.
Is there a view that says anything about markets we have never ranked in?
The generative research module is the closest thing, and it infers rather than measures: it classifies query intent, sorts competing domains into tiers and marks pages with room to grow. Semalt sets out what the generative views read and how the scores are produced. Treat the scores as direction over quarters and the gap lists as a writing brief.
Keep both sites in view without judging them alike
An estate assembled from product lines rather than branches has no natural common denominator, and the honest response is to stop looking for one. The group site and the parts portal are both worth keeping, for opposite reasons, and any single figure covering both describes neither.
What a shared workspace genuinely provides is narrower than portfolio marketing suggests, and more useful. Separation by project, so properties stay distinguishable. Tags, to regroup them by role when a question demands it. One connected set of Google properties. Access granted at the property boundary and revocable. And a dated record per project, which at these volumes explains more than any trend line.
The rest of our notes on measuring very small markets sit with the other English articles, and the way we run estate work alongside technical maintenance is set out on the service pages. Neither replaces deciding, before you open a dashboard, which property you are asking about.
To see your own estate laid out this way rather than a constructed one, connect the properties and let the panel gather a baseline on each: sign in and set up the first project in the Semalt dashboard. Add the quiet properties too, including those that will never carry a campaign.
On an estate like this the first useful finding is almost never a ranking. It is the moment someone notices that the property everyone talks about and the property that pays the wages have never appeared in the same report.
