How I use AI to audit a Google Ads account

Auditing a Google Ads account has always meant getting the data out of the interface first. The interface shows you one view at a time, and the findings worth having come from putting views next to each other: match types across every ad group at once, negative lists against the searches they ought to be blocking, the account structure against the pages it is sending traffic to.

Two tools do that, and they do different jobs. Google Ads Editor is how bulk changes actually get made. It holds a local copy of the account, you work against that copy offline, and nothing reaches the live account until you post it. The CSV export is the other half, and it is for analysis rather than for changing anything: the entire account structure in one file, every campaign, ad group, keyword, match type, negative and setting, in a form you can work through properly and use to get a strategy agreed before anything is touched.

That division is ordinary paid search practice and it long predates any AI involvement.

What changed is the middle step. The export still comes out of Editor and the changes still go back in through it. Instead of reading through the tables and writing up the findings myself, I work through the file with Claude against a fixed checklist, and the same session that produces the analysis produces the change file in the format Editor imports.

That last part is what makes it reasonable to let an AI build the file at all. The import is not the change. Everything lands in Ads Editor as pending changes against the real account, where I can read them, correct them or throw them out, and only then post the lot in one go.

I did this on the Google Ads account for Milone’s Tree Solutions in November 2025, through the agency Emote Digital. The account came to me because it was not performing, which is the brief most audits arrive with: something is wrong, work out what. It is also the same client whose 452 suburb pages I built, so I audited the account against the site it was advertising rather than in isolation. That is where the largest finding came from.

The account as I found it

The export showed three campaigns running at once with five ad groups between them, and 118 keywords of which roughly 70% were broad match. Quality Scores sat between 3 and 6 across most ad groups. There was no account-wide negative keyword list.

The finding that mattered most was one you can only see by holding two things side by side. The site had 452 suburb landing pages live since the November 2025 relaunch. The account had no suburb-specific ad groups at all. Every one of those pages existed, ranked, and had nothing pointing at it from paid search.

What the checklist covers

The audit runs the same five passes every time. The export is what makes them possible at all. Working through it with Claude is what makes them quick enough to run in full on every account, rather than on the ones that already look like they have a problem.

Structural review. How campaigns, ad groups and keywords are organised, and where they overlap. Two of the three campaigns here were competing for the same searches while splitting a small daily budget between them.

Match type analysis. The proportion of broad, phrase and exact across the whole account. Seventy per cent broad is a number you feel in the search terms report weeks later and can see in the export immediately.

Ad copy alignment. Whether the ads in each ad group speak to that ad group’s search theme and its target keywords, or whether they are general purpose ads doing duty for everything. This is where a structural problem surfaces in the only part of the account a customer actually reads. Five ad groups were covering the full service range here, so the copy could not be specific to any of it, and it was generic accordingly: reasonable ads for a tree company rather than ads for the search someone had just typed. Splitting an account into service-level and suburb-level ad groups is only worth doing if the copy splits with it, which is why the rebuild ended with an ad written for each one rather than the existing ads redistributed.

Cross-reference against the site. Which service and location pages exist with no ad group pointing at them. This is the pass that found those orphaned suburb pages, and it only works if you know what is on the site as well as what is in the account.

Negative keyword gap analysis. What is blocked at account and ad group level, and what obvious waste is not. For a tree service that means DIY and informational searches, equipment hire, job seekers, and neighbouring services the business does not offer.

What it produced

The five passes produced eight issues, and from them a restructure: consolidate the overlapping Search campaigns into one, move off broad match, and rebuild into ad groups organised by service intent and by suburb.

The account ended up as a single Search campaign with 17 ad groups: 11 by service and intent, five by Tier 1 suburb, and the original one. Each got its own responsive search ad. Underneath sat an 80-plus term account-wide negative list and a negative keyword matrix at ad group level, so a stump grinding search cannot trigger the tree removal ad group, with phrase match throughout.

The suburb ad groups map to the suburb landing pages, so the search, the ad and the page finally agree with each other.

I made the changes myself. Some went in directly through Ads Editor and the interface, including pausing the conflicting campaign and moving the keywords to phrase match while the account settled. The rest came in as imported files, which I reviewed in Editor before posting. Nothing went live that I had not read first.

Performance lifted substantially after the rebuild. I do not have the reporting from that period to hand, so that is as far as I will take the claim. Where I control the measurement now, the figures come out of a reporting pipeline rather than a screenshot. What I can show is the work: an account that was fighting itself across three campaigns became one campaign whose structure matched the site it was advertising.

What it got wrong, and what only looked wrong

This is the part worth reading. The failures were consistent, which makes them easy to check for, and they are the reason I do not hand any of this over unchecked.

It under-proposed the ad group structure. The first pass of recommendations had no general Arborist Services ad group, and no separate Emergency or Hazardous Tree Removal groups. Those are high intent, high value searches that deserve their own targeting and their own ad copy rather than being folded into general tree removal. I added them. An AI working from an export can see what is in the account and cannot see what a customer in trouble types at 9pm.

It could not count characters. The first pass of responsive search ad copy came back over Google’s limits: headlines past the 30 character ceiling and descriptions past 90. That was a real error, not a formatting misunderstanding. Language models work in tokens rather than characters, so a hard character ceiling is exactly the kind of constraint they are bad at respecting, and they will tell you the copy fits when it does not. Overlong assets are rejected on import rather than trimmed, so the file has to be rebuilt. The rebuild capped headlines at 30 and brought descriptions to 85 to 90, close enough to the limit to use the space without crossing it, with a verification pass and a summary listing the count for every asset. Now I ask for those counts as part of the output, so checking them takes seconds instead of a re-read.

Two things looked like errors and were not. The updated CSV opened with strange characters and looked corrupted. Checking the actual bytes rather than how a text editor displayed them showed ÿþ, the UTF-16 byte order mark that Ads Editor requires for its own import format. Working as intended. Later, the import into Ads Editor threw a run of “cannot import new automatically created assets” warnings, which turned out to relate to Performance Max asset columns that cannot be imported this way and had no effect on the Search structure being built. Both times the answer came from checking the file or the log directly. Neither was worth a rebuild, and either one could have cost a day.

Since then I ask for a plain-language summary alongside every technical file, so I can sanity-check what changed without interpreting a raw CSV or an import log.

What a CSV cannot tell you

The export is a structural snapshot, and a structural audit is genuinely useful. It is not a complete audit, because the file carries no performance data at all.

It cannot tell me which search terms took spend and returned nothing over the last ninety days. It cannot tell me whether impression share is being lost to budget or to rank, which is the difference between a spending problem and a relevance problem. It cannot tell me whether the conversion actions are counting what the client believes they count, which is where more paid search reporting goes wrong than anywhere else. All of that still comes from the interface, by hand, and it does not join up with the structural work.

Where this goes next

Google released an official Google Ads MCP server in April 2026. It is read-only, and it lets a tool like Claude Code run Google Ads Query Language queries against a live account instead of a file: the same structural data, plus the performance history the export does not carry, without an export step at all. Account size stops being a limit, because a query returns the rows you asked for rather than the whole account.

It would replace the analysis half and leave the other half alone. The server cannot change anything, which is the right call, so Ads Editor stays where changes are staged, checked and posted.

I have not built this yet, and I want to be plain about why, because the obstacle is not the tooling. Querying a real account needs a Google Ads manager account and a developer token approved for Basic Access, and the account being audited has to be linked to the manager account holding that token. For an ongoing client that is a link request. For a prospect who has handed over a login and nothing else, it is not available at all, which is exactly when a free-standing audit is most useful. So the export workflow above is not a stopgap. It is the version that works on any account someone gives me access to, and the API route will be the better way to analyse the accounts I hold properly.

The risk worth settling first

Read-only describes Google’s official MCP server, not the entire category of tools. Several third-party Google Ads MCP servers offer mutation access as a selling point, and connecting one of those would remove the staging step altogether. An agent would go from reading the account to changing it with nothing in between.

That is a worse trade in Google Ads than it would be in most systems, because some of it does not come back. Pausing is reversible. Removing is not. A removed keyword cannot be re-enabled, and the only route back is to create a new one, which starts with none of the history the old one had. An agent that tidies away forty keywords it has judged redundant has not made a change I can undo.

The API does offer a dry run. Most mutate requests accept a validate_only flag, which validates the request fully and skips the execution. That is useful, and it is not the same thing as Ads Editor. validate_only tells me the request is well formed. Editor shows me what the account will look like afterwards and waits for me to agree. One checks syntax, the other checks intent.

The difference matters because of the failure this account already produced. The ad copy that came back over the character limits was invalid, so an API would have rejected it and I would have found out either way. The errors worth worrying about are the valid ones: a keyword in the wrong ad group, a negative that blocks traffic which was converting, a bid change that is legal and wrong. Those pass validation. Nothing catches them except a person reading the list before it goes live.

So the split should stay, and I would keep it even once the API route is running. Analysis through the API, where the speed and the coverage are worth having. Changes through Ads Editor, where they can be read and rejected. Not as a transitional arrangement while I learn to trust the tooling, but because a staging step someone has to clear is worth more than the minutes it costs.

The checklist is the part that carries across either way. The tool changed what I could ask. It did not decide what was worth asking.