Google stopped advertisers from creating new campaign-level broad match settings on 3 August 2026, four weeks before the AI Max migration that begins on 1 September. The block also covers new legacy automatically created assets configurations, and it is enforced in the Google Ads interface, in Google Ads Editor and in every version of the Google Ads API at the same time.
The 1 September auto-upgrade itself was already known and has been covered here before. What is new in this story is the enforcement and the calendar around it: the creation gate closed on 3 August, before Google's 5 August email to advertisers and nine days before Bob Hancock of the Google Ads API Team published the mechanics on the Google Ads Developer Blog on 12 August 2026. There is now a published end to end timetable that runs to around September 2027, including a separate Dynamic Search Ads migration window in February 2027. PPC Land reported the sequence on 13 August in its account of the migration, and says the changes apply to Google Ads accounts globally with no region-specific carve-outs.
What was blocked on 3 August 2026
Two specific things can no longer be created. The first is a new campaign-level broad match setting, the account-side configuration that turned broad match behaviour on for a whole campaign. The second is a new standalone legacy automatically created assets configuration. Both were previously part of routine campaign build work, and both now return nothing when you try to create them.
The important detail is where the block sits. It is not an interface-only change that a power user can route around. Google enforced it in the interface, in Google Ads Editor and across all versions of the Google Ads API, which means bulk sheets, scripted builds and third party tools hit the same wall. If your build process quietly creates these settings as part of a template, it started failing on 3 August whether or not anyone noticed.
The order of events matters more than the events
Read the dates in sequence. Google closed creation on 3 August. Google emailed advertisers about the 1 September conversion on 5 August. Bob Hancock of the Google Ads API Team published the migration mechanics on the Google Ads Developer Blog on 12 August. The enforcement therefore ran ahead of the notice by two days, and ahead of the technical explanation by nine.
That gap is the practical lesson in this story. For nine days there was an enforced behaviour change with no published explanation of what it was or what would replace it. Anyone whose build broke in that window had no documentation to check. It is a reminder that in a migration of this size, the account is the source of truth about what is currently possible, and the blog post is the source of truth about why. They do not arrive at the same time.
The full timetable, from the 3 August block to the API sunset
The dates below are the ones Google has published, set against what happens on each. Everything after 12 August is scheduled rather than done.
| Date | What happens |
|---|---|
| 3 August 2026 | Creation of new campaign-level broad match settings and new legacy automatically created assets configurations is blocked in the interface, in Google Ads Editor and in all API versions |
| 5 August 2026 | Google emails advertisers confirming the 1 September conversion |
| 12 August 2026 | Bob Hancock of the Google Ads API Team publishes the migration mechanics on the Google Ads Developer Blog |
| 1 to 30 September 2026 | Phase 1 of the migration runs progressively through the month, with in-account pre-migration banners for Dynamic Search Ads campaigns |
| 1 to 28 February 2027 | Phase 2, the Dynamic Search Ads migration window, with official reminder notifications sent on 15 January 2027 |
Beyond the table, API versions released after 1 September 2026 remove the legacy entities entirely, and older versions carry legacy setups until their scheduled sunset at around September 2027, which follows the usual twelve month version lifecycle. That is the real end date for anything still running on legacy configurations.
What Phase 1 sets in September 2026
Google published the settings each cohort lands on, which is more useful than knowing the date. Campaigns in the broad match cohort migrate with text customization off, search term matching on and final URL expansion off. Campaigns in the automatically created assets cohort migrate with text customization on, search term matching on and final URL expansion off. Brand lists are preserved for broad match campaigns.
Two of those defaults deserve attention before September rather than after. Search term matching on is the setting that widens which queries a campaign can serve against, so it is the one most likely to change what your search terms report looks like in the first weeks of the month. Final URL expansion off is the conservative choice and means the system will not send traffic to pages you did not nominate, at least at migration time. If a campaign of yours depends on either behaviour being the opposite of the default, that is something to plan for now, not to discover in a weekly report.
The migration runs progressively from 1 to 30 September rather than on a single date, so two campaigns in the same account can convert weeks apart. Comparing September against August at account level will mix migrated and unmigrated campaigns together and produce a number that means very little.
What you can still do with legacy settings today
The block is on creation, not on everything. As of the source's reporting you can still:
- Read existing legacy entities through older API versions.
- Edit existing legacy configurations through older API versions.
- Pause or delete legacy configurations.
- Pause campaigns that have not yet migrated.
- Upgrade voluntarily from September 2026 onward using the "Upgrade Your Dynamic Search Ads" setting rather than waiting for the automatic window.
What you cannot do is create anything new of these types, in any surface. And once legacy expanded dynamic search ads transition into standard ad groups, they can no longer be modified at all: attempts to modify them, as opposed to pausing or deleting them, trigger API error codes. The source references those errors without listing the specific codes, so if you maintain an integration, the safe assumption is that modify calls against migrated legacy entities will fail and your error handling should treat that as expected rather than as an outage.
The February 2027 Dynamic Search Ads window
The Dynamic Search Ads migration is a separate event on its own calendar, and it is the part most likely to be forgotten because it sits five months past the September noise. In-account pre-migration banners appear from September 2026. Official reminder notifications go out on 15 January 2027. The automigration itself runs from 1 to 28 February 2027, and creation of new DSA ad groups is permanently removed at that point. DSA campaigns move to standard Search with AI Max enabled.
For anyone running DSA at scale against a large catalogue, this is the change with the longest tail. DSA built its targeting from your site's crawlable content, so the quality of that content has been doing quiet work in those campaigns for years. Moving to standard Search with AI Max does not delete that dependency, it relocates it. This is one of the few places where what is actually on your pages and what your paid search campaigns can do are the same problem wearing two labels, and it is worth auditing your page inventory before February rather than after the automigration has run.
What to check in the account before September
- List every campaign that currently has a campaign-level broad match setting or a legacy automatically created assets configuration. These are the campaigns Phase 1 touches.
- List every Dynamic Search Ads campaign separately. Those are on the February 2027 calendar, not the September one.
- Check any build automation, bulk template, script or third party tool that creates campaigns. Anything that tries to create the blocked configurations has been failing since 3 August.
- Record a clean performance baseline now, per campaign, while everything is still pre-migration. Because Phase 1 rolls out progressively, a baseline taken in late September is worth much less.
- Note the migrated defaults per cohort, especially search term matching on, and decide in advance what your negative keyword coverage needs to look like when query matching widens.
- Check your brand lists on broad match campaigns. The source says they are preserved, which is worth verifying against your own account rather than assuming.
- If you would rather control the timing than receive it, look at the voluntary upgrade path available from September 2026.
For accounts where search drives revenue directly, particularly ecommerce accounts with a wide product range, step 5 is the one that pays for itself. Widening query matching without widening negative coverage is how a migration month turns into a wasted spend month.
What the source did not say
The report does not list the specific API error codes returned when an integration tries to modify a migrated legacy entity. It does not give an exact sunset date beyond around September 2027. It does not say what happens to a campaign that is paused through the September window and enabled afterwards. It does not describe any exception process, any opt out, or any way to keep legacy broad match configurations past the migration. And it explicitly says the changes apply globally with no region-specific carve-outs, so there is no Thailand-specific timeline to wait for.
What this means for Thai marketers
The source is a trade report on a global Google Ads change and says nothing specific about Thailand beyond the absence of regional carve-outs. What follows is reasoning about the implication.
The first implication is about the calendar rather than the feature. September and February are both live commercial periods for a lot of Thai accounts, and the migration lands in the middle of the first one and inside the pre-Songkran planning stretch for the second. A structural change to how campaigns match queries, arriving progressively across a month, will be hard to separate from ordinary seasonal movement unless you write down which campaign migrated on which day. That record is cheap now and impossible to reconstruct later.
The second is about query matching in Thai. Widening how a campaign matches queries has a different shape in a language without spaces between words, where segmentation decides what counts as a match in the first place, and where English and Thai terms are routinely mixed in the same query. Negative keyword coverage built for a narrower matching regime does not automatically hold when matching widens. Reviewing search terms weekly through September, rather than monthly, is the low effort version of protecting the budget while the cohort settles. Teams running Google Ads at meaningful volume should plan for that extra review time before the month starts.
The third is about tooling. Plenty of Thai accounts are built and maintained through Editor and bulk sheets rather than the interface. Because the block covers Editor and the API as well, a template that has worked for years will fail silently in the middle of a build. Test one campaign build before you need to do twenty.
Frequently asked questions
Is this live in Thailand?
Yes. PPC Land reports that the changes apply to Google Ads accounts globally with no region-specific carve-outs, so the 3 August creation block is already in effect for Thai accounts and the September and February windows apply on the same dates. The source does not describe any regional variation in timing.
Do I have to do anything before 1 September?
Nothing is required, because Phase 1 runs automatically whether you prepare or not. What is worth doing is recording a per-campaign baseline before the progressive rollout starts, listing which campaigns hold the affected legacy configurations, and testing any build automation that might be trying to create the blocked settings.
Can I still edit my existing broad match campaigns?
Yes, for now. Existing legacy configurations can still be edited and read through older API versions, and legacy campaigns can be paused or deleted. Only creation of new configurations is blocked. Once legacy expanded dynamic search ads have transitioned into standard ad groups, though, they can no longer be modified and modify attempts trigger API error codes.
What is actually new here, given the 1 September upgrade was already announced?
Three things: the creation gate closed early, on 3 August, ahead of both the 5 August email and the 12 August developer blog post; the settings each migrated cohort lands on are now published; and there is a complete timetable running past September 2026 to a February 2027 Dynamic Search Ads window and an API sunset at around September 2027.
When do legacy settings disappear for good?
API versions released after 1 September 2026 remove the legacy entities entirely, while earlier versions continue to support legacy setups until their scheduled sunset at around September 2027. The source gives that as an approximate date tied to the standard twelve month version lifecycle rather than a fixed day.
If you would rather not read this in a weekly report
The work that makes September readable is all baseline work, and it has to happen before the first campaign converts. If you want a second set of eyes on which campaigns are in scope, what your negative keyword coverage looks like against wider matching, or how your DSA campaigns should be prepared for February, that is a conversation with a deadline attached to it.
