structured-data
$
npx mdskill add 686f6c61/alfred-dev/structured-dataGenerate schema.org validated JSON-LD for rich snippets.
- Enables search engines to understand content semantically.
- Depends on schema.org vocabulary and page analysis.
- Selects data types based on page content and relevance.
- Outputs independent script blocks in the page head.
SKILL.md
.github/skills/structured-dataView on GitHub ↗
---
name: structured-data
description: "Generar datos estructurados JSON-LD validados contra schema.org. Activar ante: JSON-LD, schema.org, rich snippets, datos estructurados, marcado semantico"
---
# Generar datos estructurados JSON-LD
## Resumen
Este skill genera datos estructurados en formato JSON-LD basados en el vocabulario de schema.org. Los datos estructurados permiten a los buscadores entender el contenido de una pagina de forma semantica, lo que puede resultar en rich snippets (resultados enriquecidos) que mejoran la visibilidad y el CTR en las paginas de resultados.
El formato JSON-LD es el recomendado por Google porque se inserta como un bloque `<script>` independiente en el `<head>`, sin modificar el HTML visible. Esto lo hace mas facil de mantener y menos propenso a errores que los formatos alternativos (Microdata, RDFa).
## Proceso
1. **Identificar los tipos de schema aplicables.** Analizar cada pagina del sitio para determinar que tipos de datos estructurados son relevantes. Los tipos mas comunes son:
- **Organization**: pagina principal o "Acerca de". Campos obligatorios: `name`, `url`, `logo`. Recomendados: `sameAs` (perfiles sociales), `contactPoint`, `address`.
- **WebSite**: pagina principal. Campos obligatorios: `name`, `url`. Recomendados: `potentialAction` con SearchAction si hay buscador interno.
- **Article / BlogPosting**: paginas de blog o noticias. Campos obligatorios: `headline`, `author`, `datePublished`, `image`. Recomendados: `dateModified`, `publisher`, `description`.
- **Product**: paginas de producto. Campos obligatorios: `name`, `image`, `offers` (con `price`, `priceCurrency`, `availability`). Recomendados: `brand`, `sku`, `aggregateRating`.
- **FAQPage**: paginas con preguntas frecuentes. Campos obligatorios: `mainEntity` con array de `Question`, cada una con `acceptedAnswer`.
- **BreadcrumbList**: todas las paginas con navegacion de migas de pan. Campos obligatorios: `itemListElement` con `position`, `name` e `item` (URL).
2. **Generar el markup JSON-LD para cada pagina.** Crear el bloque `<script type="application/ld+json">` correspondiente. Ejemplo para Organization:
```json
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Nombre de la empresa",
"url": "https://ejemplo.com",
"logo": "https://ejemplo.com/logo.png",
"sameAs": [
"https://twitter.com/ejemplo",
"https://linkedin.com/company/ejemplo"
]
}
```
3. **Combinar tipos cuando corresponda.** Una pagina puede tener multiples bloques JSON-LD. Por ejemplo, la pagina principal puede incluir Organization, WebSite y BreadcrumbList simultaneamente. Cada uno va en su propio bloque `<script>` o se combinan en un array con `@graph`.
4. **Validar el markup.** Antes de publicar, verificar cada bloque contra:
- **Schema Markup Validator** (validator.schema.org): comprueba la sintaxis y el vocabulario.
- **Rich Results Test** (search.google.com/test/rich-results): comprueba si Google puede generar resultados enriquecidos a partir del markup.
Corregir cualquier error o advertencia antes de desplegar.
5. **Insertar en el HTML.** Colocar los bloques JSON-LD dentro del `<head>` de cada pagina. Si se usa un framework o CMS, verificar que no genera duplicados.
## Que NO hacer
- No inventar datos que no existen en la pagina: el markup debe reflejar el contenido visible.
- No usar tipos de schema incorrectos (por ejemplo, marcar un articulo como Product).
- No omitir campos obligatorios, ya que el markup no generara rich snippets sin ellos.
- No asumir que el markup es correcto sin validarlo: un JSON mal formado se ignora silenciosamente.
More from 686f6c61/alfred-dev
- acceptance-criteriaGenerar criterios de aceptación en formato Given/When/Then. Activar cuando el usuario quiera definir criterios de aceptacion, usar formato Given When Then, escribir en Gherkin, saber como determinar que algo esta terminado o establecer una definicion de hecho.
- architecture-docsUsar para documentar la arquitectura del sistema. Activar ante: documentar arquitectura, diagrama del sistema, como funciona el proyecto, vision general tecnica
- bundle-sizeAnalizar y reducir el tamaño de bundles frontend. Activar cuando el bundle sea grande, se quiera reducir tamaño, aplicar tree shaking, configurar lazy loading, usar webpack analyzer o analizar el peso de la aplicacion.
- choose-stackUsar para evaluar y elegir tecnologías con matriz de decisión ponderada. Activar cuando el usuario quiera elegir tecnología, comparar frameworks, decidir entre alternativas técnicas, construir una matriz de decisión, evaluar stack, seleccionar base de datos, elegir lenguaje o comparar herramientas.
- ci-cd-pipelineConfigurar pipeline CI/CD adaptado al proyecto. Activar cuando el usuario quiera configurar CI, crear GitHub Actions, configurar GitLab CI, montar un pipeline de despliegue, automatizar tests o implementar integracion continua.
- code-review-responseUsar al recibir feedback de code review para responder técnicamente. Activar cuando el usuario quiera responder a comentarios de PR, gestionar feedback de code review, resolver comentarios de un revisor, o cuando el revisor pide cambios en el código.
- compliance-checkUsar para verificar cumplimiento RGPD, NIS2 y CRA. También: verificar RGPD, cumplimiento normativo, NIS2, CRA, Cyber Resilience Act, protección de datos, regulación europea.
- copy-reviewRevisar textos publicos: claridad, tono, ortografia y CTAs. Activar ante: revisar textos, mejorar copy, tono de comunicacion, textos de la web, landing page copy
- dependency-strategyEstrategia integral de gestion de dependencias: inventario, evaluacion de riesgo, politica de actualizaciones y documentacion. Usar para auditar el estado global de las dependencias del proyecto.
- dependency-updateRevisar dependencias desactualizadas, con CVEs o end-of-life, y proponer actualizaciones seguras. También: actualizar paquetes, actualizar dependencias, Dependabot, Renovate, versión desactualizada, breaking changes.