Google migra campañas de Search a AI Max durante todo septiembre, y a las que venían de ACA les deja prendida la reescritura de copy
El 1 de septiembre de 2026 Google empezó a mover, de forma automática, las campañas de Search que todavía usan Broad Match a nivel de campaña o Automatically Created Assets standalone hacia AI Max. No hay un botón que apretar ni un aviso por campaña antes de que ocurra. La migración se despliega de forma progresiva durante todo el mes, así que una cuenta puede amanecer un día de septiembre con algunas campañas ya migradas y otras todavía no, sin que nada en la interfaz lo señale como un evento.
Esto conecta con algo que este blog viene señalando desde que Google empezó a escribir las descripciones de los Shopping ads con IA: cada vez es más común que el texto publicado en una cuenta no lo haya escrito quien la paga. Con esta migración esa dinámica se extiende a Search, y depende de un detalle de configuración que la mayoría de las cuentas nunca miró a propósito.
Dos puntos de partida, dos resultados distintos
No todas las campañas migradas terminan igual, y ahí está la parte que conviene revisar con atención.
Las campañas que venían con Campaign-level Broad Match quedan con Text Customization apagado, Final URL Expansion apagado, y Search Term Matching prendido por default. Las listas de marca (las inclusiones y exclusiones que una cuenta haya configurado) se preservan y se mueven junto con la campaña, así que ese control no se pierde en el traspaso.
Las campañas que venían de Automatically Created Assets standalone quedan distintas: Text Customization prendido por default, Final URL Expansion apagado, y Search Term Matching prendido por default. Text Customization es la función que le da a Google permiso para reescribir o adaptar el texto del anuncio. En este segundo grupo, entonces, la migración no solo cambia el motor de matching por debajo: deja activa, sin que nadie la haya pedido, la reescritura de copy. Es el mismo movimiento de fondo que ya se vio con la segmentación por idioma en Search: un control que antes dependía de una decisión explícita del anunciante pasa a resolverse solo, del lado de la plataforma.
Google enmarca el movimiento como una migración "in-place a settings equivalentes" pensada para minimizar volatilidad de performance. Es una descripción razonable de la intención, pero no dice si el resultado es efectivamente equivalente en cada cuenta, y esa evaluación queda del lado de quien la gestiona.
Cómo saber si ya te tocó
Google publicó una query de GAQL para detectar campañas migradas, y vale la pena correrla en cada cuenta antes de asumir que septiembre todavía no llegó.
La query, tal como Google la publicó, selecciona campaign.id, campaign.name, campaign.aca_migration_date_time y campaign.broad_match_migration_date_time desde campaign, filtrando por las dos fechas de migración mayores a '1970-01-01 00:00:00'.
Hay un detalle en cómo está armada esta query que conviene señalar porque cambia lo que efectivamente detecta: las dos condiciones están unidas con AND, así que solo devuelve campañas que migraron por los dos motivos a la vez. Una campaña que migró solo por ACA, o solo por broad match, no va a aparecer en ese resultado tal como está escrito. Para cubrir el universo completo hace falta correr las dos condiciones por separado, no juntas. No es una acusación de que Google se haya equivocado ni hay forma de saber si fue intencional; es simplemente lo que la query, tal cual está publicada, devuelve.
Lo que ya no se puede crear, y lo que sigue vivo un tiempo más
Desde el 3 de agosto de 2026, antes de que arrancara la migración, quedó bloqueado crear configuraciones nuevas de Campaign-level Broad Match o de ACA standalone legacy. El bloqueo aplica parejo en la interfaz, en Google Ads Editor y en todas las versiones de la API: no hay vía alternativa para configurar estas entidades desde cero.
Las versiones de la API publicadas después del 1 de septiembre de 2026 eliminan por completo las entidades legacy; ni siquiera aparecen como opción. Las versiones ya publicadas antes de esa fecha las siguen soportando hasta su sunset normal, que cae aproximadamente en septiembre de 2027 y ahí sí se eliminan de forma permanente. Cualquier integración que dependa de estos objetos tiene, entonces, una ventana concreta para migrar, más allá de lo que le pase a cada campaña dentro de la interfaz. Es el mismo tipo de reloj que ya corre para cualquier cuenta que reporte con exportaciones propias, como quedó documentado con los cambios en los reportes de performance de Merchant Center: un histórico que la plataforma puede reescribir o discontinuar deja de ser confiable si nadie lo guardó antes del corte.
La excepción que se corrió a 2027
Dynamic Search Ads queda afuera de esta ronda. Google reprogramó su migración para febrero de 2027, entre el 1 y el 28, con banners de aviso previo apareciendo en la interfaz durante septiembre de 2026 y una notificación oficial recién el 15 de enero de 2027. Quien gestiona campañas de DSA no tiene, por ahora, nada que revisar en este frente específico, más allá de tomar nota de que la ventana ya está fijada.
Para quién es esto
Esto le importa, primero que nada, a cualquiera que gestione campañas de Search Ads en cuentas con más de un año de antigüedad, porque ahí es más probable encontrar Campaign-level Broad Match o ACA standalone configurados hace tiempo y sin revisión reciente. Vale la pena correr la query de detección (las dos condiciones por separado, no la que publicó Google tal cual) y anotar qué campañas ya migraron y con qué configuración quedaron.
Le importa en particular a quien gestiona cuentas que venían de ACA, porque ahí Text Customization queda prendido por default: Google puede estar reescribiendo el copy de anuncios que salen a producción sin que haya habido una decisión explícita de permitirlo. Revisar esa opción y decidir activamente si se deja prendida o se apaga es la tarea concreta de este mes.
Le importa menos, por ahora, a quien gestiona Dynamic Search Ads: esa migración está corrida a 2027 y todavía hay tiempo para planificarla con calma.
Y le importa a cualquier equipo que opere cuentas vía scripts o integraciones propias, porque el reloj de la API legacy corre en paralelo al de la interfaz, con un sunset distinto (septiembre de 2027) que conviene anotar aparte. Ese mismo tipo de equipo es el que ya está lidiando con cómo las plataformas de ads empezaron a hablar MCP: si la cuenta ya es operable por agentes vía API, el objeto legacy que esos agentes leen o escriben tiene que estar migrado antes de que la API deje de sostenerlo.
Fuentes
Desarrollado con IA. Revisado por humanos. Si algún dato envejece mal, culpen al ecosistema, no a nosotros.