The portfolio playbook

Start with the arithmetic, because the arithmetic is the whole problem. An operator running six WordPress sites at 30 articles a month each is moving 180 articles, and the writing is the visible half. The invisible half is per-article logistics: formatting the draft, setting the featured image, categories, metadata, scheduling it, confirming it actually published, confirming it actually got indexed. Call it ten minutes per article when nothing goes wrong, and something always goes wrong. That's roughly 30 hours a month of pure logistics on a six-site portfolio, before anyone has checked a ranking, read a Search Console report, or decided what next month's content should be.

Now scale the same math to 20 sites, or 50. The work that grows linearly with site count (publishing, checking, monitoring) swallows the operator long before the work that actually earns the money: deciding what to build, what to fix, and what to kill. Every failure mode in portfolio operations is downstream of that one inversion. The playbook, compressed to a sentence: systematize everything that scales with site count, so your attention only goes where judgment is needed. The rest of this page is what that means in practice, and at what size each piece stops being optional.

What breaks at 5, 20, and 50 sites

The exact numbers are fuzzy: they depend on cadence and on how much you've already systematized. The sequence isn't. These thresholds arrive in the same order for everyone; running a portfolio at 200 just means having met all three.

Around 5 sites, memory breaks. Below that, the portfolio fits in your head: you know what's published where, which site is due for content, which one had the weird plugin issue. Past it, you don't, and the first symptoms are quiet ones. Two sites covering the same topic without meaning to. A site that silently missed two weeks of its cadence because nothing was checking. The fix is boring and non-optional: a written profile per site (niche, cadence, publishing mode, credentials, quirks) and a publishing calendar that exists outside your head. Operators resist this step because five sites still feels manageable. It is, right up until the first silent miss.

Around 20 sites, process breaks. The spreadsheet-and-willpower system that replaced your memory now becomes a job in itself. Checking Search Console weekly per site is twenty logins; honest version: you stop. Publishing stays consistent only on the sites you happen to look at. This is the threshold where you learn about problems from the revenue graph instead of from monitoring, weeks late, which for anything algorithmic is the difference between a contained fix and a full site triage. The fix is aggregation and alerting: one view across every site, machine-checked daily, that tells you what changed instead of waiting for you to look. From here on, you manage by exception or you don't manage.

Around 50 sites, attention breaks. Even with a good dashboard, you cannot give 50 sites equal attention, and pretending otherwise means your best site gets the same ten distracted minutes as your worst. The fix is admitting the portfolio has tiers and running different rules per tier: money sites get human review before anything publishes and a scheduled deep-dive; middle-tier sites run on automation with review-by-exception; experiments run fast and cheap and are allowed to fail. Tiering feels like giving up on sites. It's the opposite: it's the only way the sites that matter get what they need.

Past 50, nothing categorically new breaks. The same three systems (written profiles, aggregated monitoring, tiered attention) either hold at 200 or they were already failing at 60. Which is the real lesson of the thresholds: each one is cheap to build before you hit it and expensive to build after, because after, you're building the system while bailing out the consequences of not having it. I built the monitoring layer after a 40% drop instead of before it; the HCU guide is the expensive version of this lesson.

What to automate, and what never to

The line that works: automate observation and execution; never automate judgment on anything you can't afford to lose. Concretely, automate:

• Publishing mechanics - scheduling, formatting, metadata, the entire path from approved draft to live post. Zero judgment, pure repetition, and the single biggest reclaim of hours (it's most of the 30-hour figure above).
• Indexing checks - whether what you published is actually in the index, checked daily by machine. Nobody does this manually across a portfolio, which is exactly why deindexing gets discovered months late.
• Ranking observation - position movement on the queries that matter, watched continuously, surfaced as alerts when something that was ranking starts sliding. One data point of decline is information; a month of it is damage.
• The paper trail - what published where and when, what changed, what got flagged. When something breaks, the first question is always "what changed?", and a portfolio can't answer that from memory.

And never automate, no matter how good the tooling gets:

• What ships on sites that matter. Review mode on money sites is not a bottleneck to optimize away; it's the control that keeps one bad batch of content from becoming a site-level quality problem. The HCU guide arrives at the same rule from the recovery side: publish at the speed of review, not the speed of generation.
• The delete / refresh / keep call. Tooling should assemble the evidence and propose the answer; a human makes it. These decisions are site strategy, made one article at a time.
• Portfolio composition. What niche to enter, which site to invest in, which to kill or sell. No dashboard makes this call; it just makes it with better information.

The point of the split isn't caution for its own sake. Automating the observation layer is what makes the judgment layer good: a human deciding "delete or refresh?" with full performance history in front of them makes a better call in thirty seconds than the same human making it blind after an hour of tab-hopping.

Measuring across a portfolio, not one site at a time

Per-site checking doesn't scale: it either takes over your week or quietly stops happening. The shift that fixes it is asking one question of the whole portfolio instead of twenty questions of twenty sites: "which sites need me today?" Answering that needs a handful of portfolio-level measures, each compared against the site's own baseline. Sites in different niches should never be compared against each other:

• Publishing health - did every site do what its cadence says it should have? Misses surface here first, days before they'd show anywhere else.
• Indexation rate - of what published recently, how much is in the index? A site whose new content stopped getting indexed has a problem that traffic graphs won't show for weeks.
• Ranking movement - this week's winners and losers across the whole portfolio, sorted by size of move. This is the attention-allocation list: the site with three sliding money pages needs you today; the nineteen flat ones don't.
• Trajectory versus own baseline - each site tracked against its own history. A small site growing 20% deserves investment; a big site flat for two quarters deserves a question.
• Cost per site - the number nobody tracks and everyone should. Hosting, tools, content, attention. A portfolio reliably carries a few sites that earn less than they cost to keep, invisible until this number is written down.

Cadence: daily is the exception scan. Minutes, driven by alerts, most days ending in "nothing needs me." Monthly is a real review of a rotating subset, so every site gets genuinely looked at on a cycle even if it never trips an alert. Quarterly is composition: kill, keep, or invest, per site, using the cost and trajectory numbers. That last meeting is the one operators skip, and it's how a portfolio ends up carrying six zombie sites for two years.

The stack, honestly

The honest version is shorter than the affiliate-blog version, and the categories matter more than the brand names:

• WordPress on every site, boring on purpose. One CMS pattern means one publishing integration, one credential model (Application Passwords), one set of failure modes learned once. Portfolio operations reward standardization far more than any single site's ideal setup would.
• Search Console on every site from day one. It's free and it's the closest thing to ground truth for queries, positions, and indexing. Not connecting it on a new site is throwing away the only history you can't buy later.
• Hosting standardized on as few providers as possible - with staging, automated backups, and uptime monitoring. At portfolio scale the host's feature list matters less than having one recovery runbook and one credential pattern across every site, instead of twelve different ones to remember at 2am.
• A keyword research tool of your choice (Ahrefs and Semrush are the usual suspects) for deciding what's worth writing. Research is a judgment input, so it stays a tool a human drives, not a pipe that feeds the queue automatically.
• One aggregation layer for publishing, indexing, ranking, and triage across every site at once. This is the layer I could not buy when the portfolio needed it, which is why ImprintSEO exists; the usual predecessor is a spreadsheet, and a spreadsheet holds up to about ten sites and limps to twenty.

What's deliberately absent: the long tail of per-site subscriptions. The separate optimizer, the separate AI-detection scanner, the separate brief builder, each billed monthly, each multiplied by site count. Every tool in a portfolio stack has to justify itself times N sites, and very few do.

FAQ