Hola — preguntaste dos cosas en el mismo mensaje: por qué la sincronización de tus tres dominios se activó una hora más tarde de lo que configuraste, y si deberías simplemente pasar tu equipo de optimización a modo autónomo ya que estás en ello. Resulta que son la misma conversación, así que déjame abordarlas juntas en lugar de dar dos respuestas separadas.
Empecemos por la forma del sistema, porque explica ambos problemas. Cada equipo aquí funciona en uno de tres modos — una vez, manual, autónomo — y "autónomo" no es un nivel separado y más inteligente. Es una ejecución manual con una programación adjunta y el ciclo dejado abierto. Mismo agente, mismas barreras de seguridad, todo igual, solo que un programador decide cuándo pulsar el botón en lugar de tú. Una vez que eso queda claro, el resto encaja.
Por qué tu sincronización y tu programación viven en lugares distintos
| Programar | Qué impulsa |
|---|---|
| Sincronización de datos | La extracción diaria de datos de Search Console / Analytics / tienda hacia tus paneles — el combustible para todo lo demás |
| Ejecuciones de agentes | Ejecuciones de optimización automáticas tras cada sincronización, barridos de investigación que rellenan tu cola de resúmenes, y cualquier equipo que dejes en funcionamiento |
Encontrarás la configuración de sincronización junto a cada dominio y la configuración de ejecución junto a cada equipo — no en una única página de automatización combinada, lo cual sé que se siente raro la primera vez que la buscas. Sin embargo, es deliberado. Tu cadencia de sincronización trata sobre los datos: qué tan rápido se actualiza realmente Search Console. Tu cadencia de ejecución trata sobre el equipo: qué tan rápido quieres que ese equipo actúe sobre lo que ve. Son preguntas distintas con respuestas distintas, y una versión anterior de esta plataforma las juntaba en una sola página, lo que significaba que tocar cualquiera de las dos te obligaba a pensar en ambas. Separarlas fue la solución.
Algo que vale la pena saber antes de programar nada para tu equipo de optimización: una ejecución que se activa según una programación y una que inicias manualmente producen exactamente el mismo objeto una vez en marcha. Mismo informe, misma entrada en el historial, mismo costo en créditos, misma capacidad de abrirla a mitad de ejecución y ver qué está haciendo. He visto a gente asumir que las ejecuciones programadas son una versión más ligera y reducida para ahorrar costo — no lo son. Si no confiarías en una ejecución que activaste tú mismo, no la pongas en un temporizador.
Qué salió mal realmente con tu programación migrada
Mencionaste haber pegado la hora directamente desde tu herramienta anterior — 14:00 UTC, pensada para caer a las 2pm tu hora. Esa es exactamente la trampa. Nuestro campo de hora quiere tu reloj local, no UTC; muestra la zona horaria que detectó justo debajo para que nunca tengas que adivinar. Pega un valor UTC ahí y se trata como si ya fuera local, se convierte a UTC una segunda vez, y terminas con una ejecución a las 4pm en lugar de las 2pm. La solución para tus otros dos dominios: vuelve a introducir las horas en local, ignora cualquier valor UTC que te haya dado la herramienta anterior.
La hora por la que realmente preguntaste — la sincronización cayendo a las 7am en lugar de las 6 — es un artefacto del horario de verano, y conviene entenderlo bien una vez en lugar de perseguirlo cada marzo y octubre. Configura una sincronización a las 6:00 en Berlín en enero y la plataforma almacena las 5:00 UTC, porque Berlín está en UTC+1 en invierno. Un programador ingenuo simplemente seguiría activándose a las 5:00 UTC para siempre. Cuando llega el cambio de horario de verano, Berlín pasa a UTC+2, y ese mismo tic de las 5:00 UTC ahora cae a las 7:00 hora local — silenciosamente, sin error, solo números un par de horas más tarde de lo esperado. Nosotros convertimos en el momento de la entrada según el desfase actual en lugar de eso, así que una programación a las 6:00 significa las 6:00 en el reloj de pared el día que se ejecuta, con o sin horario de verano. Si sigues viendo un desfase de una hora después de volver a introducir la hora en local, vale la pena abrir un ticket de soporte — no debería ocurrir con una programación recién introducida.
Configurando la cadencia real
- Sincronización: diaria, no más rápida. Los datos de Search Console llegan con dos o tres días de retraso en el mejor de los casos. Sincronizar cada hora en tus tres dominios no te dará cifras más recientes, solo llenará el historial de sincronización con tareas que obtienen una y otra vez los mismos datos desfasados.
- Optimización: encadenada a la sincronización, no con su propio horario. Esta es la parte más importante de lo que estás a punto de programar. Si la sincronización termina a las 6:02 en lugar de a las 6:00 porque la API de Google fue lenta esa mañana, la ejecución de optimización se dispara justo después, sobre esos datos frescos; no espera su propia franja de las 6:15 arriesgándose a ejecutarse con los datos de ayer si la sincronización se alargó. Dos relojes independientes suenan bien hasta el día en que se desincronizan.
- Investigación: semanal, dimensionada a lo que tu equipo de contenido pueda realmente procesar. Los briefs no caducan de un día para otro, y los briefs sin revisar que se acumulan en una cola siguen consumiendo créditos aunque nadie actúe sobre ellos. Si tu equipo puede aprobar de forma realista cuatro o cinco briefs por semana, ajusta el barrido para producir esa cantidad; un barrido diario que alimenta un hábito de revisión semanal solo genera un backlog que nadie llega a procesar.
- Anuncios, cuando llegues a ese equipo el próximo mes: sin horario, a propósito. Los borradores se generan bajo demanda; nada se publica ni se gasta sin ti. El razonamiento está en el argumento en contra del gasto en piloto automático, pero, en resumen, un error de programación en una sincronización de contenido es una molestia menor, y un error de programación en el gasto publicitario es una factura. No esperes que la configuración de ese equipo se parezca a la que estás definiendo hoy.
Entonces, ¿deberías activar la optimización en modo autónomo?
Esta es la respuesta honesta, y es menos dramática de lo que la pregunta sugiere: activarla cambia menos de lo que piensas. El agente no adquiere ninguna capacidad nueva que no tuviera cuando lo ejecutaste tú mismo; las mismas barreras de confirmación ante cualquier acción destructiva, los mismos juicios, todo igual. Lo único que cambia es quién decide cuándo actúa. Ahora mismo, eres tú. Con un horario, es el reloj.
La pregunta que en realidad me haría, en lugar de "¿es segura la opción autónoma?", es esta: ¿te sientes cómodo con que el resultado de tus últimas tres ejecuciones manuales de optimización se repita, sin supervisión, con la periodicidad que definas? Si la respuesta es sí, estás listo, actívala. Si solo te sientes cómodo porque revisaste personalmente cada una de esas tres ejecuciones antes de que ocurriera algo posterior, esa es una señal real, y significa que seguir en modo manual un poco más es la decisión correcta, no una falta de decisión.
Dado el punto en el que estás —tres dominios recién migrados, horarios aún sin asentar del todo—, yo esperaría unos días más antes de pasar a modo autónomo. Corrige los dos horarios que faltan, comprueba que la sincronización de mañana se ejecuta a la hora correcta, ejecuta la optimización manualmente dos o tres veces más para haber visto de principio a fin lo que hace. Después, prográmala. Las preguntas sobre la periodicidad se responden mucho más fácilmente con una ejecución real delante que en abstracto, y no cuesta nada esperar una semana para conseguir eso.
