Llevo un tiempo dándole vueltas a algo que me tenía un poco mosqueado y que, cuando até cabos, me hizo soltar un «ostras» en voz alta (sí, hablo solo con el código, no es nada nuevo).
La cosa es así: en varios proyectos he ido metiendo componentes en React dentro de bloques de Gutenberg. Nada demasiado exótico, bloques que muestran datos que vienen de una API, que se actualizan solos, que cambian de versión de vez en cuando… la magia habitual. El problema es que esos cambios pasan sin entrar nunca a la página a darle a «Actualizar». El contenido cambia, pero para WordPress esa página sigue siendo, técnicamente, la misma de hace ocho meses.
Y claro, ahí es donde me salté la típica pregunta: ¿esto le importa a Google? ¿Se está dando cuenta de los cambios?
El lastmod no es decorativo (aunque muchos plugins lo tratan así)
Resulta que sí, le importa. El campo <lastmod> de tu sitemap no es un capricho estético que rellenas para que quede bonito el XML. Google lo usa como señal de prioridad de rastreo: si confía en que tu lastmod refleja cambios reales, lo usa para decidir qué URLs merece la pena revisar antes. Si detecta que le estás mintiendo (el típico plugin que pone la fecha de hoy cada vez que se regenera el sitemap, cambie algo o no), directamente empieza a ignorarlo. Y ojo, no es solo «ignora ese dato», es que pierde confianza en tu sitemap entero como fuente fiable. Bonito lío.
Así que si tus componentes React actualizan datos importantes y tu post_modified en WordPress se queda congelado en la fecha de publicación original… básicamente le estás diciendo a Google «aquí no hay nada nuevo que ver», cuando sí lo hay.
Pero espera, hay una segunda capa del problema
Aquí es donde la cosa se pone más interesante (y más fea). Aunque arregles el lastmod, tu contenido vive en JavaScript. Y Google no indexa el JS igual que indexa el HTML plano.
El proceso va más o menos así: Googlebot rastrea el HTML inicial, lo aparca, y más tarde (podemos hablar de días, a veces más) lo manda a una segunda cola para renderizarlo, ejecutar el JS y ver qué sale. Es lo que se conoce como el rastreo e indexado en dos oleadas. O sea que aunque tu lastmod diga «esto se actualizó ayer», si Google tarda en pasar tu página por el renderizador, seguirá viendo la versión vieja un rato más.
Traducción: no basta con tocar una fecha. Tienes dos frentes:
- Que el lastmod refleje cambios reales (para que te prioricen el rastreo).
- Que el contenido crítico sea legible sin depender 100% del JS, si puedes.
¿Y cómo lo automatizo sin volverme loco?
Nada de entrar a mano a darle a «Actualizar» cada vez, evidentemente, para eso estamos aquí. La idea es enganchar la actualización del post_modified al evento real que dispara el cambio de datos: un webhook, un cron, lo que uses para refrescar la info que consume tu componente.
Algo tipo:
function actualizar_fecha_modificacion_real( $post_id ) {
// Aquí entra tu lógica: se disparó el evento
// que sabes que ha cambiado el contenido de verdad
wp_update_post( array(
'ID' => $post_id,
'post_modified' => current_time( 'mysql' ),
'post_modified_gmt' => current_time( 'mysql', 1 ),
) );
}
Y que tu generador de sitemap (Yoast, AIOSEO o el que lleves) lea de ese campo, que para eso está. Una cosa que me pasó a mi con RankMath es que no saltaba y no se terminaba de refrescar la caché interna que tiene para los sitemaps, así que tuve que forzarlo añadiéndole la llamada a RankMath\Sitemap\Cache::invalidate_storage().
Y no es teoría, esto me lo he encontrado literal en El PC de Adam, donde tengo un par de casos que me sirvieron para entenderlo bien.
Mi experiencia en este tema
Caso 1: la home que nunca cambia (pero sí cambia)
La página de Inicio del PC prácticamente no la toco. Como mucho la actualizo por SEO de vez en cuando, pero contenido en sí que editar, ninguno. El problema es que ahí es donde se muestran los Iconos de escritorio, que es su propio tipo de dato y sí que se actualiza con cierta frecuencia. Es decir: la página en sí está congelada, pero lo que enseña, no. Antes de darme cuenta de esto, mi lastmod de la home llevaba desde 2023 sin moverse mientras el contenido real que veía el usuario cambiaba cada dos por tres.
La solución fue simple una vez até el cabo: cuando se actualiza algún icono de escritorio, lanzo también la actualización de la fecha de modificación de la página de Inicio, aunque yo no haya tocado ni una coma de esa página. Es el mismo principio que lo del componente en React: identificas qué es lo que realmente cambia, y haces que ese evento sea el que dispare el bump de fecha en la página que lo muestra, no al revés.
Caso 2: cuando el changelog se te va de las manos
El otro caso es de los changelogs. Tengo dos: el Changelog del propio PC y el de los changelogs de otros proyectos. Estas páginas llegaron a superar los 81.000 caracteres, todo escrito directamente en el contenido del post. Un despropósito. Y claro, si todo el changelog vive dentro del post, cada línea nueva que añades implica editar esa página gigante, lo cual en teoría sí actualiza el lastmod… pero a costa de tener una página que pesa una barbaridad y que cada vez tarda más en cargar.
Así que hice la migración a su propio tipo de dato personalizado. Cada entrada del changelog es ahora su propia pieza de contenido, y la conecto a la página correspondiente mediante una taxonomía de Tipo de proyecto. Con eso consigo dos cosas: primero, sé exactamente qué taxonomía tiene que hacer bump de fecha en qué página cuando se añade una entrada nueva (porque la relación está explícita, no adivinada). Y segundo, esas fechas de cada changelog no tienen vista de detalle, muestran el contenido paginado, así que la carga sigue siendo rápida aunque el histórico no pare de crecer, y encima siguen siendo útiles para quien las visita.
Vamos, que en los dos casos el patrón es el mismo: deja de pensar en «esta página se actualiza cuando la edito» y empieza a pensar en «esta página se actualiza cuando cambia el dato que realmente muestra». Una vez lo ves así, el resto es cablear el evento correcto.
Ahora bien, cuidado con pasarte de listo. No actualices el lastmod por cualquier tontería. Google es bastante clarito con esto: un cambio en el contenido principal, en los datos estructurados o en los enlaces cuenta como significativo; cambiar una fecha de copyright, no. Si tu componente solo retoca un numerito decorativo sin peso real para el usuario, mejor no tocar nada. Si empiezas a mover el lastmod cada dos por tres sin que cambie nada gordo, vuelves al punto de partida: Google deja de fiarse de ti.
Lo que me llevo de esto
- El lastmod solo sirve si es honesto. Automatízalo desde el evento real que cambia el dato, no desde «cada vez que se regenera el sitemap» ni desde «cada vez que edito la página» (a veces ni siquiera coinciden).
- Actualizar la fecha no garantiza que Google vea el contenido nuevo al momento, porque el renderizado de JS va por su cuenta y a su ritmo.
- Si tienes datos muy dinámicos y te importa que se vean rápido, plantéate meter esa info también en JSON-LD servido en el HTML inicial, que ese Google lo lee sin esperar a renderizar nada.
Esperemos que esto ayude a mejorar mi relación con Google que, hace unos meses, me odió y me eliminó de la faz de la tierra (su buscador).