Next.js SEO
Cómo añadir JSON-LD en Next.js: esquemas de artículos, productos, software y rutas de navegación
Añade JSON-LD seguro y preciso a páginas App Router de Next.js con ejemplos de Article, Product, SoftwareApplication y BreadcrumbList.
Los datos estructurados deben ser una proyección tipada de la página visible para los usuarios. No son un segundo canal de marketing donde completar los hechos ausentes con suposiciones optimistas.
Elige la entidad antes del esquema
Pregunta qué representa principalmente la página. Una noticia o entrada de blog puede ser Article. Un artículo comprable puede ser Product con Offer. Una página de destino de software puede describir SoftwareApplication. BreadcrumbList describe la jerarquía de navegación y puede acompañar a otra entidad principal.
No elijas un tipo porque su aspecto en búsquedas resulte atractivo. Las funciones de búsqueda tienen requisitos que van más allá de JSON válido, y mostrar marcado no garantiza un resultado enriquecido. El primer objetivo es una descripción precisa y legible por máquinas que coincida con la página visible.
Renderiza JSON-LD en el servidor
Crea el objeto en un Server Component con el mismo registro que renderiza la página. Serialízalo en un script con type application/ld+json. Sustituye los caracteres menor que del valor serializado para impedir que las cadenas controladas por usuarios cierren el elemento script e inyecten marcado.
Mantén pequeño el helper. Debe serializar datos con seguridad, no decidir hechos de negocio. Crea objetos Article, Product o SoftwareApplication en funciones tipadas que validen campos obligatorios y omitan valores opcionales desconocidos.
export function JsonLd({ data }) {
const json = JSON.stringify(data).replaceAll("<", "\u003c");
return (
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: json }}
/>
);
}Describir un artículo
Usa el titular canónico, la descripción, las fechas de publicación y modificación, el autor, el editor, la imagen principal y la URL de la página principal. Actualiza dateModified solo por un cambio sustancial del artículo. Recompilar todo el sitio no es una revisión editorial.
El autor debe coincidir con la firma visible. Si la página acredita a una organización, marca esa organización; si acredita a una persona, usa esa persona. Enlaza páginas estables de autor o editor cuando existan y mantén absoluta la URL del logotipo.
const article = {
"@context": "https://schema.org",
"@type": "Article",
headline: post.title,
description: post.excerpt,
datePublished: post.publishedAt,
dateModified: post.updatedAt,
mainEntityOfPage: SITE_URL + "/blog/" + post.slug,
author: { "@type": "Organization", name: "Acme" },
};Describe un producto que se pueda comprar
Los datos Product pueden incluir nombre, descripción, imágenes, SKU, marca y ofertas. Los valores Offer, como precio, moneda, URL, condición y disponibilidad, deben coincidir con lo que puede ver y comprar el usuario. Genéralos desde el mismo registro de comercio que usa la página.
Las variantes requieren un modelo claro. No publiques varios precios contradictorios como una sola oferta sin explicar el rango, ni declares InStock si el proceso de pago rechaza el artículo. Las reseñas y puntuaciones agregadas deben proceder de datos reales visibles y cumplir las políticas de búsqueda pertinentes.
const product = {
"@context": "https://schema.org",
"@type": "Product",
name: item.name,
image: item.images,
sku: item.sku,
offers: {
"@type": "Offer",
price: item.price.amount,
priceCurrency: item.price.currency,
availability: item.inStock
? "https://schema.org/InStock"
: "https://schema.org/OutOfStock",
},
};Describe con honestidad una aplicación SaaS
SoftwareApplication puede identificar nombre, categoría, sistema operativo, URL y descripción de la aplicación. Añade Offer solo cuando el precio y las condiciones correspondan a una opción visible. Si el precio varía o requiere contacto, represéntalo con precisión en lugar de forzar una oferta engañosa de precio cero.
Los datos estructurados no sustituyen una página de producto clara. La página visible sigue necesitando explicar la función, el público, las funcionalidades, las restricciones, las opciones de precios y la siguiente acción. Excluye afirmaciones como puntuaciones o premios salvo que las respalden la página y las pruebas.
Valida los datos y el comportamiento ante fallos
Valida la sintaxis JSON, la estructura del esquema y los requisitos de la función de búsqueda, y compara después cada valor relevante con la página visible. Prueba comillas, corchetes angulares, Unicode, imágenes ausentes, falta de precio, productos sin stock, artículos sin publicar y cambios de URL canónica.
Si falta un campo opcional, normalmente debes omitir la propiedad. Si falta un hecho de negocio obligatorio, puede que la página todavía no esté lista para ese esquema. Registra los fallos de validación durante el desarrollo y la incorporación de contenido, en lugar de servir valores predeterminados inventados.
Verifica los datos estructurados en la ruta promovida
Adios permite que la misma versión Next.js sirva la página visible y JSON-LD desde un entorno de ejecución persistente. Despliega la candidata, solicita la ruta generada y valida el script del HTML real. Los registros de compilación muestran fallos de serialización o tipos; los del entorno de ejecución ayudan a seguir registros que fallan solo con datos de producción.
Tras superar la comprobación de salud, mantén el dominio personalizado y TLS gestionado asociados a la versión promovida. Repite la validación con la URL canónica porque el host, las redirecciones, los valores de entorno y las URLs de imágenes pueden diferir de una prueba local.
env:
NEXT_PUBLIC_SITE_URL: https://www.example.com
runtime:
name: node@24
port: 3000
health_path: /api/health