Two language versions, a documentation site and whatever the last acquisition brought with it. Four properties, four people who half-own them, and a board that wants one number. Producing that number currently takes most of a working day, every quarter, and the result is not something anyone would want examined closely.
The problem is not that the properties exist. Separating an English site from a German one is usually correct, and documentation genuinely does belong somewhere else. The problem is that each was set up in its own moment, with its own access, its own reporting habits and its own idea of what a month means — and nothing was ever built to read across them.
Four properties nobody planned together
| Property | Why it exists | Who owns it now |
|---|---|---|
| English marketing site | The original site | Whoever last had time |
| German version | First local customers | A contractor, part-time |
| Documentation | Engineering wanted control | Engineering, incidentally |
| Acquired product site | Came with the deal | Formally nobody |
The third column is the finding. Four properties with four different ownership models mean anomalies are caught only where somebody happens to be looking. A property that stopped being recorded six weeks ago produces no alert and no complaint — it simply contributes nothing, and its absence is indistinguishable from a quiet quarter.
A second pattern compounds it. Properties get created and almost never retired. A discontinued side product keeps its domain, an ended campaign keeps its landing page, a renamed offering keeps both names. Two or three years in, alongside the four maintained properties sits a comparable number of half-forgotten ones — still served, still recorded, still competing for the same queries as the sites that matter. That second group appears in no inventory, because nobody considers themselves responsible for it.
The second column above is worth reading generously: each of these decisions was defensible at the time. There was a reason, a department and a deadline. What never happened was the moment where somebody looked at the resulting whole, and in a growing company that moment does not arrive on its own. It has to be scheduled, usually the first time an outsider asks for defensible numbers.
The effort is between the properties, not inside them
- Four sets of credentials. Often including at least one personal account belonging to somebody who has left. It works until the first incident, at which point exactly the access you need is unavailable.
- Four reports that do not align. Different periods, different metrics, different table layouts. Building a common statement from them takes longer than the analysis itself.
- No shared baseline. Whether the German site is performing well is only answerable relative to the others, and that comparison cannot be drawn without a common basis.
- The same work done twice. Two people research the same queries for two language versions without knowing about each other, because there is no shared place for intermediate results.
The fourth item is specific to bilingual companies and it is the least visible. Both people feel productive; neither is duplicating obviously. It only surfaces when the English and German pages end up targeting the same intent with the same argument and both underperform what one properly resourced page would have achieved.
Scattered credentials deserve more weight than they usually get. In a company assembled over three years, access typically spreads across several personal accounts, at least one belonging to somebody who has left. Nothing goes wrong while nothing goes wrong. The moment a property drops out of the record or an alert arrives, the missing access is exactly the one needed. Consolidating is an afternoon of work and removes a risk that otherwise surfaces at the least convenient time.
What changes when it all sits in one place
Labels instead of separate accounts
Each property gets a marker that behaves as a filter in every view.
- One sign-in for everything. More than thirty-five surfaces sit behind it, from position tracking to observation of generated answers.
- A filter applies everywhere. Filtering to one property holds in reporting, in tasks and in exports — not only on the screen where it was set.
- Eleven connected services. Google, Analytics and the rest converge in one place rather than existing as four parallel copies.
- A single Google authorisation. Mail, Search Console and Analytics connect once, which removes the scattered-credentials problem at its root.
Submission limits are shared, not multiplied
The number that most multi-property plans get wrong.
- The daily allowance is per account. One thousand addresses a day covers everything in it. Four properties divide that figure; they do not each receive it.
- Ten thousand addresses in one job. Accepted at once and worked through against the daily ceiling, which makes a ten-thousand-page submission a ten-day operation.
- Two jobs running, twenty queued. Filing four property migrations simultaneously means deciding the order deliberately or having it decided by whoever submitted first.
- Sitemaps nested three levels deep. Up to a thousand per job, which comfortably covers a generated documentation tree.
The first bullet of the second block is where multi-property plans break. A team assuming four thousand addresses a day plans a migration schedule on that basis, receives one thousand, and concludes the process is slow rather than that the arithmetic was wrong. On a large migration this costs weeks, and it costs them invisibly, because the jobs are running — just not at the assumed rate.
It is worth being precise about what consolidation does and does not achieve. It does not reduce the amount of work; it makes the work visible and comparable. The first weeks after bringing four properties into one view are frequently uncomfortable, because a single screen now shows how many of them are unattended and how few produce enquiries. That discomfort is the actual product — it is the information needed to decide which two deserve attention and which two can be left alone without loss.
Spending a shared allowance across four properties
| Situation | Sensible split | Reasoning |
|---|---|---|
| German version relaunching | 800 to it, 200 to the rest | Only one property is actually changing |
| Everything steady | Proportional to page count | No reason to favour any of them |
| Acquired site being merged | Full capacity for two weeks | Redirects need to be picked up quickly |
| Before a funding round | Priority to the main product site | That is the one that gets examined |
Writing this down once replaces a discussion that otherwise recurs monthly. It also records that allocation is a decision rather than a default, and that it changes when circumstances do. In a company where attention is the scarce resource, a settled rule of this kind is worth more than an additional tool.
One refinement on the fourth row. Ahead of a funding round only the main product site receives real scrutiny, and it receives more of it than at any other time. Directing the full allowance there for six to eight weeks beforehand, and letting the other three sit, costs a little progress in three places and secures a clean state in the one place that will be examined. That trade is almost always worth making, and it has to be made in advance rather than during the process.
Two language versions are not two properties
An English site and its German counterpart occupy an awkward middle position. They are separate in reporting and connected in reality: each page on one should have a declared counterpart on the other, and when that declaration is missing or wrong the two versions compete instead of supporting each other.
Each page names its counterpart
The German page declares the English one and vice versa, both pointing at addresses that actually resolve. Each version is served to the audience it was written for.
- Both versions recorded
- No competition between them
Declarations that point nowhere
Half the pairs reference addresses that changed in the last rebuild. The declarations are ignored, and the two versions are treated as unrelated near-duplicates.
- One version suppresses the other
- Invisible without checking directly
This is worth auditing after every structural change, because a rebuild on one side silently breaks pairs on the other. The check is mechanical — every declared counterpart should resolve directly, without a redirect — and it takes minutes when scripted. Left unchecked for a year, it quietly halves the value of having built the second language version at all.
There is a related decision that often gets postponed indefinitely: whether the German version should carry original text or translated text. The structural pairing works either way. What differs is performance — a translated page carries the claims across and frequently loses the precision that made them useful, whereas original German text written against observed German demand tends to do better on both counts. Deciding this deliberately, per page rather than per site, is cheaper than translating everything and then discovering which parts were worth it. Keeping the two versions' figures side by side in one place is what makes that comparison possible at all.
One set of data, four kinds of reader
The team, weekly
Wants rows it can act on. Table views of fifty to two hundred rows per page are ample, since filtering happens anyway.
- Filtered to one property
- Split by query language
The board, quarterly
Wants few numbers with a year-on-year comparison. A printed export carrying up to two hundred and fifty rows is generous for this.
- Rolled up across properties
- No query-level detail
Your own analysis
Wants raw data. Machine-readable exports carry up to ten thousand rows and load directly into whatever you already run.
- Unfiltered, complete
- Joined against internal data
Diligence and disposal
Wants traceability over time, per property. Here the documented history matters more than the current figure.
- Separable by label
- Produced under time pressure
Using one export for all four is the standard mistake in a small team. A ten-thousand-row table in a board pack looks thorough and is not read; a rolled-up view in the weekly meeting invites questions the detailed one would have answered. Separating them costs an hour of setup and nothing thereafter.
Cadence deserves the same treatment as format. Internal reports earn their keep weekly because they lead to action. Reports going upward earn theirs quarterly, because they serve a different purpose and more frequent versions mostly generate noise. Putting both on the same schedule produces either too much effort or too little currency, and in small teams usually both at once.
Asking a question across four properties
With several properties the dominant activity is not analysis but navigation — locating the view, applying the filter, remembering where last quarter's comparison lives. An assistant taking plain-language questions collapses that: each question loads between zero and three data blocks depending on what it needs, and the last twenty messages remain as context.
In practice the question becomes "which of our properties lost the most positions last month" rather than a sequence of filter selections repeated four times. Four filters bound what the answer covers — with several properties, primarily the property itself. For a weekly review inside one workspace this removes most of the clicking, and because the wording is recorded, the identical review can be run a month later without reconstructing it.
The twenty-message limit on history is a sensible boundary rather than a shortcoming. A question spanning four properties resolves in five to ten exchanges; needing substantially more usually means the original question was poorly framed. A conversation that repeatedly hits the ceiling is a signal to split the question in two, which reaches a usable answer faster than a longer thread would have.
What several properties cost
Billing is per domain rather than per account. Four properties on the entry tier come to 596 dollars a month and 7 152 across a year. A mixed arrangement — the main site on the full tier, the other three on the entry tier — is 947 monthly and 11 364 annually. Administration stays in one place either way; labels separate the reporting.
| Arrangement | Composition | Monthly | Twelve months |
|---|---|---|---|
| All four, entry tier | 4 × AutoSEO | 596 $ | 7 152 $ |
| Mixed | 1 × FullSEO, 3 × AutoSEO | 947 $ | 11 364 $ |
| Only what earns | 2 × AutoSEO | 298 $ | 3 576 $ |
Deciding that requires knowing what each property is currently reachable for, which is a keyword research question rather than a matter of opinion. Whether each is delivered and recorded cleanly is settled by a technical review, and where two of them cover the same ground with the same text, the fix belongs to on-page work rather than to more spending. Running all three from a single account is what makes the comparison across properties meaningful in the first place.
On sequencing: there is no requirement to bring all four in at once. Labels and shared reporting work from the first property, and each additional one slots in without anything being rebuilt. For a company reviewing spend quarterly, a staged approach is easier to justify than a single request covering four domains, which reads as a large number at exactly the moment somebody is looking for large numbers to cut. How positions expand later inside a connected environment does not change the initial decision.
Bring every property into one view
Questions from teams running several properties
Is the daily submission limit per property or per account?
Per account. One thousand addresses a day covers everything inside it. With four properties the split has to be a deliberate decision — otherwise capacity goes to whichever job was filed first, which is rarely the one that matters most.
Can reporting stay separated by property?
Yes, through labels that act as filters in every view. The difference from separate accounts is that the filter can also be removed, so the combined picture across all four is a setting rather than an afternoon in a spreadsheet.
Should the English and German sites be separate properties?
For reporting purposes, treating them separately is usually clearer, since their audiences and competition differ. For structural purposes they have to stay paired — each page declaring its counterpart on the other side, with both addresses resolving directly. Separate in analysis, connected in markup.
Do all properties need the same tier?
No. Billing is per domain, so mixing is normal. The usual arrangement puts the full tier on the property where somebody genuinely participates in query selection and the entry tier everywhere else — 947 dollars monthly across four properties, with the surcharge directed at the one place it can pay off.
What happens if a property is sold or spun out?
Its label allows the full history for that one property to be exported as a machine-readable file of up to ten thousand rows. That is precisely the documentation requested during diligence, and having it available shortens the exercise from weeks to days.
Is this worth doing with only two properties?
The benefit scales with the number but starts at two. Two properties already create the reconciliation problem and already compete for the same daily allowance. Two on the entry tier is 298 dollars a month, which is the smallest sensible configuration for a company that will predictably add more.