BASE DE DATOS
¿Cómo se aplican los enlaces internos y JSON-LD en los contenidos de e-commerce?
Tabla de Contenidos — Español
¿Qué tipo se elige para cada contenido?
Para un artículo estratégico de blog, BlogPosting es un candidato adecuado; para un contenido didáctico técnico, TechArticle. Schema.org define el tipo TechArticle para artículos técnicos y procedimentales. Estas elecciones describen el tipo de contenido; por sí solas no dan derecho a un formato especial de resultado en Google.
Que un artículo mencione un producto o un concepto de pago no lo convierte en una página Product. El marcado Product debe basarse en una página de producto real y en los datos del producto correspondiente. Elija los tipos de contenido según el propósito principal de la página, no según la palabra clave.
¿Cómo se preparan los enlaces internos?
1. Determine la pregunta principal de la página. La función de un artículo sobre la elección de infraestructura es ayudar a decidir; la de una guía de migración de datos es enseñar el proceso.
2. Elija la siguiente pregunta relacionada. Desde la expresión “plan de migración” se puede enlazar a la guía de migración de datos y URL. No es necesario enlazar todas las páginas entre sí.
3. Redacte el texto del enlace de forma descriptiva. En lugar de “haga clic aquí”, use un texto que describa el destino, como “reserva de stock y estados de pedido”.
4. Coloque el enlace en el párrafo donde aparece el tema y refuércelo con una lista de contenidos relacionados al final del artículo. Si el destino aún no se ha publicado, el enlace debe esperar en el plan de publicación.
5. Si cambia una dirección, revise a la vez los enlaces y las redirecciones. Un enlace que no se puede rastrear o que lleva a un destino equivocado también confunde al usuario.
¿Con qué información se construye JSON-LD?
Para cada artículo, defina el título, la descripción, el idioma, la URL permanente de la página y el identificador del contenido. El nombre del editor debe coincidir con el nombre de marca visible. El autor y la fecha de publicación solo deben añadirse si existe la información real. En los ejemplos de este paquete no se usan nombres de personas falsos ni fechas de publicación que no se hayan producido.
El código de esquema puede colocarse en un script de tipo application/ld+json dentro del head o del body de la página publicada. La sintaxis JSON debe ser válida, y las comillas y los caracteres especiales dentro del texto deben escaparse correctamente. Si un plugin ya genera la misma información, no añada un segundo registro contradictorio.
¿Es obligatorio el marcado FAQ?
No. Una sección FAQ visible que responda a las preguntas del lector tiene valor por sí misma. Google ha anunciado que la función de resultado enriquecido de FAQ dejará de mostrarse a partir del 7 de mayo de 2026. Por ello, no debe prometerse un resultado de búsqueda desplegable al añadir FAQPage. La disponibilidad del vocabulario de Schema.org y el soporte del buscador para mostrarlo son cuestiones distintas.
La recomendación principal de este paquete de contenidos es BlogPosting o TechArticle. Si se prefiere un marcado FAQPage independiente, solo debe abarcar las preguntas y respuestas que realmente existan en la página. No debe presentarse como un atajo probado para ser citado o para subir en el posicionamiento.
¿Cómo se valida antes de publicar?
Abra la página en el navegador y compruebe el título y el texto. Pase el JSON por una comprobación de sintaxis y el tipo y las propiedades por el Schema Markup Validator. Para las propiedades compatibles con Google puede usarse la Rich Results Test; estas herramientas tienen fines distintos.
Las directrices generales de datos estructurados de Google exigen que el marcado represente el contenido visible. Aunque el código parezca válido, no deben añadirse afirmaciones falsas ni ocultas. La comprobación final es que el texto y los datos digan lo mismo, además de la validez técnica.
¿Cuáles son las preguntas frecuentes?
¿Cuál es el siguiente paso?
Comparta con PROJX Digital el marcado que genera actualmente su sistema de gestión de contenidos; revisaremos los registros duplicados y la correspondencia con el contenido.
