Frontmatter de Contenido: Campos y Metadatos SEO

El frontmatter es el elemento de página que los lectores nunca ven como un bloque y del que depende todo sistema de publicación. Le da a un documento una identidad, un contrato de renderizado, una vista previa de búsqueda, un registro de propiedad, fechas y entradas de esquema. Un frontmatter defectuoso puede seleccionar la plantilla incorrecta, crear conflictos canónicos, perder al autor o emitir marcado que contradiga la página.

El espécimen en vivo es un registro a nivel de documento, mostrado como código porque el frontmatter no debe convertirse en una caja decorativa en el cuerpo.

+++
entity = "guide-how-to"
id = "reset-api-key"
title = "How to Reset an API Key"
seoTitle = "How to Reset an API Key Safely"
description = "Reset an API key safely, replace it in every dependent service, verify the new credential, and revoke the exposed key without avoidable downtime."
url = "/academy/reset-an-api-key/"
image = "/images/academy/reset-api-key.png"
imageAlt = "API key settings with the Rotate key action highlighted"
date = "2026-08-27 10:00:00"
updated = "2026-09-03 14:30:00"
author = "maya-chen"
reviewedBy = "alex-rivera"
keywords = [ "reset API key", "rotate API key", "revoke API key" ]
taxonomy = [ "security", "account-administration" ]
canonical = "https://amicited.com/academy/reset-an-api-key/"

[[faq]]
question = "Does rotating an API key revoke the old key immediately?"
answer = "Not necessarily. Confirm the provider's rotation behavior before changing dependent services."
+++

Por qué existe el frontmatter

Para un lector, los metadatos reducen la incertidumbre. Un título preciso establece el alcance, una descripción útil gana el clic, las identidades hacen que las afirmaciones sean responsables y las fechas revelan si la información puede haber envejecido. Estas señales no pueden compensar un contenido débil, pero su ausencia obliga al lector a adivinar.

Para las máquinas, el frontmatter reemplaza la inferencia con valores nombrados. Las plantillas mapean campos a títulos de navegador, enlaces canónicos, registros de personas, fechas, feeds, índices y JSON-LD sin extraer texto de la prosa. Esto es capacidad de extracción por máquina: los datos importantes tienen una ubicación y un tipo consistentes.

Siga las reglas de redacción de elementos: los metadatos pertenecen al nivel del documento; los elementos visibles para el lector pertenecen al cuerpo. Una línea de autoría puede renderizarse desde el frontmatter, pero su identificador autoritativo permanece allí.

Cuándo usarlo — y cuándo no

Toda página indexable necesita un registro de frontmatter para identidad, renderizado y enrutamiento. Los borradores lo necesitan cuando entran en producción para que la validación pueda fallar temprano.

No oculte hechos del artículo en el frontmatter. Las limitaciones del producto, las advertencias de seguridad, las divulgaciones de afiliados, los métodos y las fuentes deben permanecer visibles donde los lectores puedan evaluarlos. Un valor estructurado nunca sustituye una divulgación.

Los errores por aproximación causan el mayor daño:

• Las etiquetas de navegación, el texto de campaña y los subtítulos sociales que varían de forma independiente son configuraciones de canal; no sobrecargue title.
• Los datos de la organización compartidos en todo el sitio pertenecen al registro de la organización del sitio, no copiados en cada página donde se desviarán.
• Una sección de preguntas y respuestas pertenece a [[faq]] solo cuando el mismo contenido se renderiza visiblemente. Una FAQ oculta solo para esquema no es válida.
• Una etiqueta de tema pertenece a taxonomy; no debe reemplazar a entity, que identifica el tipo de publicación del documento.
• Una redirección pertenece a la configuración de enrutamiento o a un campo de alias aprobado. canonical identifica la versión preferida; no redirige a los visitantes.

Dónde ubicarlo

El frontmatter comienza en el primer byte con +++ y termina en el delimitador de cierre antes del cuerpo. Ningún encabezado, comentario, nota, shortcode o bloque de metadatos puede precederlo. Los campos y arreglos de TOML pertenecen dentro de ese único registro.

El cuerpo comienza después del delimitador de cierre. El frontmatter no puede situarse entre el H1 y la introducción, junto a una captura de pantalla, dentro de un componente o al final. Una marca de orden de bytes o un comentario errante pueden impedir su reconocimiento. Las claves duplicadas, los delimitadores de YAML y los segundos bloques no son válidos.

Anatomía

La leyenda renderizada permanece en la página para que sea legible y traducible independientemente de la imagen:

1. Límite: los delimitadores de apertura y cierre +++ definen la única región de metadatos.
2. Identidad: entity, id, type y url indican a los sistemas qué es el documento y dónde reside.
3. Descubrimiento: title, seoTitle, description, image, imageAlt y keywords admiten vistas previas y recuperación.
4. Procedencia: date, updated, author y reviewedBy indican quién es responsable y cuándo se modificó válidamente el trabajo.
5. Clasificación: taxonomy une la página a colecciones de temas controlados sin redefinir su identidad.
6. Control de duplicación: canonical nombra la URL pública preferida cuando hay versiones equivalentes accesibles desde otro lugar.
7. Colecciones estructuradas: cada [[faq]] crea un registro tipificado de pregunta y respuesta para renderizado visible y esquema.

Ejemplos de diseño

El frontmatter tiene variantes de contrato de datos, no estilos visuales. Las capturas de pantalla emparejan registros fuente con su vista previa o línea de autoría resultante.

Parámetros

Estos son límites editoriales incluso cuando un analizador acepta más. «Condicional» significa obligatorio cuando se cumple la condición indicada.

Referencia por campo

Esta referencia define el contrato de publicación para cada campo. «Obligatorio» significa que la validación debe detener la publicación cuando el campo o su derivación válida estén ausentes. «Condicional» significa que el requisito se activa por un hecho indicado, como que se renderice una imagen o que se haya realizado una revisión independiente. Un valor predeterminado es seguro solo cuando produce el mismo significado que un editor habría elegido deliberadamente.

Identidad y enrutamiento

title, h1 y seoTitle

• Propósito — title da al documento su nombre editorial duradero. h1 controla el encabezado principal en la página cuando el contexto de diseño necesita una redacción diferente. seoTitle controla el título del navegador/búsqueda cuando el valor predeterminado necesita un calificador conciso o un tratamiento de marca. Separarlos evita que una etiqueta de navegación, un encabezado de página y una vista previa de búsqueda se vean forzados a una sola cadena incómoda.
• Tipo y formato — Cada uno es una cadena de texto plano. title es el valor fuente; las sobrescrituras ausentes deben recurrir a él. HTML, Markdown, decoración con emojis y marcas de truncamiento manual no son valores válidos.
• ¿Obligatorio? — title es obligatorio en toda página pública. h1 y seoTitle son opcionales y deben omitirse cuando title funciona en los tres contextos.
• Límites — Use de 30 a 70 caracteres para title, de 20 a 80 para h1 y de 30 a 60 para seoTitle como bandas editoriales, no como promesas de que una interfaz de búsqueda mostrará cada carácter. Debe haber un H1 renderizado.
• Quién o qué lo consume — Plantillas de página, títulos de navegador, adaptadores de búsqueda y redes sociales, tarjetas de navegación, feeds, headline de esquema, esquemas de accesibilidad y listados editoriales.
• Reglas — Todas las versiones deben identificar el mismo tema, intención y alcance. Una diferencia legítima resuelve una restricción del canal: por ejemplo, el H1 puede decir «Cómo Rotar una Clave de API Sin Tiempo de Inactividad», mientras que el título SEO más corto dice «Rotación de Clave de API: Guía Paso a Paso Segura». La sección posterior Título, H1 y título SEO explica la prueba editorial.
• Errores comunes — Repetir una palabra clave en las tres variantes, poner un sufijo de marca en el H1, cambiar la promesa para perseguir clics, incorporar el año actual cuando la página no se mantiene anualmente, o redactar tres valores simplemente porque existen tres campos.

slug y url

• Propósito — El slug es el segmento final de la ruta; url es la ruta pública relativa al sitio que lo contiene. Juntos le dan a la página una dirección estable para lectores, rastreadores, enlaces, informes y migraciones. La estabilidad importa porque cada enlace conseguido y marcador guardado depende de esa dirección.
• Tipo y formato — Use una cadena de ruta en minúsculas separada por guiones, como /academy/rotate-an-api-key/. Este repositorio registra la ruta completa en url; un CMS que tiene un campo slug separado debe derivar el mismo segmento final.
• ¿Obligatorio? — Se requiere una ruta única para cada página pública. Puede generarse solo cuando una sección tiene una regla determinista aprobada y comprobaciones de colisiones; las páginas del manual usan sus valores url registrados.
• Límites — Prefiera un slug corto y legible que conserve el tema distintivo, normalmente de tres a ocho palabras útiles. Elimine la puntuación y los modificadores vacíos. Elimine palabras vacías como «el», «la», «un», «una» solo cuando el resultado siga siendo natural e inequívoco; no hay un límite arbitrario de caracteres que justifique dañar el significado.
• Quién o qué lo consume — Enrutamiento de Hugo, enlaces internos, migas de pan, generación canónica, sitemaps, feeds, analíticas, redirecciones y referencias externas.
• Reglas — Trate un slug publicado como un compromiso permanente. Decídalo a partir del tema duradero, no de un titular de campaña o un año transitorio. Cuando el título cambie pero el tema y la intención no, mantenga el slug anterior. Si la página se muda realmente, cree la nueva ruta, conserve la ruta anterior en aliases, actualice los enlaces internos y pruebe el destino de la redirección.
• Errores comunes — Regenerar el slug cada vez que cambia el título, incluir sinónimos en la ruta, mantener fechas que hacen que el contenido imperecedero parezca obsoleto, usar mayúsculas y minúsculas mezcladas o guiones bajos, crear dos URL que difieren solo por una barra diagonal final, y cambiar una ruta sin preservar la anterior.

canonical

• Propósito — Un canonical identifica la URL preferida entre versiones equivalentes o casi equivalentes accesibles. Consolida la identidad; no mueve al visitante ni excusa la duplicación descontrolada.
• Tipo y formato — Una URL HTTPS absoluta, que incluya el host previsto y la ruta normalizada: https://amicited.com/academy/rotate-an-api-key/. La plantilla puede derivar una autorreferencia del enlace permanente de la página cuando el sitio tiene una política de host y ruta confiable.
• ¿Obligatorio? — Toda página indexable debe emitir un canonical. El campo en sí es condicional cuando se deriva automáticamente un valor de autorreferencia correcto; establézcalo explícitamente para un canonical excepcional o entre dominios aprobado.
• Límites — Exactamente un destino canónico. El destino debe devolver un documento indexable exitoso, usar el protocolo y host preferidos, y representar sustancialmente el mismo contenido.
• Quién o qué lo consume — El HTML <link rel="canonical">, los motores de búsqueda, las comprobaciones de sitemap y enlaces internos, los informes de deduplicación y los identificadores de URL de esquema.
• Reglas — Autorreferencia por defecto. Use un canonical entre dominios solo cuando otro editor sea propietario del equivalente preferido y ambas partes tengan la intención de consolidar. Use una redirección, no un canonical, cuando la URL anterior haya sido reemplazada y los usuarios deban llegar siempre a la nueva. Mantenga alineados el canonical, la URL del sitemap, el hreflang, los enlaces internos y la identidad del esquema.
• Errores comunes — Apuntar cada página paginada o localizada a un padre genérico, canonicalizar contenido distinto, dirigirse a una redirección o página de error, mezclar HTTP y HTTPS, usar el campo como sustituto de un alias, y asumir que las directivas canónicas están garantizadas.

aliases

• Propósito — aliases preserva rutas que anteriormente identificaban la misma página, de modo que un traslado no convierta los enlaces y marcadores existentes en callejones sin salida. Registra el historial de rutas en lugar de crear identidades indexables alternativas.
• Tipo y formato — Un arreglo TOML de rutas relativas al sitio, por ejemplo aliases = [ "/blog/old-api-key-guide/" ]. Cada valor incluye una barra inicial y final y debe ser único en todo el sitio.
• ¿Obligatorio? — Opcional para una página nueva; obligatorio cuando una página publicada se traslada desde una ruta que el sitio controlaba.
• Límites — Incluya cada ruta conocida de terceros que aún reciba enlaces o tráfico. No agregue variantes ortográficas especulativas ni una lista ilimitada de URL con palabras clave.
• Quién o qué lo consume — La salida de alias de Hugo, el procesamiento de redirecciones de despliegue donde esté configurado, el QA de migración, los monitores de enlaces y los usuarios que siguen URL antiguas. Debido a que Hugo puede emitir una página de alias en lugar de una redirección HTTP a nivel de origen, el comportamiento del despliegue debe verificarse en lugar de asumirse.
• Reglas — Una página trasladada mantiene su ruta anterior funcionando. Cada alias debe resolverse en un solo salto a la ruta canónica actual. Actualice los enlaces internos a la nueva URL incluso cuando el alias funcione, y conserve el alias en ediciones posteriores a menos que un sistema de redirección documentado lo sustituya.
• Errores comunes — Eliminar la página anterior sin un alias, encadenar ruta antigua a ruta intermedia a ruta actual, tratar los alias como rutas de publicación duplicadas, apuntar varias páginas no relacionadas a un destino conveniente, o asumir que la salida local de Hugo demuestra el estado HTTP de producción.

type y layout

• Propósito — Estos campos seleccionan el contrato de renderizado. type coloca una página en una clase de contenido con plantillas y comportamiento compartidos; layout solicita una plantilla específica dentro de esa clase. Una selección correcta asegura que la página reciba la navegación, el espacio de contenido, los activos y el comportamiento de esquema previstos.
• Tipo y formato — Cadenas registradas en minúsculas. Esta página usa type = "academy". Un valor de layout es un nombre base de plantilla como single, sin extensión de archivo ni recorrido de ruta.
• ¿Obligatorio? — type es obligatorio cuando la ubicación del contenido no implica de forma segura el tipo previsto o cuando el contrato del manual lo exige. layout es opcional y debe omitirse cuando la plantilla predeterminada del tipo es correcta.
• Límites — Un valor para cada campo, elegido solo entre las plantillas mantenidas por el sitio. Un nuevo valor es un cambio de ingeniería, no una improvisación editorial.
• Quién o qué lo consume — El orden de búsqueda de Hugo, las plantillas, la selección de parciales, la inclusión de CSS y JavaScript, los adaptadores de esquema y las reglas de validación.
• Reglas — Elija el tipo de publicación y el contrato de renderizado antes de redactar. Use layout solo para una variante genuinamente soportada; no lo use para compensar contenido que pertenece a otro type. Verifique que exista una sobrescritura y acepte la forma del frontmatter de la página.
• Errores comunes — Confundir el entity editorial con el type de Hugo, nombrar un archivo de plantilla que no existe, copiar un tipo de página de aterrizaje en un documento de academia, confiar en la inferencia de carpetas durante una migración, e introducir nombres de layout únicos que eluden las mejoras compartidas.

Descubrimiento

description

• Propósito — La descripción ayuda a un buscador cualificado o destinatario de un contenido compartido a decidir si esta página responde a su necesidad. Es texto de vista previa, no una introducción comprimida ni un lugar para demostrar relevancia mediante repetición.
• Tipo y formato — Una oración en texto plano. Debe nombrar el término principal de forma natural, indicar el valor concreto y agregar alcance, audiencia, método o resultado útiles.
• ¿Obligatorio? — Obligatorio para toda página indexable en este manual.
• Límites — 150–160 caracteres, incluidos los espacios. Esta es una banda de coherencia editorial, no una garantía de visualización: los motores de búsqueda pueden truncarla o reescribir el fragmento a partir del contenido del cuerpo cuando otro pasaje se ajuste mejor a la consulta.
• Quién o qué lo consume — Etiquetas de meta descripción, valores predeterminados de descripción de Open Graph y Twitter, tarjetas de listado, feeds, vistas previas del CMS, controles de calidad de búsqueda y, a veces, description de esquema.
• Reglas — Escriba para un clic del lector adecuado. Haga que la oración sea lo suficientemente específica para distinguir la página de otro resultado con un título similar. La sección Reglas de descripción más adelante proporciona la justificación y las pruebas de rechazo.
• Errores comunes — Duplicar el título, enumerar palabras clave, comenzar con «Aprenda todo sobre», hacer una afirmación no respaldada de ser el mejor o el más rápido, usar un llamado a la acción vago, exceder la banda mediante un sufijo de marca no visible, o asumir que el texto redactado debe aparecer textualmente en los resultados de búsqueda.

keywords

• Propósito — En este repositorio, keywords registra el conjunto compacto de consultas y terminología utilizado para el QA editorial, la búsqueda en el corpus, el análisis de cobertura y las herramientas internas. Ayuda a los editores a reconocer el lenguaje que una página debe usar con precisión; no es una promesa de incluir cada frase mecánicamente.
• Tipo y formato — Un arreglo de cadenas en lenguaje natural, ordenadas desde el término principal hasta variantes significativas y terminología estrechamente relacionada.
• ¿Obligatorio? — Obligatorio según este manual, incluso para páginas cuyas plantillas públicas no renderizan los valores.
• Límites — Seis a ocho entradas distintas. Cada entrada debe representar una frase de consulta real o un término necesario, no una variación a nivel de token.
• Quién o qué lo consume — Validadores editoriales, inventarios de contenido, análisis de búsqueda y oportunidades, recuperación interna y herramientas de migración. Los motores de búsqueda públicos no usan este campo como señal de clasificación simplemente porque existe.
• Reglas — Mantenga el conjunto centrado en el alcance de una sola página. Fusione duplicados de mayúsculas/minúsculas, puntuación, singular/plural y orden trivial de palabras. Use las frases para verificar la cobertura y la terminología, nunca para dictar una densidad antinatural.
• Errores comunes — Tratar el campo como el obsoleto mecanismo de clasificación de meta keywords, agregar docenas de variantes, repetir el título como ocho cuasi duplicados, insertar nombres de competidores que el cuerpo no menciona, y permitir que el arreglo reemplace la taxonomía adecuada o los objetivos de consulta.

targetPrompts

• Propósito — targetPrompts registra las preguntas o solicitudes completas que una persona puede dar a un sistema de respuesta de IA y para las cuales esta página debería ser una fuente útil. Los objetivos de consulta preservan el contexto conversacional que las frases cortas de palabras clave omiten.
• Tipo y formato — Un arreglo de cadenas completas en lenguaje natural, por ejemplo targetPrompts = [ "How do I rotate an API key without downtime?", "What should I check before revoking an old API key?" ]. Mantenga la redacción tal como un usuario la preguntaría, incluyendo audiencia, restricciones o comparación deseada.
• ¿Obligatorio? — Condicional para páginas incluidas en el seguimiento de consultas o un programa de visibilidad en IA; opcional cuando no existe un conjunto de consultas rastreadas.
• Límites — Use un conjunto pequeño e intencional, normalmente una consulta principal y hasta cuatro variantes significativas. Una consulta puede ser más larga que una palabra clave porque sus calificadores conllevan intención.
• Quién o qué lo consume — Briefs de contenido, flujos de trabajo de seguimiento de consultas, auditorías de recuperación y cobertura, monitoreo de respuestas de IA y evaluación editorial. No se renderiza como texto de búsqueda oculto.
• Reglas — Separe las consultas por necesidad real de información, no por puntuación. Una palabra clave como «rotación de clave de API» nombra un tema; «¿Cómo puede un equipo SaaS rotar una clave de API sin interrumpir las integraciones?» nombra una audiencia, tarea y restricción. La página debe responder honestamente a cada consulta almacenada.
• Errores comunes — Copiar el arreglo de keywords en este campo, inventar docenas de variaciones sintácticas, registrar consultas más amplias que la página, usar consultas como encabezados del cuerpo independientemente del flujo de lectura, y afirmar cobertura de consultas cuando la respuesta depende de información que la página no proporciona.

Confianza y procedencia

date y updated

• Propósito — date conserva cuándo se publicó la página por primera vez; updated informa el último cambio sustancial o revisión completada. Dos campos preservan la historia mientras muestran si la información en la que confían los lectores ha cambiado.
• Tipo y formato — Cadenas de marca de tiempo en la convención del sitio, YYYY-MM-DD HH:MM:SS. Mantenga una política de zona horaria en todo el corpus para que los feeds y las comparaciones sigan siendo deterministas.
• ¿Obligatorio? — date es obligatorio para páginas editoriales publicadas. updated es opcional hasta que ocurra un cambio que lo justifique; entonces es obligatorio si la página presenta una fecha de modificación.
• Límites — Un valor cada uno. updated no puede preceder a date ni estar en el futuro. Una corrección hecha minutos después de la publicación aún puede documentarse, pero las revisiones rutinarias de borradores antes de la publicación no crean una fecha de actualización.
• Quién o qué lo consume — Líneas de autoría visibles y sellos de actualidad, feeds, sitemaps, datePublished y dateModified de esquema, auditorías de actualidad, clasificación y colas editoriales.
• Reglas — Restablezca updated por una corrección factual, un cambio de instrucciones, evidencia nueva o eliminada, un alcance revisado, una recomendación modificada sustancialmente, o una revisión documentada de afirmaciones sensibles al tiempo. Nunca lo restablezca por puntuación, formato, trabajo de plantilla o una edición de solo marca de tiempo. Consulte Fechas, autores y revisores para conocer la justificación de la política.
• Errores comunes — Sobrescribir la fecha original durante una actualización, poner una fecha futura para que una página parezca reciente, aumentar las fechas sin un diff de contenido, tratar un despliegue automatizado como una actualización editorial, y no registrar qué cambió en el historial de actualizaciones mantenido.

author

• Propósito — author conecta el documento con la entidad de persona responsable de su trabajo. El vínculo le da al lector y a la máquina una ruta desde una página que contiene afirmaciones hasta una identidad, experiencia y otros trabajos mantenidos.
• Tipo y formato — Un identificador de autor estable que se resuelve a través del registro de autores del sitio hasta una URL de perfil y un registro Person. Por ejemplo, author = "maya-chen" es válido solo si ese identificador se resuelve; un nombre para mostrar como "Maya Chen, Experta en SEO" no es un sustituto del vínculo de entidad.
• ¿Obligatorio? — Obligatorio para páginas editoriales sustanciales. Las páginas transaccionales pueden usar un propietario organizacional gobernado solo cuando la plantilla y la política admiten ese tipo de entidad.
• Límites — Un responsable principal por defecto; use un arreglo de identificadores documentado solo cuando el esquema y las plantillas de línea de autoría admitan la coautoría genuina.
• Quién o qué lo consume — Líneas de autoría visibles, enlaces a perfiles de autor, esquema Article, feeds, informes de propiedad editorial, flujos de trabajo de revisión y gráficos de entidades.
• Reglas — Resuelva el identificador antes de la publicación. El perfil debe identificar a la misma persona que se muestra en la línea de autoría y mantenerse actualizado. Acredite a la persona responsable del contenido, no a la persona que simplemente lo subió.
• Errores comunes — Ingresar una cadena de nombre sin enlace, usar «Admin» o un equipo editorial inventado, asignar a un ejecutivo destacado que no redactó el trabajo, permitir que un identificador se resuelva a ningún perfil, y cambiar la autoría para implicar experiencia que no estuvo involucrada.

reviewedBy, reviewedAt y reviewScope

• Propósito — Estos campos registran una revisión independiente distinta de la autoría. reviewedBy identifica la entidad revisora; reviewedAt indica cuándo se completó la revisión; reviewScope dice qué comprobó el revisor, para que la insignia no implique aprobación más allá de la evidencia.
• Tipo y formato — reviewedBy es un identificador estable que se resuelve en un perfil de persona mantenido. reviewedAt usa el formato de marca de tiempo del sitio. reviewScope es una declaración concisa en texto plano como «Pasos de rotación de credenciales y advertencias de seguridad».
• ¿Obligatorio? — Condicional cuando la ley, la política de riesgos, la sensibilidad del tema o la especificación del tipo de publicación requieran una revisión independiente. Cuando reviewedBy está presente, la fecha y el alcance de la revisión son obligatorios como datos del registro de revisión, incluso si una plantilla particular los almacena en un registro editorial conectado en lugar del frontmatter público.
• Límites — Nombre solo a revisores reales. El alcance debe ser lo suficientemente específico para revelar exclusiones sin convertirse en un informe de revisión. Un revisor debe tener competencia relevante y no debe simplemente duplicar el rol de autor.
• Quién o qué lo consume — Componentes de «revisado por», uniones de entidades Person, auditorías de gobernanza, puertas de publicación de alto riesgo, procedencia estructurada y registros de actualización.
• Reglas — Complete la revisión después de que el contenido esté estable, capture los hallazgos y la resolución en el historial editorial, y vuelva a revisar cuando cambios posteriores afecten el alcance revisado. Independiente significa que el revisor prueba el trabajo en lugar de respaldar su propio borrador.
• Errores comunes — Tratar la corrección de estilo como revisión experta, mostrar un revisor sin fecha ni alcance, nombrar a alguien que nunca vio la versión final, dejar la insignia después de una reescritura no revisada sustancial, e implicar aprobación legal, médica o técnica fuera del alcance indicado.

Multimedia y redes sociales

image e imageAlt

• Propósito — image selecciona el activo principal y para redes sociales; imageAlt proporciona la alternativa textual funcional cuando ese activo se renderiza como contenido de página significativo. Mantener el par junto evita que las imágenes de descubrimiento se conviertan en una omisión de accesibilidad.
• Tipo y formato — image es una ruta resoluble del sitio o una URL absoluta aprobada. imageAlt es texto plano que describe la información útil de la imagen en su contexto de página, no su nombre de archivo o palabra clave objetivo.
• ¿Obligatorio? — Condicional según el tipo de publicación y la plantilla. Si la página requiere una imagen principal o una imagen social dedicada, image es obligatorio. imageAlt es obligatorio siempre que esa imagen se renderice de forma informativa; una representación puramente decorativa debe usar un atributo alt vacío en la plantilla, no un texto descriptivo inventado.
• Límites — Use un activo representativo. Para compatibilidad social, proporcione una fuente de 1200 × 630 píxeles en la proporción de recorte esperada, mantenga el contenido importante alejado de los bordes y mantenga imageAlt conciso — normalmente de 5 a 160 caracteres. El archivo debe existir antes de ser referenciado.
• Quién o qué lo consume — Componentes principales, tarjetas de listado, etiquetas de Open Graph y Twitter, campos de imagen de esquema, feeds, canalizaciones de imágenes, lectores de pantalla cuando es visible y QA de activos.
• Reglas — Elija una imagen que siga comunicando después de un recorte centrado y en tamaño de miniatura. Describa su función en contexto: «Configuración de clave de API con Rotar clave resaltado» es útil; «clave de API» no. No ponga afirmaciones esenciales solo dentro de los píxeles.
• Errores comunes — Referenciar un activo planificado que no existe, usar un logotipo como imagen de cada artículo, incrustar texto pequeño que se vuelve ilegible al compartir, escribir «imagen de», incluir palabras clave en el texto alternativo, y asumir que el texto alternativo social y el comportamiento del texto alternativo de imagen visible son idénticos en todas las plataformas.

Campos de Open Graph y tarjetas de Twitter

• Propósito — Los metadatos sociales controlan cómo se resume una URL cuando se comparte. Un título, descripción, URL, tipo e imagen coherentes ayudan a los destinatarios a reconocer la página antes de hacer clic y reducen la probabilidad de que una plataforma seleccione un activo irrelevante.
• Tipo y formato — En este repositorio, las plantillas derivan og:title y twitter:title de title, las descripciones de description, las URL del enlace permanente, og:type del contexto de diseño, y ambas etiquetas de imagen de image con un respaldo del sitio. twitter:card se emite como summary_large_image. Estas son etiquetas generadas, no campos de frontmatter duplicados por defecto.
• ¿Obligatorio? — Las etiquetas de salida son obligatorias en las páginas públicas. Las sobrescrituras separadas son opcionales y deben introducirse solo a través de un contrato de plantilla documentado; los campos ad hoc no soportados como ogTitle no hacen nada.
• Límites — Una vista previa coherente por página y una imagen representativa de 1200 × 630. Mantenga la redacción derivada dentro de las bandas de título y descripción, luego pruebe el comportamiento real de recorte y superposición en las principales superficies de uso compartido.
• Quién o qué lo consume — Redes sociales, clientes de mensajería, expansores de enlaces, extensiones de navegador, herramientas de colaboración y depuradores de vista previa de uso compartido.
• Reglas — Prefiera la derivación para que las afirmaciones de búsqueda y redes sociales se mantengan alineadas. Sobrescriba solo cuando el contexto social necesite genuinamente un enfoque diferente y la plantilla lo soporte. Una imagen incorrecta cuesta reconocimiento y confianza: el destinatario puede ver una interfaz obsoleta, otro producto, una afirmación engañosa o un recorte que oculta el tema.
• Errores comunes — Redactar campos que ninguna plantilla lee, permitir que un respaldo global oculte un héroe obligatorio faltante, usar una imagen vertical o pequeña para una tarjeta ancha, cambiar el texto social para hacer una promesa más fuerte que la página, y validar solo el código fuente HTML en lugar de una vista previa obtenida.

Clasificación

taxonomy, categories y tags

• Propósito — La clasificación conecta una página con colecciones gobernadas de temas, formatos, audiencias o productos. Potencia archivos y filtros útiles solo cuando cada vocabulario tiene un significado declarado; de lo contrario, las etiquetas se convierten en un montón de sinónimos no controlados.
• Tipo y formato — Arreglos de slugs registrados en minúsculas. Use taxonomy para el vocabulario controlado de temas del repositorio. Use categories solo para una jerarquía editorial pequeña mutuamente inteligible y tags solo para un vocabulario transversal gobernado cuando esas taxonomías estén configuradas.
• ¿Obligatorio? — Condicional según el tipo de publicación y el diseño del archivo. Las páginas editoriales con contenido temático normalmente requieren uno o más términos controlados; las páginas utilitarias pueden no requerir ninguno. Un campo no debe poblarse simplemente porque un CMS lo expone.
• Límites — Para taxonomía general, de uno a cinco valores por vocabulario controlado. Cada término necesita una definición, propietario y regla de fusión. Cree un archivo indexable solo cuando el término represente una demanda duradera del lector y el archivo pueda ofrecer una introducción única, un inventario coherente, enlaces internos y un mantenimiento continuo.
• Quién o qué lo consume — Páginas de archivo, migas de pan, filtros, sistemas de contenido relacionado, navegación facetada, auditorías de contenido y segmentación analítica.
• Reglas — Elija el término registrado más específico que agrupe la página con precisión. Mantenga singular/plural, abreviaturas y variantes ortográficas mapeadas a un valor canónico. Decida si los archivos son indexables a nivel de vocabulario, no etiqueta por etiqueta después de una creación accidental.
• Errores comunes — Usar seo, SEO, search-optimization y search engine optimization como valores separados, agregar etiquetas únicas para describir cada sustantivo, confundir un tipo de negocio con un tema, generar archivos indexables de poco contenido y eliminar términos sin migrar a sus miembros.

Claves de unión del manual

• Propósito — playbookPillar, playbookFamily, playbookWave, postTypes, elements, businessTypes, journeyStage y amicitedFeatures son claves de unión tipificadas. Permiten que una página fuente aparezca en bibliotecas y matrices generadas sin que los editores copien tarjetas manualmente. Esta página es el ejemplo práctico: su pilar identifica un elemento, su familia agrupa la guía de metadatos y su arreglo postTypes declara las especificaciones que lo consumen.
• Tipo y formato — Las claves singulares usan slugs registrados en minúsculas: playbookPillar y playbookFamily son cadenas, playbookWave es un entero y journeyStage es una cadena controlada. Las claves de relación —postTypes, elements, businessTypes y amicitedFeatures— son arreglos de slugs registrados de sus respectivos registros.
• ¿Obligatorio? — playbookPillar y playbookWave son obligatorios en los registros del manual. playbookFamily es obligatorio cuando el pilar tiene familias gobernadas. Las uniones de arreglos y journeyStage son condicionales: poble solo las relaciones que el contrato de la página realmente soporta.
• Límites — Un pilar, una familia dentro de ese pilar, una oleada y una etapa de recorrido a menos que el modelo permita explícitamente múltiples etapas. Los arreglos contienen claves registradas únicas, no etiquetas de visualización, prosa o URL.
• Quién o qué lo consume — Listados del centro del manual, matrices entre pilares, filtros, tarjetas de relación, informes de integridad, vistas de oleadas de lanzamiento y herramientas internas que encuentran capacidades relevantes de AmICited.
• Reglas — Valide cada valor contra el registro canónico. La dirección importa: una página de tipo de publicación lista sus elements requeridos; una página de elemento lista los postTypes aplicables; una página de tipo de negocio lista los tipos de publicación útiles. Trate las etiquetas como presentación y las claves como datos duraderos. Renombre una clave solo a través de una migración que actualice cada lado de la unión.
• Errores comunes — Inventar casi sinónimos, almacenar títulos en lugar de slugs, mezclar enteros y cadenas para oleadas, agregar una relación porque dos páginas se mencionan mutuamente, permitir que arreglos recíprocos se contradigan entre sí, y crear marcado de listado mantenido manualmente que se desvíe de los metadatos.

Campos derivados y estructurales

schemaType

• Propósito — schemaType selecciona el mapeo de datos estructurados soportados más específico que describa con precisión la página visible. Le indica al adaptador de esquema qué contrato de vocabulario aplicar; no convierte la página en esa cosa solo por declaración.
• Tipo y formato — Un nombre de tipo Schema.org registrado como Article, seleccionado de los tipos que soporta el adaptador del sitio. Las mayúsculas y la ortografía deben coincidir con el registro.
• ¿Obligatorio? — Condicional. Establézcalo donde múltiples mapeos de esquema sean válidos para el mismo tipo de Hugo o donde el contrato del tipo de publicación requiera un tipo explícito. De lo contrario, deje que la plantilla derive su valor predeterminado seguro.
• Límites — Un tipo de página principal, con entidades anidadas creadas por el adaptador a partir del contenido real. El tipo seleccionado debe satisfacer todas las propiedades requeridas y coincidir con lo que un lector puede ver.
• Quién o qué lo consume — Adaptadores JSON-LD, validación de resultados enriquecidos, QA de contenido e informes de inventario de esquema.
• Reglas — Elija según la función de la página y la evidencia visible, no según la característica de búsqueda que un editor desea. Una página de instrucciones sin un procedimiento visible completo no puede ganar precisión estableciendo un tipo de instrucciones. Mantenga las URL, fechas, personas e imágenes del esquema sincronizadas con sus campos fuente.
• Errores comunes — Seleccionar un tipo más específico sin su contenido requerido, emitir varios tipos principales conflictivos, copiar un valor de esquema de una plantilla no relacionada, asumir que la sintaxis válida garantiza la elegibilidad, y poner afirmaciones en JSON-LD que los lectores no pueden inspeccionar.

Tiempo de lectura

• Propósito — El tiempo de lectura le da al lector una estimación aproximada del esfuerzo. Se deriva del cuerpo final renderizable para que la estimación cambie cuando la carga de lectura real cambia.
• Tipo y formato — Un número entero computado de minutos producido a partir de la política de recuento de palabras de la canalización de contenido. Los bloques de código, tablas, leyendas y contenido multimedia incrustado deben seguir una regla de recuento documentada.
• ¿Obligatorio? — La visualización es opcional según la plantilla. No se permite un campo de frontmatter redactado como fuente de verdad.
• Límites — Redondee de forma coherente y aplique una visualización mínima razonable, como un minuto. La suposición precisa de palabras por minuto importa menos que usar el mismo método en todo el sitio y etiquetar el resultado como una estimación.
• Quién o qué lo consume — Encabezados de página, tarjetas, feeds, segmentación analítica y lectores que deciden si comenzar una guía larga.
• Reglas — Calcule después de que los shortcodes y las regiones excluidas se hayan manejado según la política del sitio. Vuelva a calcular en cada compilación. Si un video o una tarea interactiva cambia materialmente el tiempo de finalización, etiquete eso por separado en lugar de corromper el tiempo de lectura.
• Errores comunes — Redactar readingTime = 8, olvidar actualizarlo después de una reescritura, presentar falsa precisión, contar navegación y texto repetitivo, y tratar un tutorial con mucha ejecución como ocho minutos de lectura más cero tiempo de tarea.

[[faq]]

• Propósito — [[faq]] almacena pares de preguntas y respuestas visibles una sola vez para que la página y cualquier dato estructurado de FAQ elegible no puedan divergir.
• Tipo y formato — Un arreglo TOML de tablas; cada elemento contiene un question en texto plano y una cadena answer autocontenida.
• ¿Obligatorio? — Condicional cuando quedan preguntas de seguimiento genuinas después de la página principal. Nunca es obligatorio simplemente para llenar una plantilla o perseguir una característica de búsqueda.
• Límites — Normalmente de cuatro a ocho elementos útiles en páginas del manual. Cada pregunta aparece una vez, y cada respuesta debe ser completa sin depender del orden del acordeón.
• Quién o qué lo consume — Renderizado FAQ visible, esquema FAQPage cuando es elegible, navegación de página, QA de contenido y extracción de respuestas.
• Reglas — Este es un contrato de referencia cruzada: siga Por qué FAQ vive en el frontmatter y la guía de FAQ posterior en lugar de mantener copias visibles y de esquema separadas. Almacene solo preguntas a las que todo lector pueda acceder en la página.
• Errores comunes — Respuestas ocultas solo para esquema, encabezados duplicados disfrazados de preguntas, respuestas promocionales, afirmaciones no respaldadas, JSON-LD desactualizado y tratar la elegibilidad de resultados de búsqueda como garantizada.

[[lnks]]

• Propósito — [[lnks]] registra cada enlace interno gobernado utilizado en el cuerpo, emparejando su ancla visible con un destino y una descripción mantenida. El registro hace que los enlaces sean inspeccionables sin extraer HTML renderizado y soporta migración y QA.
• Tipo y formato — Un arreglo TOML de tablas con text, path y title. text es el ancla visible exacta, path es una URL relativa al sitio con barra inicial y final, y title es la descripción de la página de destino.
• ¿Obligatorio? — Obligatorio para cada enlace interno del cuerpo gobernado por esta convención de contenido. Los enlaces profundos de aplicaciones y las fuentes externas siguen sus propios registros y no se disfrazan como entradas de [[lnks]].
• Límites — Un registro por ocurrencia de enlace en el cuerpo cuando la misma ancla puede apuntar a diferentes destinos; de lo contrario, los registros duplicados exactos deben eliminarse. El destino debe existir o estar en el registro de slugs canónicos aprobado para el lanzamiento coordinado.
• Quién o qué lo consume — Validación de enlaces internos, migración de contenido, análisis de relaciones, generación de títulos de enlace donde sea compatible y revisión editorial.
• Reglas — Haga coincidir text con el ancla del cuerpo textualmente, incluyendo mayúsculas, minúsculas y puntuación dentro del enlace. Use la ruta canónica relativa al sitio. Escriba title como una descripción precisa del destino, no como instrucciones para la página actual. Actualice el registro y el cuerpo juntos.
• Errores comunes — Usar un valor de text más largo que el ancla real, inventar un slug no registrado, omitir una barra final, registrar una ruta anterior que redirige, describir el origen en lugar del destino, y dejar un registro después de que su enlace en el cuerpo se elimine.

Obligatorio versus opcional según el tipo de publicación

La matriz aplica los contratos anteriores a los doce tipos de publicación declarados actualmente por este elemento. R significa obligatorio, C significa condicional según las reglas del campo, D significa salida obligatoria que puede derivarse de forma segura y O significa opcional. «Identidad» incluye entity, id, title, type y la ruta estable. «Descubrimiento» incluye description y keywords; los objetivos de consulta siguen siendo condicionales para cada fila. aliases es siempre condicional a un traslado, mientras que el tiempo de lectura redactado nunca es obligatorio.

«Revisor condicional» no es un permiso para omitir la revisión cuando la precisión o el riesgo comercial lo exijan. Las páginas de mejor-X-para-Y y alternativas-a-X requieren revisión independiente porque sus recomendaciones pueden influir materialmente en una decisión y a menudo cambian a medida que cambian los productos, precios y elegibilidad. Para otras filas, la política de riesgos, no el tiempo disponible de un editor, activa el requisito. Asimismo, un canonical marcado como D sigue siendo obligatorio en el HTML renderizado; solo la entrada de frontmatter puede omitirse cuando la plantilla puede generar la autorreferencia correcta.

Validación del frontmatter

La validación debe rechazar defectos deterministas automáticamente y reservar el juicio para preguntas que dependen del significado, la evidencia o la competencia profesional. La división previene dos fallos opuestos: pedir a los revisores que detecten sintaxis que un analizador puede detectar perfectamente, y pretender que una regla de recuento de caracteres puede decidir si una copia es honesta.

Ejecute las comprobaciones deterministas antes de la revisión editorial para que el revisor vea un registro coherente. Luego revise el HTML renderizado, no solo el frontmatter: un valor fuente válido sigue siendo un defecto de producción si la plantilla seleccionada lo ignora, lo mapea a la etiqueta incorrecta, oculta la procedencia requerida o genera un canonical que discrepa de la ruta pública. La publicación está completa solo cuando el comportamiento del origen, el renderizado y el destino coinciden.

El campo entity

entity responde «¿de qué tipo de publicación exacto es este documento una instancia?» No responde «¿de qué tema trata esta página?» Esa distinción importa porque dos documentos pueden tratar el mismo tema mientras realizan trabajos diferentes. Una entrada de glosario define «diagnóstico»; un artículo de blog puede informar un cambio en la guía de diagnóstico. Si ambos usan entity = "diagnosis", los sistemas posteriores no pueden elegir de forma fiable la plantilla, las reglas de validación, el grupo analítico o la migración correctos.

Use el prefijo de grupo más el slug del tipo de publicación para variantes dentro de una familia: guide-how-to, guide-ultimate, comparison-a-vs-b y comparison-alternatives-to-x. Use el nombre simple para un tipo independiente: product-page o case-study. Registre el identificador una vez, manténgalo estable y nunca lo cambie porque el tema o la consulta objetivo cambien. Ponga los conceptos temáticos en taxonomy y el lenguaje de consulta en keywords.

Título, H1 y título SEO

Estos valores pueden diferir según el contexto, pero deben describir la misma página. title es el valor predeterminado duradero. h1 es el encabezado visible y puede ser más natural en contexto. seoTitle sirve para el navegador y los resultados de búsqueda y puede agregar un diferenciador conciso, un año legítimo o un sufijo de marca.

Por ejemplo, title = "API Key Rotation", h1 = "How to Rotate an API Key Without Downtime" y seoTitle = "API Key Rotation: Safe Step-by-Step Guide" se alinean en una misma tarea. «Free Security Tool» como título SEO sería engañoso porque cambia la promesa. No cree diferencias meramente para insertar más palabras clave.

Reglas de descripción

La descripción existe para ayudar a un lector cualificado a decidir hacer clic. Manténgala entre 150 y 160 caracteres, incluya el término principal de forma natural, indique el beneficio concreto de la página y agregue un calificador significativo como audiencia, alcance o resultado. Escriba una oración fluida, no una lista de palabras clave.

El término confirma relevancia; la repetición no añade valor. No duplique el título, use «Aprenda todo sobre», haga superlativos no respaldados ni termine a mitad de pensamiento. Los sistemas de búsqueda aún pueden seleccionar texto visible diferente para una consulta.

Fechas, autores y revisores

date conserva la marca de tiempo de la primera publicación. updated registra el último cambio sustancial: una corrección factual, nueva evidencia, instrucciones cambiadas, alcance revisado, recomendación alterada o revisión completa que confirma afirmaciones sensibles al tiempo. Registre lo que cambió en el historial editorial cuando la política lo requiera.

Arreglar puntuación, cambiar un estilo de botón, reconstruir una plantilla o tocar la marca de tiempo solo no restablece updated. Adelantar una fecha sin trabajo detrás es una violación de la política porque les dice a los lectores y a las máquinas que el contenido fue actualizado cuando no lo fue. Es una tergiversación, no una táctica de crecimiento.

Los campos de autor y revisor llevan identidades responsables a las líneas de autoría y a los datos estructurados. El autor es responsable del trabajo. Use reviewedBy solo cuando ocurrió una revisión cualificada, y vincule ambos identificadores a perfiles mantenidos. La página de fundamentos de confianza explica cómo la autoría, las fechas, la evidencia y la claridad de entidad apoyan la confianza sin garantizar clasificaciones.

Por qué FAQ vive en el frontmatter

Una FAQ es contenido visible y una colección estructurada. Almacenarla una vez en [[faq]] permite que la plantilla renderice el acordeón y el FAQPage JSON-LD idéntico, evitando que el esquema oculto quede obsoleto.

Incluya preguntas de seguimiento genuinas visibles para todos los lectores. No duplique encabezados, oculte promociones en las respuestas ni marque preguntas no mostradas. El marcado válido no garantiza una característica de búsqueda.

Sintaxis y ejemplos de código

El contrato multiplataforma mapea campos, no un componente visible. El siguiente envoltorio portátil es válido solo en un archivo de intercambio cuyo importador reconozca directivas de metadatos:

:::frontmatter{entity="guide-how-to" id="reset-api-key" title="How to Reset an API Key"}
description: Reset an API key safely, replace it in dependent services, verify it, and revoke the exposed key without avoidable downtime.
author: maya-chen
:::

Debe normalizarse a metadatos nativos de página durante la importación. No es válido en el cuerpo de un artículo de producción. En Hugo, el mapeo correcto es TOML entre delimitadores +++ en el primer byte, como se muestra en el espécimen en vivo. Deliberadamente no existe un shortcode {{< frontmatter >}}: un shortcode se ejecutaría demasiado tarde y en la región incorrecta del documento.

En WordPress, mapee los mismos campos canónicos a campos de publicación registrados y meta de publicación, por ejemplo post_title, post_excerpt, post_name, _amicited_entity, _amicited_author y _amicited_reviewed_by. Un comentario como <!-- wp:amicited/frontmatter --> o un shortcode [frontmatter] no es válido porque crea un bloque en el cuerpo en lugar de metadatos del documento. Los importadores y editores pueden presentar un panel de metadatos, pero los valores almacenados deben permanecer adjuntos al registro de la publicación.

Ejemplos

Correcto: un registro coherente y responsable

entity = "guide-how-to"
id = "rotate-api-key"
title = "How to Rotate an API Key"
description = "Rotate an API key safely, update every dependent service, verify the replacement, and revoke the old credential without avoidable downtime."
url = "/academy/rotate-an-api-key/"
date = "2026-08-27 10:00:00"
updated = "2026-09-03 14:30:00"
author = "maya-chen"
reviewedBy = "alex-rivera"
keywords = [ "rotate API key", "API key rotation", "revoke API key", "credential security", "API security", "secret rotation" ]
taxonomy = [ "security", "account-administration" ]
canonical = "https://amicited.com/academy/rotate-an-api-key/"

Esto identifica una variante de guía práctica, conserva el historial, nombra a las personas responsables y separa el tema de la identidad de la página. La marca de tiempo de actualización está respaldada por un cambio documentado de instrucciones y una revisión.

Incorrecto: el título repetido como descripción

title = "How to Rotate an API Key"
description = "How to Rotate an API Key"

La descripción no aporta ningún beneficio, alcance ni razón para hacer clic. También desperdicia el espacio de vista previa que podría distinguir esta página de cualquier otro resultado que use el mismo título.

Incorrecto: una entidad reutilizada en dos tipos de publicación

# entrada de glosario
entity = "diagnosis"

# guía editorial
entity = "diagnosis"

El tema compartido ha reemplazado la identidad del tipo de publicación. Use valores registrados como glossary-term y guide-ultimate, luego asigne «diagnosis» a través de taxonomía o palabras clave.

Incorrecto: una fecha de actualización sin diff de contenido

date = "2026-01-15 09:00:00"
updated = "2026-08-27 10:00:00" # solo cambió la fecha

Ninguna edición o revisión sustancial respalda la afirmación de actualidad. Mantenga updated sin cambios u omitido hasta que exista un cambio real y pueda inspeccionarse en el historial editorial.

Marcado de esquema y accesibilidad

Los metadatos proporcionan valores; la plantilla sigue siendo responsable del HTML semántico, el enfoque, el contraste, el propósito del enlace y el texto alternativo.

Reglas de redacción

• Mantenga los identificadores estables, en minúsculas y seguros para máquinas. Nunca recicle un id ni cambie silenciosamente entity después de la publicación.
• Use texto plano en campos similares a títulos. HTML, enlaces Markdown, decoración con emojis y saltos de línea forzados no pertenecen a cadenas de metadatos.
• Mantenga la descripción entre 150 y 160 caracteres y los arreglos de palabras clave entre seis y ocho frases distintas para este manual.
• Use personas reales registradas para los campos de autor y revisor. Nunca cree un revisor ceremonial o una identidad genérica de «Equipo Editorial» a menos que sea una entidad responsable mantenida.
• Use una taxonomía controlada. Las variantes ortográficas y los duplicados singular/plural crean archivos fragmentados.
• Referencie solo imágenes que existan y tengan derechos de publicación. imageAlt describe el contenido informativo de la imagen, no su objetivo SEO.
• Mantenga las respuestas FAQ directas y autocontenidas. Las afirmaciones siguen requiriendo la misma evidencia y divulgación que la prosa en otras partes de la página.
• Nunca coloque secretos, notas privadas, tokens de acceso, instrucciones de embargo, datos personales o afirmaciones legales no revisadas en frontmatter publicable.

Qué tipos de publicación usan frontmatter y dónde

Cada tipo de publicación usa frontmatter en el primer byte. La profundidad requerida cambia con el riesgo, la intención y el esquema, no con el diseño visual.

Lista de verificación de QA

• ¿El archivo comienza con +++, contiene TOML válido y cierra el registro antes del contenido del cuerpo?
• ¿entity es un identificador de tipo de publicación exacto registrado, no el tema, campaña o nombre del sitio?
• ¿id es único y estable, y url coincide con el registro de slugs canónicos?
• ¿title, el opcional h1 y el opcional seoTitle describen la misma página sin cambios de alcance engañosos?
• ¿La descripción tiene entre 150 y 160 caracteres, contiene el término principal de forma natural y ofrece una razón concreta para hacer clic?
• ¿Cada imagen referenciada existe, y imageAlt es preciso para la imagen que se renderiza?
• ¿Se conserva la fecha de publicación, y cada valor de updated está respaldado por un diff sustancial o una revisión documentada?
• ¿Los identificadores de autor y revisor se resuelven en perfiles reales mantenidos, y el revisor nombrado revisó realmente el trabajo?
• ¿Las palabras clave se limitan a seis u ocho frases útiles y los valores de taxonomía se extraen de vocabularios controlados?
• ¿El canonical usa HTTPS, se resuelve en la página preferida y coincide con el sitemap y los enlaces internos?
• ¿Cada elemento de [[faq]] contiene una pregunta útil y una respuesta autocontenida que se renderizan visiblemente con la misma redacción?
• ¿El JSON-LD generado coincide con el contenido visible, usa identificadores estables y pasa la validación de sintaxis sin reclamar tipos no soportados?
• ¿Los secretos, las notas editoriales privadas, las afirmaciones no respaldadas y las divulgaciones solo para el cuerpo están ausentes del registro?

FAQ

¿El frontmatter es visible en la página publicada?

El registro fuente está oculto, pero las plantillas pueden renderizar el título, las personas, las fechas y las FAQ. Otros campos alimentan vistas previas, etiquetas canónicas, feeds, sitemaps, esquema y sistemas internos.

¿El campo entity debe contener el tema o el tipo de publicación?

Identifica el tipo de publicación exacto. Los temas compartidos pertenecen a la taxonomía y las palabras clave, no en lugar de la identidad del documento.

¿Pueden ser diferentes el título, el H1 y el título SEO?

Sí. El H1 puede leerse de forma más natural y el título SEO puede agregar un diferenciador, pero todas las versiones deben hacer la misma promesa.

¿Cuándo debe cambiar la fecha de actualización?

Cámbiela después de una revisión o edición factual sustancial. No la cambie por puntuación, estilo, trabajo de plantilla o una actualización de solo fecha.

¿Por qué las preguntas de FAQ se almacenan en el frontmatter?

El arreglo estructurado permite que una misma fuente renderice tanto la FAQ visible como el FAQPage JSON-LD correspondiente. Esto evita que el esquema se desvíe de lo que los lectores pueden inspeccionar.