La frescura es una propiedad de la búsqueda, y una actualización es un cambio en la página, no en su fecha. Google tiene sistemas que favorecen páginas recientes en una parte de las búsquedas, y sus propios ingenieros describen un sesgo incorporado a favor de las antiguas. El reflejo habitual en SEO, subir la fecha según un calendario, no le dice a Google nada que pueda verificar. Lo sabemos porque nuestro propio sitemap hizo exactamente eso durante meses.
Qué significa la frescura de consulta (QDF)
En su declaración en el juicio antimonopolio US v. Google, Pandu Nayak dio tres ejemplos, citados en un análisis de Hobo del 5 de octubre de 2026. Un aficionado al deporte quiere páginas de esta mañana. Quien compra un portátil quiere análisis del año de modelo correcto, no de hoy. Quien planea una cena con pavo puede estar mejor servido con una receta de hace diez años.
El tercer caso es el que los dueños de WordPress se saltan. La frescura no es un bonus que cobra cada página. Para muchas búsquedas la respuesta correcta es la página más antigua y asentada, y “actualizarla” solo puede empeorarla. Antes de tocar una entrada, conviene preguntar si su búsqueda espera novedad.
De dónde viene query deserves freshness
El nombre es más antiguo que cualquier filtración o juicio. El 3 de junio de 2007, Saul Hansell lo describió en The New York Times, en un perfil de Amit Singhal, a quien el periódico llamó el maestro del algoritmo de ranking de Google. Según el artículo, Google prefería hasta entonces páginas con antigüedad suficiente para haber atraído enlaces, y Singhal empezó a sospechar que el equilibrio fallaba cuando una búsqueda de Google Finance no encontraba el nuevo servicio de cotizaciones bursátiles del propio Google.
La respuesta de su equipo, según la relata Hansell, fue un modelo matemático que intenta determinar cuándo los usuarios quieren información nueva y cuándo no. Se llamó QDF, por query deserves freshness. Juzgaba si un tema estaba caliente a partir de dos señales: sitios de noticias y blogs que escriben activamente sobre él, y el propio flujo de búsquedas de Google, que Singhal consideraba el mejor indicador. Su ejemplo era un apagón en Nueva York, en el que los primeros artículos aparecen a los 15 minutos y las búsquedas a los dos segundos.
Dos detalles de 2007 siguen contando. Singhal explicó a sus colegas que cambiar sin más las fórmulas para mostrar más páginas nuevas daba resultados de peor calidad la mayoría de las veces, así que la frescura nunca se pensó como una preferencia general por lo nuevo. Y el disparador era la demanda en torno a un tema, no la edad de una página concreta. Una entrada de WordPress no calienta su búsqueda cambiando su propia fecha.
Qué búsquedas tienen en cuenta los sistemas de frescura de Google
Hoy Google documenta la idea en su guía de sistemas de ranking, en plural: varios sistemas “query deserves freshness” diseñados para mostrar contenido más reciente en las búsquedas donde se esperaría. La guía da dos ejemplos. Quien busca una película recién estrenada probablemente quiere críticas recientes y no artículos de cuando empezó la producción. Una búsqueda de “terremoto” suele devolver material sobre preparación, pero tras un terremoto reciente pueden aparecer noticias y contenido más fresco.
Los dos ejemplos describen un cambio en lo que necesita quien busca, provocado por un hecho ajeno a la página. Ninguno describe una página que mejoró por recibir una fecha nueva. Encaja con la receta de pavo de la declaración de Nayak: un sistema hecho para detectar demanda de novedad no tiene nada que premiar cuando esa demanda no existe. Para un sitio WordPress, la pregunta útil es cuáles de sus búsquedas se comportan alguna vez como “terremoto”. Para la mayoría de las páginas de servicios y de las guías prácticas la respuesta es ninguna, y en esas páginas la fecha es un registro, no una palanca.
Por qué Google necesita un sistema de frescura
La razón es mecánica. Google ordena en parte por lo que los usuarios clicaron antes, y Nayak describió el efecto secundario:
El problema de la frescura y los clics es que los clics se acumulan con el tiempo, lo que significa que las páginas más antiguas, potencialmente obsoletas, tienden a tener más clics que las páginas frescas
Pandu Nayak, Google, Hobo Web, traducción propia
Una página nueva arranca sin clics y una vieja acumula años. En las búsquedas donde la frescura cuenta, Google tiene que compensarlo. En todas las demás, los clics acumulados hacen aquello para lo que se construyeron.
Para quien gestiona un sitio salen dos cosas. Un sistema de frescura existe para elevar páginas realmente recientes, así que está hecho para resistir señales baratas. Y una página fresca sin clics arranca con una desventaja que una fecha nueva no quita.
Qué dice Google sobre cambiar fechas
Hobo cita un tuit de John Mueller del 5 de febrero de 2022, borrado desde entonces:
Cuando escribas algo nuevo, o cambies algo existente de forma significativa, entonces cambia la fecha. Cambiar la fecha sin hacer nada más es solo ruido e inútil.
John Mueller, Google, Hobo Web, traducción propia
El tuit ya no está, así que es discurso indirecto y no documentación. El mismo artículo cita una pregunta de las directrices de Google sobre contenido útil:
¿Estás cambiando la fecha de las páginas para que parezcan recientes cuando el contenido no ha cambiado de forma sustancial?
Google, guía sobre contenido útil, Hobo Web, traducción propia
Conviene releer la primera frase del consejo de Mueller. No dice que nunca se cambie la fecha. Dice que se cambie cuando se escribió algo nuevo o se modificó algo de forma significativa. Una fecha es una afirmación, y la regla es que la afirmación sea verdadera.
Esa pregunta no solo llega de segunda mano. Sigue en la propia guía de Google sobre crear contenido útil, fiable y centrado en las personas, actualizada el 5 de octubre de 2026, seguida de una segunda pregunta dirigida al mismo reflejo a escala de todo el sitio:
¿Añades mucho contenido nuevo o eliminas mucho contenido antiguo principalmente porque crees que ayudará al ranking general de tu sitio haciéndolo parecer “fresco” de alguna manera? (No lo hará.)
Google Search Central, Crear contenido útil, traducción propia
La respuesta entre paréntesis es de Google, no nuestra. Cubre la publicación masiva y la poda masiva hechas para aparentar frescura, que es la versión de sitio entero de subir una fecha.
El contenido evergreen necesita actualizarse
Hobo recoge otros tweets borrados de Mueller, y uno de ellos sirve a quien tenga guías que no necesitan cambiar. Según Hobo decía:
Si es evergreen, entonces por definición no necesitas cambiarlo. No hace falta hacer nada especial. Mantén las fechas, hazlo excelente.
John Mueller, Google, Hobo Web, traducción propia
Como el tweet anterior, es un testimonio indirecto que no se puede confirmar. Pero encaja con lo que dijo Nayak sobre la receta de pavo. Una guía estable conserva su fecha original y no tiene por qué perderla. La tentación de “refrescarla” cada trimestre viene de la idea equivocada de que Google premia el movimiento. Premia la respuesta correcta para la búsqueda, y para muchas búsquedas esa respuesta ya está escrita.
Filtración de Content Warehouse API y fechas de frescura
Hobo va más lejos y superpone las declaraciones a nombres de campos de la documentación filtrada de la Content Warehouse API: fechas separadas para la firma, para el patrón de la URL y un sello de la última actualización significativa. El cuadro es ordenado, y es una inferencia del autor. Nadie en Google ha confirmado que esos campos muevan el ranking de frescura como se describe. Las declaraciones y las directrices públicas respaldan el principio, y la historia a nivel de campos es una lectura de una filtración.
El consejo práctico sobrevive sin ella. Una página cuya fecha se movió mientras el texto apenas cambió parece, a cualquier sistema que compare versiones, una página con una promesa que no cumplió. Sea un campo con nombre o una comparación general, la táctica no necesita una filtración para ser mala apuesta.
Misma fecha lastmod en todas las URL del sitemap
El 24 de agosto de 2026 medimos cinco de nuestros sitemaps en producción. En cada uno, todas las entradas tenían exactamente un valor de lastmod, la fecha del build. La integración del sitemap calculaba la fecha actual una vez y sellaba con ella todas las URL. Google programa nuevas visitas por lastmod solo mientras el valor siga siendo verificablemente cierto. Un sitio en el que cada URL declara un cambio en cada build enseña al rastreador a ignorar el campo. Las fechas del último rastreo en páginas de la muestra iban de tres semanas a tres meses atrás.
Es el patrón fecha sin cambio, construido por nosotros, a escala de todo el sitio y sin intervención humana. La corrección toma la fecha de updatedDate, o de pubDate si falta, y desde el 29 de septiembre una URL sin fecha de contenido conocida no recibe lastmod, porque la ausencia de fecha es mejor que una fecha falsa.
Medido hoy, el sitemap del blog en inglés lista 329 URL con 100 fechas de lastmod distintas. Es la forma de un sitio que cambia en momentos distintos. No es un resultado limpio. 130 de esas URL comparten un día, el 22 de septiembre, y no hemos auditado si esas ediciones añadieron contenido. Si no, hemos reconstruido el problema a menor escala, un editor cada vez.
Qué considera Google un cambio significativo para lastmod
La documentación de sitemaps de Google fija el listón en dos frases. Google usa el valor de lastmod si es coherente y verificablemente exacto, por ejemplo al compararlo con la última modificación de la página, y el valor debe reflejar la fecha y hora de la última actualización significativa. Los ejemplos que da: un cambio en el contenido principal, en los datos estructurados o en los enlaces de la página suele ser significativo, la actualización de la fecha de copyright no lo es. La misma página dice que Google ignora priority y changefreq, así que esos dos campos tampoco transmiten ninguna señal de frescura.
Esa definición es más estrecha que lo que WordPress guarda como modificación y más amplia de lo que muchos editores suponen. Un enlace interno nuevo o un dateModified corregido en el schema cuentan. El año del pie de página que cambia el tema, un nuevo guardado o un plugin que reescribe entradas al activarse no cuentan. “Verificablemente” es la palabra que hace el trabajo: Google puede comparar la fecha declarada con lo que obtuvo la última vez, y nuestro sello con la fecha del build suspendió esa comparación en todas las URL a la vez.
Cómo comprobar las fechas lastmod del sitemap
Sin plugin ni panel, el sitemap se cuenta con una línea. Sustituya la dirección por la suya:
curl -s https://example.com/sitemap-posts.xml | grep -o '<lastmod>[^<]*' | sort | uniq -c | sort -rn | headSi la salida es una sola línea con el total de URL, el sitemap declara que todo cambió el mismo día. Si un día concentra una parte grande, pregunte qué se editó ese día. Los plugins de SEO suelen pasar post_modified a lastmod, y WordPress lo actualiza en cada guardado, también en una edición masiva de categorías o en un re-guardado para disparar otro plugin.
Cuánto tarda Google en volver a rastrear una página
En un evento Search Central Live, Gary Illyes mostró tiempos internos que Barry Schwartz recogió en Search Engine Roundtable. El refresco de una URL conocida tarda típicamente unos 30 días, en el peor caso semanas o nunca. El procesamiento del sitemap tarda unas 24 horas, hasta 14 días o nunca. Illyes añadió una salvedad:
ten en cuenta que esto fue un ejercicio para ver si el público podía identificarse con las cifras que extrajimos internamente y pusimos en esas diapositivas.
Gary Illyes, Google, Search Engine Roundtable, traducción propia
Son órdenes de magnitud, no garantías. Aun así cambian cómo evaluar una actualización. Quien edita una entrada el lunes y mira el resultado el miércoles no ha medido nada. Y si el refresco típico tarda un mes, un lastmod honesto es la única forma de decirle a Google que esta página merece una visita antes.
Qué cuenta como actualización en WordPress
Una actualización que merece fecha nueva es:
- una cifra, precio o versión que cambió, con la frase que la rodea
- una sección añadida porque el tema creció
- una recomendación invertida ante nuevas pruebas
- un plazo que venció, con el tiempo verbal reescrito
No es actualización:
- volver a guardar para disparar un plugin
- reordenar párrafos o cambiar una imagen
- una edición masiva de metadatos en muchas entradas
- releer la página y no encontrar nada que cambiar
Para el último caso usamos un campo aparte, lastVerified, separado de updatedDate: una verificación es un hecho que vale la pena registrar, pero no es un cambio de contenido. Los textos con fecha límite exigen el trato más estricto, porque una entrada escrita como consejo antes de una fecha se vuelve falsa ese día, y un lastVerified reciente no detecta el futuro que sigue en el texto.
Cómo elige Google la fecha que muestra en los resultados
La fecha bajo un resultado de búsqueda es un asunto distinto de lastmod. La guía de Google sobre fechas dice que no depende de un único factor de fecha, porque todos pueden fallar, y que mira varios para estimar cuándo se publicó o se actualizó de forma significativa una página. Tampoco garantiza que se muestre ninguna fecha.
La guía pide una fecha visible para el usuario, destacada y etiquetada con un texto como “Publicado” o “Última actualización”. En los datos estructurados recomienda un subtipo de CreativeWork, como Article o BlogPosting, con datePublished y/o dateModified. La fecha visible y el valor estructurado deben coincidir, la zona horaria, si se indica, debe ser correcta, y la fecha tiene que describir la publicación o la actualización de la página, no una fecha futura ni la fecha de un hecho del que habla la página. Si Google sigue eligiendo la fecha equivocada, la guía sugiere quitar algunas de las otras fechas de la página.
En WordPress esto significa que tres sitios llevan la misma afirmación: la línea visible “actualizado el”, el dateModified del schema que imprime el plugin de SEO y el lastmod del sitemap. Si uno de ellos se mueve en cada guardado y los otros no, la página se contradice. Si los tres se mueven en cada guardado, la página es coherente y sigue siendo falsa. La corrección es la que aplicamos al sitemap: una fecha de contenido, cambiada solo por un editor que cambió el contenido, y todas las salidas leen esa fecha.
Cuándo cambiar la fecha de actualización de un artículo
- Abrir la versión anterior junto a la actual. Si la diferencia es solo espacio, marcado u orden, parar.
- Preguntar si la búsqueda espera novedad. Si no, una fecha sin cambios es honesta y segura.
- Si el cambio es real, escribir en el texto qué cambió, cerca del inicio o del final, para que una persona vea el motivo y no solo la fecha.
- Dejar que
lastmodsiga la fecha del contenido y nada más. Revisar el propio sitemap, no los ajustes del plugin, y contar los valores distintos.
La frescura se gana con un cambio que un lector o un rastreador pueda ver. Una fecha solo puede registrarlo, y una fecha que no registra nada es la señal más barata que un sitio puede enviar y la primera que Google aprende a ignorar.
