Auditoría de schema muerto: los datos estructurados que mantienes y Google ya no usa

Abres el código fuente de un tutorial publicado en 2021, bajas hasta el final y ahí sigue: un bloque JSON-LD de tipo HowTo con doce pasos, cada uno con su imagen, su texto y su nombre. Alguien lo montó con cariño. El plugin lo regenera en cada carga. Y Google lleva desde 2023 sin hacer absolutamente nada con él.

Esto pasa en más sitios de los que parece, porque el marcado estructurado tiene una propiedad incómoda: cuando deja de servir, no falla. No sale un error en consola, no se rompe la maqueta, no protesta nadie. Simplemente se queda ahí, generando bytes y trabajo de mantenimiento para un consumidor que ya no existe.

Las fechas que conviene tener a mano

Estas son las retiradas que más marcado huérfano han dejado por ahí:

• data-vocabulary.org: Google avisó a principios de 2020 y dejó de admitirlo en abril de ese año. Si tu web arrastra plantillas antiguas con itemtype apuntando a data-vocabulary, ese marcado lleva seis años sin efecto.
• HowTo: en agosto de 2023 Google anunció que dejaba de mostrar estos resultados. No hubo periodo de gracia ni sustituto. El tipo sigue existiendo en schema.org y sigue validando, que es justo lo que confunde a todo el mundo.
• FAQ: mismo anuncio, mismo día. Google restringió la presentación a webs de administraciones públicas y de salud reconocidas. Para el resto de sitios, el marcado es válido y no pinta nada en resultados.
• Sitelinks searchbox: el buscador que aparecía dentro del resultado de marca. Google anunció su retirada en otoño de 2024 y a partir de finales de noviembre de ese año el marcado dejó de tener efecto. Google decidió mostrarlo o no según sus propios criterios, sin mirar el JSON-LD.
• Y los clásicos del museo: rel=»author» con las fotos de perfil en resultados murió en 2014, y el marcado de publisher asociado a Google+ se fue con la propia red social.

Añade una herramienta a la lista de bajas: el viejo Structured Data Testing Tool dejó de ser el validador oficial de Google y hoy vive como validador de schema.org. Sigue siendo útil para comprobar sintaxis, pero validar ahí no te dice nada sobre lo que Google va a mostrar. La prueba de resultados enriquecidos es la que responde a esa pregunta, y solo evalúa los tipos que Google admite hoy.

Lo que sigue vivo en 2026

Para no dejar la sensación de que esto es un cementerio, el marcado que Google sí procesa para presentar resultados enriquecidos sigue siendo bastante amplio: producto con precio y disponibilidad, reseñas y valoraciones, migas de navegación, artículo, receta, vídeo, evento, oferta de empleo, ficha de negocio local, organización, software, libro, páginas de preguntas y respuestas de usuarios y los tipos de foro y perfil que Google incorporó a partir de 2023.

Con un matiz que ahorra discusiones: marcar bien te hace elegible, no te garantiza nada. Y la fuente de verdad para tu sitio no es la documentación, son los informes de mejoras de Search Console. Si un tipo que estás inyectando no aparece como informe propio en tu propiedad, Google no lo está procesando para ti. Ese dato vale más que cualquier artículo, incluido este.

El coste que nadie apunta en ninguna parte

El argumento habitual para no tocar nada es que el marcado sobrante no hace daño. Es verdad que no penaliza, pero gratis tampoco sale:

• Peso. Un HowTo con quince pasos e imágenes se va con facilidad a varios kilobytes por página, y suele convivir con otro bloque que repite la mitad de los datos porque el tema y el plugin no se hablan.
• Trabajo de servidor. Muchos plugins de WordPress construyen ese JSON-LD en cada carga, con consultas a la base de datos para sacar imágenes y campos personalizados que después nadie lee.
• Mantenimiento fantasma. Cada migración, cada cambio de plantilla y cada actualización de plugin obliga a revisar que ese bloque siga saliendo bien. Se han dedicado tardes enteras a arreglar avisos de campos incompletos en tipos que Google ya no mira.
• Contradicciones. Dos bloques que declaran precios distintos para el mismo producto es un problema real. Cuantos más bloques inútiles arrastras, más fácil es que uno de ellos se quede desactualizado y ensucie a los que sí importan.

Cómo encontrar el marcado que nadie consume

No hace falta gran cosa. Un script de unas treinta líneas en Python resuelve el inventario:

• Lee las URLs del sitemap XML (incluidos los sitemaps índice) y quédate con las que tengan respuesta 200.
• Descarga el HTML con requests, con una pausa entre peticiones para no castigar tu propio servidor.
• Extrae todos los script con tipo application/ld+json usando BeautifulSoup y pásalos por json.loads, tolerando fallos: hay plugins que generan JSON inválido y ese hallazgo por sí solo justifica el rato.
• Recorre el árbol, incluido el @graph y los objetos anidados, y acumula cada @type en un contador junto con el tamaño en bytes del bloque.
• Cruza el resultado contra la lista de tipos retirados: HowTo, FAQPage si no eres administración o entidad sanitaria, SearchAction dentro de WebSite, y cualquier resto de data-vocabulary.

La salida que interesa es una tabla con tres columnas: tipo, número de URLs donde aparece y kilobytes totales que suma en todo el sitio. Cuando ves que HowTo pesa varios megas repartidos entre trescientas páginas, la conversación con quien defiende dejarlo «por si acaso» se acaba sola.

Si quieres una comprobación rápida antes de montar nada, busca en el HTML de una plantilla las cadenas HowTo, FAQPage y SearchAction. Con que aparezcan en la plantilla base ya sabes que están en todo el sitio.

Qué borrar y qué dejar quieto

El sitelinks searchbox se va sin discusión: no lo consume nadie y ocupa. El HowTo también, salvo que lo estés usando para alimentar algo tuyo, un feed interno o una app, en cuyo caso lo sabrás perfectamente. Con FAQ hay más matiz, porque el bloque de preguntas visible en la página sigue teniendo sentido para quien lee; lo que sobra es el JSON-LD que lo acompaña si no encajas en las excepciones.

Sobre el argumento de que los modelos de lenguaje leen ese marcado y por eso conviene mantenerlo todo: no hay confirmación pública de que estos tipos concretos influyan en cómo los sistemas de IA de Google interpretan una página. Puede que ayude, puede que no. Lo que sí es medible es lo que cuesta mantenerlo, y decidir con eso me parece más sensato que decidir con una corazonada sobre lo que hará un modelo.

Nosotros hemos acabado en un punto intermedio: un único bloque @graph por página, escrito a mano en la plantilla, con organización, migas de navegación, artículo o producto según el caso, y nada más. Todo lo que un plugin activa por defecto «porque viene incluido» tiende a envejecer mal, y el día que Google retira otro tipo nadie se entera hasta que alguien abre el código fuente por casualidad, tres años después.