Prompts are a commodity. You can find a hundred Google Ads prompts in an afternoon, and most of them work in the sense that something plausible comes back. What almost nobody publishes is the second half: the specific way each prompt gets things wrong on a live account, and what that costs. These are the ten I use, each with its failure attached.
10, across five jobs
With the way it fails
August 10, 2026
One pattern runs through nearly all of them, so it is worth naming before the list rather than after.
The one bias to expect
Ask it whether an underperforming ad is the fault of the asset or the landing page, and it will say the asset. Ask it for the single highest-value change to a landing page, and it will say the headline. Two different prompts, two different jobs, same answer shape — because in both cases it picked the thing it could see and directly rewrite.
That is not a reason to skip these prompts. It is a reason to treat every one of them as a draft to argue with rather than a decision to act on. The same rule applies to the numbers: nothing here replaces the account data, and if you want a picture of what clicks actually cost across live accounts, that is a separate benchmark page with the raw counts behind it.
Job 1 — Keyword expansion
1.1 Seed keywords into a structured list
The first pass. It turns five or ten seeds into something with match types, funnel stages and ad groups attached.
You are helping build a Google Ads Search campaign for a [VERTICAL] business serving [GEO]. Seed keywords: [PASTE 5-10 SEEDS] Expand these into a keyword list. For each keyword, return a row with: - keyword - match type you'd recommend (exact / phrase / broad) and one clause on why - funnel stage (research / comparison / ready-to-buy) - the ad group it belongs in Rules: - Group by search intent, not by string similarity. "emergency [service]" and "24 hour [service]" go together; "[service] cost" goes somewhere else. - Do not invent branded terms for competitors I have not named. - Do not include volume or CPC estimates. You do not have that data and I will pull it from Keyword Planner. - Flag any keyword where the intent is ambiguous between two verticals. Return as a markdown table, sorted by ad group.
Where it fails. Anything generated here has to be verified before it goes anywhere near a live campaign. An unverified keyword structure does not produce a bad document — it produces paid clicks from searches the business cannot serve. The output looks finished, which is exactly the problem: a table with match types and ad groups already assigned reads like a decision rather than a first draft.
What to do. Treat the list as a set of candidates and check every row against what the business actually sells. The volume rule in the prompt matters too — the cost per click figures belong to Keyword Planner, not to a chat window.
1.2 Sort an existing list by intent
For a list you have inherited rather than one you are building.
Here is an existing keyword list from a live Google Ads account: [PASTE LIST] The account is a [VERTICAL] business. Its money-making action is [BOOKED CALL / FORM FILL / PURCHASE]. Sort every keyword into exactly one bucket: 1. Buys — someone searching this is ready to transact 2. Researches — real interest, wrong stage 3. Wrong person — a competitor, a job seeker, a student, a DIYer, a supplier 4. Can't tell from the string alone For bucket 4, say what additional signal would resolve it. Do not move anything into bucket 1 to be helpful. Bucket 1 should be small.
Where it fails. It over-fills the first bucket. Research-stage terms come back labelled ready-to-transact, and if you act on that you buy them at transaction prices. The instruction telling it to keep bucket one small is in the prompt because the pull towards a flattering answer is real — and writing the rule down reduces the problem without removing it.
What to do. Read bucket one first and assume it is too long. The terms that survive that read are the ones worth bidding hard on.
1.3 The words customers use that marketers do not
I run ads for [VERTICAL] businesses in [GEO/REGION]. List the terms real customers use for this service that a marketer would not naturally write — regional words, colloquialisms, misspellings that get typed often, the wrong-but-common technical term, and the phrase people use when they don't know the industry word. For each: the term, who says it, and whether it's worth bidding on or only worth adding as a negative. Do not list the obvious industry-standard terms. I already have those.
Where it fails. The output drifts generic. Localise it, every time, wherever it applies — there are references every local understands, and those are what make targeting and messaging land. A vocabulary list that would work anywhere is a vocabulary list that works nowhere in particular.
What to do. Give it the region explicitly, then check the result against how people in that market actually speak. The bid-or-negative column is the useful half; a term can be worth knowing and still be worth blocking.
Job 2 — Ad copy
2.1 Generate RSA headlines and descriptions
Write Responsive Search Ad assets for this ad group. Business: [WHAT THEY DO, ONE LINE] Ad group: [AD GROUP NAME] Keywords in the group: [PASTE] Landing page promise: [WHAT THE PAGE ACTUALLY OFFERS] Proof points I can use: [LICENCES, YEARS, GUARANTEE, RESPONSE TIME] Things I cannot claim: [PASTE ANY COMPLIANCE CONSTRAINTS] Produce: - 15 headlines, max 30 characters each - 4 descriptions, max 90 characters each Rules: - Count the characters. Print the count in brackets after each line. - Every asset must be true given the proof points above. If you want to say something I haven't given you evidence for, don't — list it separately under "claims I'd need you to verify". - At least 3 headlines must work as a standalone opener with no other asset. - No exclamation marks. No "Call Now!" No superlatives I can't substantiate.
Where it fails. The character count is generated, not measured. An asset can come back marked twenty-eight characters and be thirty-three, and you find out when the import rejects it.
What to do. Generate for the ideas, then count somewhere that actually counts. I run ad ideation inside Bytown now, where the limit is enforced by the tool rather than asserted in the output. Before that, the workaround was to append an explicit instruction making the model re-check its own counts as a second pass after generating — a QA step, not a reason to trust the first number.
2.2 Rewrite assets Google has rated Low
These RSA assets are live and underperforming. Google reports asset ratings of: [PASTE ASSET + RATING, e.g. "Fast emergency service — Low"] Ad group keywords: [PASTE] What the landing page says above the fold: [PASTE] For each Low-rated asset, tell me: - your read on why it's rated Low - whether the fix is the asset or the landing page - two replacement variants, character counts noted Be specific about which of the two is the likely cause. "Could be either" is not useful to me.
Where it fails. It says the asset. Nearly every time. Forcing a single call is what makes the prompt useful and also what biases it — asked to choose between the thing it can rewrite and the thing it can only read about, it picks the one it can rewrite.
What to do. Keep the forced call, then discount it. If the landing page has not changed and several assets in the same ad group are rated Low together, the page is the more likely cause whatever the answer says.
2.3 Compliance pass on finished copy
This is the one to be careful with, and the care matters more than the prompt.
Review these ad assets for a [VERTICAL] advertiser running in [JURISDICTION].
[PASTE ASSETS]
Flag anything that is:
- an unsubstantiated performance or outcome claim
- a superlative that would need evidence ("best", "#1", "fastest")
- a guarantee, or something a reader would hear as a guarantee
- a claim that triggers a platform policy or a regulated-industry rule in this
jurisdiction
For each flag: the asset, what's wrong, and a compliant rewrite that keeps the
same persuasive job.
Do not flag things that are merely bland. I want policy risk, not style notes.What to do. Run it early, as a first pass that clears the easy problems before a human looks. Then have the human look. If you advertise in a category that OpenAI itself reviews rather than opens by default, the restricted-category rules and the approval route are separate reading.
Job 3 — Negative keywords
3.1 Build a pre-launch negative list
I'm launching a Google Ads Search campaign for a [VERTICAL] business in [GEO]. They serve [WHO], and explicitly do NOT serve [WHO NOT]. Build a negative keyword list, grouped by why each term is negative: - wrong intent (free, DIY, how to, salary, jobs) - wrong product or service adjacent to theirs - wrong geography - wrong buyer (wholesale, supplier, student, competitor research) For each group, recommend a match type for the negatives and say why. Do not include terms so broad they'd block real traffic. If a term is a judgment call, put it in a separate "review these" list rather than the main one.
Where it fails. It over-blocks, and the failure is silent. Nothing errors. No alert fires. The campaign simply underdelivers against a list that was approved weeks earlier, and by the time anyone asks why volume is thin, nobody is looking at the negatives.
What to do. The "review these" bucket is the important output, not the main list. Read the broad terms out loud and ask whether a real customer might type one.
3.2 Derive negatives from a search terms report
Here is a search terms report from a live campaign: [PASTE: search term, impressions, clicks, cost, conversions] The business is [VERTICAL] and a conversion means [DEFINITION]. Identify terms to add as negatives. For each, give: - the term - the match type to negate at - the reason in one clause - the level to add it at (ad group / campaign / account list) Rank by wasted spend, highest first. Ignore terms with fewer than [N] impressions — I'll deal with the long tail separately. Do not negate a term that has converted, even once, without telling me explicitly that you're doing so and why.
Where it fails. It bins terms that have converted. An expensive term with a single conversion reads as waste when you are scanning for waste, and the explicit written rule against doing it does not reliably stop it happening. That is the part worth sitting with: the instruction is right there in the prompt, and it still goes wrong.
What to do. Before you paste anything into the negatives box, sort your own report by conversions and check nothing on that list appears on this one. A negative keyword is the one change whose damage is invisible afterwards.
Job 4 — Search terms triage
4.1 The waste scan
The original version of this prompt asked for the last seven days. That was wrong, and the fix is worth explaining rather than quietly patching.
Seven days of performance often is not enough to decide anything, depending on volume. If an account is not spending much, a week produces a handful of clicks per term and a confident-looking Kill list built on noise. Widen the window until there is enough data to support a decision — sample size sets the window, not the reporting calendar.
Search terms report for [WINDOW — see the sample-size rule below]: [PASTE] Business: [VERTICAL]. Target CPA: [$X]. Conversion action: [DEFINITION]. Before anything else: tell me whether this window holds enough data to decide on. If most terms have only a handful of clicks, say so and tell me what window would. Do not produce a Kill list from a sample too small to support one. Then give me three lists: 1. Kill — spending with no path to conversion. Include cost to date. 2. Watch — spending, no conversions yet, but the intent is right. Say what threshold should trigger a decision. 3. Promote — converting well and buried in a broad match ad group. Say which ad group it should move to. Total the wasted spend in list 1. Work only from the numbers in the table. Do not assume seasonality, competitor activity, or anything else you can't see.
Where it fails. The original framing did, by baking in a weekly cadence that suits reporting habits rather than the data. Ask a low-volume account for a seven-day verdict and you will get one, delivered with the same confidence as a verdict worth having.
What to do. Set the window from the volume. A small local account might need a month or a quarter before a Kill list means anything; a high-spending one can genuinely be read weekly. The cost per acquisition you are measuring against needs enough conversions underneath it to be a number rather than an accident.
Job 5 — Landing pages
5.1 Message-match audit
Ad group keywords: [PASTE] RSA headlines running: [PASTE] Landing page copy, above the fold: [PASTE OR DESCRIBE] Conversion action: [DEFINITION] Assess message match. Specifically: - Does the page's first screen confirm the promise the ad made? Quote the mismatch if there is one. - Is the conversion action visible without scrolling, and is it the same action the ad implied? - What is the single highest-cost friction point between arriving and converting? Give me one change, not a list. If I could only do one thing to this page, what is it and what do you expect it to move?
Where it fails. The one change is always the headline. It is the easiest thing to rewrite, so it is what gets nominated — while the expensive friction is usually further down and structural: the form, the offer, what the page asks for before it gives anything.
What to do. Ask the question twice, the second time with the headline explicitly off the table. The second answer is usually the more useful one.
What none of this replaces
Every prompt here shortens the first draft. Not one of them shortens the verification. The pattern in the comparison between ChatGPT Ads and Google Ads holds here too — the tool changes what the work looks like, not whether the work has to be done.
If you are running the ads themselves inside ChatGPT rather than using it to build Google campaigns, that is a different subject with its own rules, and it starts with what ChatGPT Ads actually is.
Questions people ask
Do these work in other models? They are written for a chat interface with a long context window and no account access. Nothing in them depends on a particular vendor.
Why no worked examples? Because real examples mean real client accounts, and anonymising a search terms report far enough to publish removes the detail that made it worth showing. The failure modes are the part you cannot get elsewhere, so that is what this page carries.
Can I give it access to the account instead of pasting? You can, and the same bias applies with more reach. A tool that can read the account still nominates the fix it can perform.
