Search for a support question about your own product and see what comes back. In a good number of software companies the first result is not the official documentation. It is a four-year-old community thread, written by a user, describing a workaround for a bug that was fixed in the meantime — and it outranks everything your documentation team has ever published.
This is what happens when a company runs five properties that were never planned together. The product site, the documentation, the status page, the community forum and whatever came with the last acquisition all carry the same brand, all answer overlapping questions, and none of them was set up with any awareness of the others. The forum wins because forums accumulate links and age; the documentation loses because nobody ever compared the two.
Five properties, one product
| Property | Why it exists | Who owns it now |
|---|---|---|
| Product site | The commercial presence | Marketing |
| Documentation | Engineering wanted its own tooling | Technical writing |
| Community forum | Support wanted to reduce ticket volume | Support, loosely |
| Status page | An outage in 2021 | Operations |
| Acquired product site | Came with the deal | Formally nobody |
The third column is the finding. Five properties with five different owners means anomalies are noticed only where somebody happens to be looking. A property that stopped being catalogued six weeks ago produces no alert and no complaint — it simply contributes nothing, which is indistinguishable from a quiet quarter.
Five answers to the same question
The administrative overhead is irritating and survivable. The serious problem is that the five properties compete with one another for the same questions, and the winner is decided by accumulated age and links rather than by which answer is correct.
Each property has its own job
Documentation explains, the forum discusses, the status page reports. Clean separation, sensible ownership, no conflict on paper.
- Clear internal boundaries
- Each team autonomous
Three of them answer the same question
A user asks how something works. Documentation explains it, the forum debates it, an old release note mentions it. The oldest and best-linked one surfaces.
- Correctness is not the deciding factor
- Nobody sees the conflict internally
The forum case deserves separate treatment because it is both the most common and the most awkward. A community forum is genuinely valuable, generates content nobody has to write, and accumulates standing quickly. It also contains outdated answers that will never be corrected, and those answers represent the company to anyone who finds them first. Shutting it down is the wrong response; leaving it entirely unmanaged is the current one.
A further consequence only becomes apparent once all five are viewed side by side: identical groundwork carried out twice over. Somebody in one team investigates a set of questions for their property while somebody in another does the same investigation for theirs, neither aware of the other, because nowhere is there a common place to leave a half-finished result. Each of them is working hard and neither is doing anything you could point at as a mistake. The waste only shows up at the end, when two properties tackle one query using the same reasoning and each performs less well than a single properly resourced page would have done on its own.
A related pattern compounds it. Properties get created and almost never retired. A discontinued integration keeps its landing page, an ended campaign keeps its microsite, a renamed module keeps both names. A few years in, alongside the five that somebody maintains sits a comparable number of forgotten ones — still served, still catalogued, still bidding for the same product terms. No inventory contains them, because no team considers them theirs.
What changes when everything reports to one place
Markers rather than separate accounts
Each property carries a label that behaves as a filter across every screen.
- One login covers all five. More than thirty-five screens sit behind it, from placement tracking through to observation of assembled answers.
- A restriction travels with you. Narrow to one property and it holds in the figures, in the task list and in every file produced — not only on the screen where it was applied.
- Eleven connections in one place. What arrives from Google, from Analytics and from other services meets in a single location rather than existing five times over.
- Authorise Google once rather than five times. A single grant covers the mailbox, Search Console and Analytics together — which is what makes the scattered-credentials problem go away rather than merely become manageable.
The daily allowance is pooled
Where planning for several properties goes astray more reliably than anywhere else.
- One thousand a day, and it is the account's. Everything held under that account draws from the same daily figure. With five properties the figure gets carved up; it does not arrive five times over.
- A batch holds up to ten thousand. The whole list is accepted immediately and then processed against the daily limit — which puts a full ten thousand at roughly a fortnight of working days.
- Two run at a time, twenty queue behind. Submit changes for several properties simultaneously and either you determine the sequence or the clock does it for you.
- Three levels of nesting, a thousand sitemaps in a batch. More than enough for documentation organised by release and topic, so long as something actually links to the index files.
Everything tends to go wrong at that opening point. Because the company runs five properties, somebody assumes five thousand addresses will clear each day and lays out the migration timetable accordingly. One thousand arrive. The conclusion drawn is that the mechanism is sluggish, when the arithmetic was simply wrong from the start. On a documentation rebuild the error costs several weeks, and it does so without anybody noticing, since the batches genuinely are processing — at one fifth of the speed the plan assumed.
The consolidated Google grant gets less credit than it deserves. In a company assembled over eight or ten years, access typically hangs off several individual accounts, at least one belonging to somebody who has since left. Day to day nothing goes wrong. Then a property disappears from the record or a warning arrives, and the account nobody can reach turns out to be exactly the one needed. Half a day of tidying closes that exposure permanently, and of everything on this list it is the only item with no case for postponement.
Spending a shared allowance across five properties
| Situation | Sensible division | Reasoning |
|---|---|---|
| A documentation rebuild is running | Eight hundred to it, the remainder shared | Nothing else is being altered |
| A quiet month | In proportion to how many pages each holds | No case for favouring any of them |
| Acquired product being merged in | Full allowance to the redirects | They need picking up quickly |
| Ahead of a funding round | Priority to the product site | That is the one examined |
Write it down a single time and the recurring quarrel — two teams both wanting capacity in the same seven days — evaporates. What the note additionally establishes is that a person is allocating the pool on purpose, instead of the default behaviour of the system allocating it by accident, and that the allocation gets looked at again whenever the situation moves.
Deciding which property answers which question
How something works, currently
The canonical answer. Everything else on this list should defer to it and link to it rather than restating it.
- Exposed and maintained
- Linked from forum answers
Edge cases and workarounds
Valuable for what documentation cannot cover. Damaging where an obsolete thread answers a question the documentation answers correctly.
- Close and redirect solved threads
- Date-stamp everything
What is happening right now
Useful for minutes and misleading for years. Historical incident pages accumulate and answer questions nobody is asking any more.
- Current page exposed
- Incident history not
A product that now has another name
Either merged properly into the main properties or left competing with them under a brand you no longer market.
- Redirect page by page
- One hop, not a chain
The forum item is the one that requires an actual policy rather than a decision. A thread whose question is now answered properly in the documentation should be closed with a link to that answer — not deleted, because deletion discards its accumulated standing, and not left open, because an open thread with an outdated accepted answer continues to represent the product. Working through the fifty most-visited threads once takes a week and permanently changes which of your properties answers the common questions.
Be clear about what consolidation achieves and what it does not. The volume of work stays the same; what changes is that it becomes visible and comparable. The opening weeks are frequently uncomfortable, because a single screen now shows how many properties run unattended and how few produce anything. That discomfort is the actual output — it is the information needed to decide which two deserve attention and which three can be left alone without loss.
One data set, several kinds of reader
Five properties with five owners produce a reporting problem before they produce anything else: each owner wants their own figures, leadership wants the comparison, and both come from the same underlying data. Separate outputs resolve this without argument.
- Each owner, monthly, their property only. Table views of fifty to two hundred rows per screen are ample, since filtering happens anyway.
- Leadership sees all five together, once a quarter. A printed export tops out at two hundred and fifty rows, which is already several times more than anyone at this level will work through.
- Analysis, on demand, unfiltered. Data files reach ten thousand rows and load directly into whatever is already running.
- Diligence, rarely and urgently, per property. Here the documented history matters more than the current figure, and the marker makes it separable.
The first two sit in tension, as they do in any organisation with distributed ownership. The cross-property comparison is the most useful view for leadership and the least welcome one for whoever owns the property that comes off worst. Producing them separately from one source at least removes any argument about whose numbers are right.
Frequency deserves the same treatment as format. What goes to a property owner belongs on a monthly rhythm because it prompts action. What goes upward belongs on a quarterly one, because it serves a different purpose and more frequent versions mainly generate friction between teams. One rhythm for both produces either wasted effort or stale figures, and in a company with a small marketing function usually both.
Asking a question across five properties
Once five properties are in play, most of the working hour goes on getting somewhere rather than on thinking: finding the report, narrowing it down, trying to recall where the previous quarter's comparison ended up. Being able to put the question into an ordinary sentence deletes that step. Between nothing and three blocks of data get fetched, according to what the question requires, and the last twenty turns of the conversation remain in view so that a follow-up lands sensibly.
One question is worth asking deliberately in this configuration: for which queries do two of our own properties appear at the same time? The answer is the working list for the governance decision above, and it can be produced in one workspace in minutes, whereas assembling it from five separate accounts is effectively impossible.
What several properties cost
What gets billed is each domain, not the account as a whole. Take four properties on the lower tier together with five encyclopedic placements: that comes out at 646 dollars monthly, 7 752 over twelve months. A mixed arrangement — the product site on the upper tier, three others below it, plus a hundred network placements — is 1 047 monthly and 12 564 annually.
| Configuration | Components | Monthly | Twelve-month total |
|---|---|---|---|
| All four on the lower tier | 4 × AutoSEO with 5 encyclopedic placements (50 $) | 646 $ | 7 752 $ |
| Mixed | 1 × FullSEO, 3 × AutoSEO, plus 100 network (100 $) | 1 047 $ | 12 564 $ |
| Once consolidated | 2 × AutoSEO | 298 $ | 3 576 $ |
Keeping the retire-or-keep decision recorded in one place stops a later arrival from quietly reviving a property that looked like an oversight.
Deciding which properties survive means establishing what each is currently found for, which is a keyword research question rather than an internal negotiation. A technical review answers whether each ships and gets catalogued properly. Where two of them cover the same ground in different words, the remedy is on-page work and not more budget. Doing all three out of a single account is what makes comparing the properties possible at all.
A word on order of adoption. There is no obligation to onboard everything simultaneously. From the very first property the labelling and the shared reporting are already doing their job, and adding the next one later involves no rework of what is in place. In an organisation where budgets sit with individual teams, going step by step also avoids the political problem of getting five owners to commit to a single start date — which, with five owners, tends to be the harder part of the exercise. Watching the first property settle inside a shared overview tends to make the argument for the second one unnecessary.
Bring every property into one view
Questions from teams running several properties
Our forum outranks our documentation. Should we close it?
No. Close individual threads whose question the documentation now answers, linking to that answer, and leave the rest. Deleting the forum discards years of accumulated standing; leaving it unmanaged lets obsolete answers represent the product. Working through the fifty most-visited threads takes a week and changes which property answers the common questions.
Does each property get its own thousand a day?
They share it. The allowance belongs to the account, so five properties draw from the same pool. During a documentation rebuild the split has to be decided explicitly — otherwise whichever batch went in first consumes what is available, importance notwithstanding.
Should the status page be exposed at all?
The current page yes, the incident history no. Historical incident pages accumulate indefinitely, each describing a problem nobody is asking about any more, and they consume allowance while adding nothing. Keeping the current page exposed preserves the part that serves customers.
Do all properties need the same tier?
No, and it is usually wrong. Because the charge follows the domain, combinations are free. Put the upper tier where somebody genuinely takes part in choosing queries — for a software company that is the product site — and leave the rest below it. Across four properties the arrangement above works out at 1 047 dollars a month.
Can property owners see each other's figures?
That depends entirely on how it is set up. Since every screen honours the labels as filters, an owner can be sent a report covering nothing but their own property, while the side-by-side view stays with leadership. As both are generated from one dataset, there is no scope for an argument about which set of numbers is the real one.
What happens to the acquired product's site?
Every page gets pointed at its counterpart on whichever property survives, with a single hop and no chain. Turning the site off and leaving nothing behind discards the standing it built up over however many years, and that is seldom worth nothing. Because the site carries its own marker, the complete record for that product can also be pulled out as a file running to ten thousand rows — precisely the document requested during due diligence.