Auto-Apply Recommendations: What to Turn Off Today

Auto-apply recommendations are Google's offer to run parts of your account on your behalf: tick a box once, and a class of changes happens automatically from then on. Some of those boxes are harmless hygiene. A few of them add keywords, move budgets and change bidding targets without a per-change review — which is to say, they transfer decisions with real spend consequences to a system whose definition of "optimised" is not obliged to match yours. The job today is knowing which boxes are which.

What auto-apply actually is, and how accounts end up enrolled

Mechanically, auto-apply is a settings page: Recommendations, then the auto-apply controls, where recommendation types can be switched on individually or accepted in bundles labelled things like "Maintain your ads" and "Grow your business". Once on, matching recommendations apply themselves; the Recommendations page's History tab records what happened.

Almost nobody remembers ticking the boxes, and that is by design of the enrolment paths: bundle prompts during setup flows, one-click acceptances in the interface, agency handovers where the previous operator's choices survive, and representative calls that end with "I'll just enable a couple of things". Enrolment is sticky in a way decisions are not — a toggle outlives the person who set it and the context that justified it. The first audit step is therefore not philosophical but factual: which toggles are on, in which accounts, since when. Point a connected AI at the settings and the History tab across every account you run and the answer comes back in seconds — in an inherited account, assume enrolment until proven otherwise.

The harmless set: hygiene with small blast radius

A minority of recommendation types are genuinely janitorial:

Toggle theme	What it does	Why it is low-risk
Remove non-serving keywords	Deletes keywords with no impressions	Cleans clutter; nothing serving changes
Remove redundant keywords	Merges duplicates covered elsewhere	Serving continues through the survivor
Fix destination issues	Flags or repairs broken landing URLs	A broken destination was already costing you
Ad rotation optimisation	Prefers better-performing ads	Marginal, reversible preference

Even here, "harmless" means low blast radius, not zero: keyword removals edit structure you may be using as a record. If you keep any auto-apply on, keep it from this table — and skim the History tab monthly anyway.

The dangerous set: keywords, budgets, bidding

The toggles to turn off today share one property: they change what you buy or what you pay, silently.

• Keyword additions — new keywords, or broader versions of existing ones, appear without a review of overlap, intent or cannibalisation. Matching expansion is precisely the change that deserves a fence and a reviewer.
• Budget raises — the recommendation optimises toward capturing available traffic, not toward your monthly commitment; a budget that raises itself defeats every pacing plan that assumed it would not.
• Bidding changes — target adjustments or strategy switches restart learning and reset the assumptions behind every downstream number.
• Reach expansions — partner networks and expansion settings widen where ads serve, with performance you only discover afterwards.
• Ad and asset changes — auto-created or auto-improved ads put words in your account's mouth; fine words, often, but published without the review your own copy gets.

None of these is malicious; all of them are Google resolving ambiguity in favour of more. The asymmetry is the problem: the upside of a good auto-applied change is small, while a bad one compounds until someone notices — and auto-apply's whole premise is that nobody is looking per change. It is the same class of risk as any unattended automation, minus the controls you would demand from one: there is no per-change approval, no evidence attached, and the log you get is a history to reconstruct rather than a proposal to judge.

Optimisation score: what it measures and what it sells

The pressure to enable auto-apply flows from optimisation score — the percentage on the Recommendations page that drifts down when advice goes unadopted. Read it precisely: the score estimates how fully the account follows Google's recommendations. That makes it a useful inventory of Google's suggestions and a poor target, because chasing it outsources exactly the judgement you are paid for. Dismissing a recommendation with a reason restores its score contribution — which tells you the score rewards engagement with advice, not obedience. Engage deliberately: review, adopt what survives contact with your data, dismiss the rest, and let the number land where it lands.

The score has an audience problem worth naming out loud: it is visible to people who do not run the account. Clients see it in reviews, managers see it in screenshots, and sales calls reference it — so a deliberate decision to hold at a modest score needs one written sentence of explanation somewhere your stakeholders read. "We review every recommendation weekly and adopt on evidence" is that sentence, and the review log below is its proof.

Auditing what auto-apply already did

Before changing the settings, establish the history — you want to know what has been steering. One prompt covers it:

Pull change history for the last 90 days. Separate changes by source: made by a person on the team, made by auto-applied recommendations, made by other automation. For the auto-applied set: group by type — keywords, budgets, bidding, ads — and list the ten with the largest plausible spend impact. Note any that were later reversed by a human.

That last line is the tell. A pattern of humans quietly reverting auto-applied changes is your account telling you a toggle fails its own audition. The mechanics of reading both ledgers — Google's change history and your own tooling's record — are covered in auditing every AI change; auto-apply is just the case where the "AI" was Google's.

The agency version: audit enrolment across every account

Multi-account operators inherit this problem at roster scale, because enrolment is per account and every onboarding imports the previous operator's choices. The sweep is one conversation with an agent connected across the manager account: for each client account, list the auto-apply toggles currently on, the date range of auto-applied changes in the History tab, and the count by type over the last quarter. The output is a roster-wide table that usually contains at least one surprise — an account whose keywords have been quietly self-expanding since a handover, or a budget toggle enabled during a long-ago support call. Standardise the endpoint: the same short list of hygiene toggles on everywhere, the dangerous set off everywhere, written into your onboarding checklist so the next inherited account gets swept on day one.

The alternative: recommendations reviewed, then applied

The choice was never auto-apply versus ignoring recommendations. The third option is the workflow auto-apply was compensating for: review each recommendation against your own data — in seconds, not an afternoon. A connected agent fetches the current recommendations, tests each one — does the keyword overlap existing coverage, does the budget raise fit the month's pacing, does the bidding change respect learning that is mid-flight — and returns a verdict list with evidence. What survives becomes approvable changes, one click each, logged with a reason. Google's signal stays in the loop; the automation stops being the decision-maker and goes back to being staff work.

The order of operations for this afternoon: run the 90-day audit, read what auto-apply has been doing, turn off the dangerous set, keep the hygiene toggles if the History tab earns them, and stand up the weekly review so recommendations keep getting judged rather than merely obeyed or ignored. Give the review job to something that reads faster than you do. Start a free pilot and run the 90-day audit prompt first — most accounts learn something from what it finds.