If you run Google Ads for more than one business, the single-account advice stops fitting. You are not structuring one account's negatives — you are trying to apply the same hygiene across a roster of separate accounts without hand-copying the same exclusions into each one. Google's answer is the manager account (MCC): from it you can build a negative keyword list once and share it across the accounts you manage, so one edit lands everywhere. That is genuinely useful, and it is also where most people misread what the feature does. This post is the cross-account companion to the single-account posts on where each negative belongs and how far lists scale — the mechanism here is the manager-level library, not the per-account one.
How a manager-level shared negative list actually works
A manager-level shared negative keyword list is a list you build once in the manager (MCC) account's Shared Library and then apply down to multiple sub-accounts you manage. Create it under Tools → Shared Library → Negative keyword lists in the manager account, add your terms, and apply it to the accounts or campaigns that should inherit it. The payoff is that maintenance collapses to one place: add a new universally-irrelevant term and every linked account picks it up, instead of you opening ten accounts and pasting the same word ten times. This only works while the accounts share that manager account — accounts with no common manager cannot share a list, and you are back to parallel copies.
The thing to be precise about is that “shared across accounts” still resolves to campaigns. A negative keyword list is applied to campaigns; it is not a free-floating account setting until you attach it. That is a different object from an account-level negative keyword list, which lives inside a single account and, per Google's documentation, “will automatically apply to all search and shopping inventory in relevant campaign types” — Search, Performance Max, App, Smart and Local — with nothing to attach. So you have two levers that sound the same and are not: the manager-level shared list pushes one set of words to many accounts where you apply it, and the account-level list auto-covers every campaign in one account. A roster-wide junk set belongs on the first; a client-specific exclusion that must blanket one account belongs on the second.
What sharing a list does not do: it does not find the waste
Sharing an exclusion list across clients scales the decisions you have already made; it does nothing to find the new junk each account is accumulating. This is the single most common misread of the feature. A manager-level list pushes the words you have decided to block — it does not open anyone's search terms report, and the search terms report is the only place the new waste shows up. That report is per-account, privacy-thresholded, and will never reconcile to campaign totals, and there is no native manager-level view that merges every client's terms into one screen. The finding is still ten separate jobs even when the blocking is one.
Two more gaps survive the move to a manager account because they are properties of negatives themselves, not of where the list lives. First, negative keywords do not match close variants: a shared negative for “free” will not catch “freee” or a close paraphrase, so a roster-wide list leaks the same way a single-account list does, just across more accounts. Second, Performance Max exposes search categories rather than raw queries, so a shared negative list applied to a client's PMax campaigns is working against partial visibility no matter how clean the manager account is. The shared list is a distribution mechanism for exclusions; it is not a hygiene system.
The real decision: one universal list or per-client lists
The hard call in a manager account is which exclusions are genuinely universal and which are one client's junk that would be another client's revenue. Keep the shared roster-wide list narrow: terms that are irrelevant for essentially every account you run — obvious adult or illegal modifiers, clearly off-category words, spam patterns. The moment a candidate is “junk for most clients,” it does not belong in the shared list, because the exception is where it costs you. The classic trap is a word like “free” or “jobs”: safe to block almost everywhere, quietly fatal for the freemium product bidding on “free” trials or the recruiter whose best queries contain “jobs.”
Because a manager-level edit propagates to every linked account at once, that mistake is not contained — it blocks converting traffic across the whole roster the instant you save. This is the same over-negating failure that throttles a single account, multiplied by your client count. The defensible structure is a tiered one: a small, stable, truly-universal shared list at the manager level, and then each client's own specific exclusions kept in that account — either in its account-level list or in account-scoped shared lists. When you find yourself tempted to add a client-specific term to the shared list “just this once,” that is the signal it belongs in the client's own list instead. For the within-account version of this placement decision, the campaign-level versus shared-list trade-off still applies underneath.
Running the weekly pass across a roster
Split the work into a shared layer that rarely changes and a per-account layer that is the actual weekly job. The shared layer is your narrow universal list at the manager level; you touch it only when a genuinely cross-client junk pattern appears, which is rare. The per-account layer is unavoidable manual time: open each client's search terms report, filter to high-cost terms with zero conversions, confirm they are irrelevant rather than mis-tracked, and negate the new waste into that account's own lists. The decision rule for each new term is simple — is this junk for every client (shared list) or just this one (account list)?
The reason this gets painful is arithmetic. The blocking scales — one shared list, applied everywhere — but the finding does not, because the search terms report is per-account and there is no native merged view. Ten accounts is ten report passes a week; thirty accounts is thirty. That linear cost is exactly the bottleneck that pushes agencies toward aggregating every account's search terms into a single queue so the finding scales like the blocking does. Whether you build that with the Google Ads API, a spreadsheet export routine, or a dedicated tool, the goal is the same: stop opening thirty reports by hand and start reviewing one list of everyone's new waste. Until the finding is centralised, the manager-level shared list is only half a system.
Related reading
For where each negative belongs inside a single account, see negative keyword lists: account vs shared vs campaign. For how far those lists scale before you hit limits, see scaling negative keyword lists, and for the risk a roster-wide list amplifies, see over-negating and throttling good traffic.