Publicar es el paso donde los errores chicos se vuelven públicos, y los más baratos de cometer son una propiedad faltante y una fecha equivocada. El 2026-10-03 el agente de schema de nuestra auditoría puntuó los datos estructurados de este sitio en 78 sobre 100, con un grafo maduro y dos propiedades requeridas ausentes. Ese mismo día, otras dos corridas de claude-seo marcaron un post nuestro por llevar una fecha de publicación siete días en el futuro. Esa fecha salió de nuestro propio producto: el artículo estaba planificado para el 2026-10-10 en el calendario, la entrega escribió ese día planificado en el archivo, y el post salió en vivo el 2026-09-28. Esta clase recorre los dos hallazgos y después la parte de publicar que ninguna herramienta hace por vos.
Un validador y un resultado enriquecido preguntan cosas distintas
Un marcado válido es un marcado que un parser acepta, y un marcado elegible es un marcado que Google puede convertir en una función. Un bloque puede pasar la primera vara y quedar bastante abajo de la segunda, porque un resultado enriquecido tiene una lista de propiedades requeridas y tu marcado las lleva o no las lleva. Nuestro BlogPosting parseó limpio, con headline, datePublished, dateModified, author como referencia a una Person y publisher como referencia a una Organization, todos bien tipados.
Y seguía sin ser elegible para el resultado enriquecido de artículo, porque faltaba image en todos los posts del sitio. Una propiedad ausente, y el blog entero quedó afuera de una función para la que calificaba en todo lo demás. Leé la lista de requeridas del resultado que querés antes de puntuar tu propio marcado, y tomá todo lo demás que te diga el validador como contexto.
Nuestro propio grafo sacó 78 sobre 100
La auditoría encontró datos estructurados en siete plantillas de página, y la forma era la buena noticia. Organization, WebSite y SoftwareApplication con un Offer en la home; WebPage y BreadcrumbList en precios; WebPage, FAQPage y BreadcrumbList en una página de feature; BlogPosting, Organization, Person y FAQPage en el post; una WebApplication con un Offer en una herramienta gratis. Todos los @context apuntaban a la URL canónica de schema.org, todas las URL eran absolutas, todas las fechas eran ISO 8601, y las entidades estaban cruzadas por @id, así que un grafo describía un sitio.
Tres cosas le pusieron techo al puntaje. BlogPosting no tenía image y los posts no tenían BreadcrumbList, mientras que las otras cuatro plantillas sí. SoftwareApplication y WebApplication no tenían aggregateRating ni review, que el resultado enriquecido de Software App requiere. Y FAQPage, presente en cuatro plantillas, ya no gana nada en la SERP.
Algunos huecos son una línea de código y otros necesitan datos que no tenés
Partir la lista de huecos en dos es el primer movimiento útil, porque las dos mitades cuestan distinto. image en BlogPosting nos salió gratis: cada post ya renderiza una tarjeta OG en una URL estable, así que completar la propiedad era apuntar a un recurso que existe. BreadcrumbList en los posts era el mismo tipo de trabajo, porque otras cuatro plantillas ya emitían uno.
aggregateRating es del otro tipo. La propiedad quiere datos de reseñas reales, y un sitio sin reseñas no tiene nada honesto para poner ahí. Nuestra auditoría escribió la instrucción adentro del hallazgo: sumalo solo cuando existan datos de reseñas genuinos, y nunca fabriques calificaciones. Un agente al que le pedís "completá el schema" te inventa feliz un 4,8 sobre 237 reseñas, y ese número pasa a ser una afirmación fabricada en una página cuyo argumento entero es que informa cosas medidas. Dejá la propiedad vacía hasta que existan los datos.
FAQPage es marcado válido sin función en la SERP desde mayo de 2026
Google retiró los resultados enriquecidos de FAQ para todos los sitios el 2026-05-07, así que hoy el marcado FAQPage no gana ninguna función de búsqueda. Nuestra auditoría lo registra como información en las cuatro plantillas que lo llevan, recomienda dejarlas así y desaconseja sumarlo a páginas nuevas por motivos de SERP. El agente geo de la misma corrida propuso sumar FAQPage a más páginas, y el orquestador descartó esa propuesta con la fecha del retiro adjunta.
Escribí igual el FAQ visible. Lo lee un lector con una pregunta, y lo lee un motor de respuestas buscando un pasaje corto y citable, que es de lo que se trata la clase 12. Si querés el marcado por lo que sea que parsee tu JSON-LD, el generador de schema FAQ gratis lo arma con las preguntas que ya escribiste, y lo de la SERP lo decidís aparte.
Una fecha de calendario se convirtió en fecha de publicación
El artículo estaba planificado para el 2026-10-10, y ese día planificado es el que la entrega escribió en el campo publishedAt del archivo. El post salió en vivo el 2026-09-28 y cuenta un fin de semana del 26 y el 27 de septiembre. Así que la página se publicó llevando una fecha futura en la línea que ve un lector, en datePublished y dateModified, en article:published_time y en cuatro valores de lastmod del sitemap.
Tres corridas lo encontraron el mismo día, desde tres ángulos. El orquestador de la auditoría lo confirmó contra el sitio en vivo y lo ató a los lastmod futuros del sitemap como una misma causa raíz. El comando de contenido lo puntuó como problema de confianza de severidad alta, porque la fecha visible contradice un cuerpo que dice que la cosa salió en vivo el 27 de septiembre. El comando de geo lo calificó de crítico y adivinó bien el mecanismo: el producto está escribiendo la fecha programada en lugar de la real. Corregimos la fecha en el repositorio al 2026-09-28.
El arreglo sugerido se trajo el bug adentro
El agente de schema cerró su informe con un bloque de JSON-LD listo para pegar que resolvía el image faltante, y ese bloque reusaba 2026-10-10 en las dos fechas. El orquestador lo agarró y dejó una nota en la sección de verificación diciéndole al lector que use la fecha real de publicación.
La salida copiable es donde un valor equivocado viaja más rápido. Una fecha que habrías cuestionado en una oración se cuela adentro de un bloque de código, porque un bloque de código se lee como algo que produjo una máquina y chequeó una máquina. Leé el ejemplo antes de pegarlo, y chequeá los valores que el ejemplo se trajo de la página que estaba describiendo.
La entrega deja un archivo borrador en tu repositorio y para ahí
Un destino de entrega son cinco respuestas: repositorio, rama, plantilla de ruta, formato del cuerpo y el mapeo del frontmatter. El nuestro dice GitHub ch0rch/seodraft-app, rama main, content/blog/{locale}/{slug}.mdoc, cuerpo Markdoc, preset de Keystatic, y ese preset mapea date a publishedAt, updatedDate a updatedAt y descarta image. delivery_status te devuelve esas cinco respuestas, más si hay un token guardado, y nunca devuelve el token.
Cada entrega escribe draft: true en el archivo diga lo que diga la marca del artículo, no hay opción para apagarlo, y nunca se borra nada de tu repositorio. Volver a entregar sobrescribe la misma ruta, así que repetirlo es seguro; cuando un slug se mueve, se escribe la ruta nueva y se te nombra la vieja para que la borres a mano. La página de entrega al CMS describe los destinos con más detalle.
Aprobar es una sola llamada que chequea primero las reglas
approve_post se niega si el último chequeo de run_gate no pasó, lo que convierte la aprobación en un gate más que en un botón. Cuando pasa, la misma llamada mueve el artículo a ready y lo entrega al destino configurado. Nuestro propio post llegó a ese estado con lastGateOk: true y cayó en content/blog/en/how-to-distribute-an-mcp-server.mdoc el 2026-09-28 a las 03:11 UTC, con su traducción al español enlazada como el mismo artículo en otro idioma.
Después de eso la herramienta terminó y vos no. El archivo de tu repositorio espera a que una persona lo abra, chequee las fechas, chequee los enlaces, suba las imágenes que pidieron los slots del artículo y publique desde el CMS. Nuestro bug de fecha vivió en ese hueco unos días, que es la versión honesta de la clase: el hueco existe para que un humano agarre lo que escribió un pipeline, y funciona solo cuando el humano mira.
El árbol en español se declaraba inglés en el HTML crudo
El único ítem crítico de la auditoría no tenía nada que ver con el post. Nuestras rutas /es servían <html lang="en"> en el HTML que sale del servidor, con el idioma correcto aplicado después por un script de cliente. Un crawler que lee HTML crudo, y cualquier cliente que no corre JavaScript, veía contenido en español etiquetado como inglés en todo el árbol español.
Lo arreglamos renderizando lang en el servidor a partir de la propia ruta, así el atributo sale correcto en el primer byte. El chequeo es una línea de curl contra tu propio sitio, y vale la pena correrlo después de cualquier cambio en un layout raíz. Una declaración de idioma es de esas cosas que están bien en todas partes o mal en todas partes, y en un navegador no se nota.
Qué leer la mañana que publicás
Cuatro lecturas forman un chequeo de publicación, y en un post normal llevan unos diez minutos. Leé las fechas en cada superficie que lleve una, incluido tu sitemap, que el chequeador de sitemap gratis te lista sin instalar nada. Leé las propiedades requeridas del resultado enriquecido que querés, y dejá vacío todo lo que no puedas respaldar con datos reales. Abrí el archivo entregado y confirmá que la marca de borrador sigue ahí, y después publicá vos desde tu CMS.
La cuarta lectura es la que todos se saltean: abrí la URL en vivo después y mirá qué dice la página de verdad. Nuestro post estaba bien en el borrador, bien en la entrega y mal en la página, y la diferencia fue un campo que un pipeline completó con el día que alguien había planificado. La clase 12 agarra esa misma página publicada y le hace otra pregunta: si un motor de respuestas puede citarla.