Significado y alcance
El tipo WebSite de Schema.org puede expresar el nombre, la URL y la información relacionada de un sitio en datos estructurados. Es un vocabulario, no una promesa de que el buscador vaya a mostrar una función concreta. Google decide cómo, cuándo y si usa los datos estructurados en la presentación de búsqueda, y puede cambiar el soporte de cada función con el tiempo.
Flujo práctico
Modela solo datos estables y visibles o verificables de otro modo. Usa la URL canónica de la página de inicio, el nombre que ven los usuarios y las relaciones con una Organization solo cuando describan con precisión la misma entidad. JSON-LD es un formato de transporte habitual, pero un grafo sintácticamente válido puede seguir siendo engañoso si combina datos de sitios distintos o ajustes desactualizados.
Qué revisar
Inspecciona el código fuente de la página tras el renderizado y analiza el grafo después del despliegue. Confirma que los identificadores se resuelven como se espera, que los valores coinciden con la identidad visible del sitio y que no hay nodos a nivel de sitio duplicados ni en conflicto. Valida el vocabulario y la sintaxis, y después consulta la documentación de Google para comprobar el soporte actual de cada función, en lugar de fiarte de tutoriales antiguos.
Límites y errores frecuentes
No añadas SearchAction para perseguir una función de visualización retirada o no compatible, y no inventes nombres alternativos, relaciones con un editor ni un endpoint de búsqueda. Los datos estructurados deben aclarar hechos existentes; no pueden reparar un contenido débil, páginas inaccesibles ni una configuración canónica confusa.
Modelar bien la entidad WebSite
Empieza por la página de inicio a la que llegan realmente los usuarios y los rastreadores tras las redirecciones. Registra su URL canónica final, el nombre visible del sitio, cualquier nombre alternativo visible y la relación con una Organization solo si ambos describen la misma entidad pública. Un grafo WebSite no debe repetir un host distinto, un nombre de staging ni una razón social antigua solo porque esos valores sigan en un ajuste del CMS. Los identificadores estables son más útiles que un grafo grande con nodos contradictorios.
{ "@context": "https://schema.org", "@type": "WebSite", "name": "Example", "url": "https://example.test/" }Inspecciona el HTML tras el renderizado, no la vista previa del editor. Analiza cada script JSON-LD y enumera @id, @type, name, url, alternateName y las conexiones con los nodos Organization o WebPage; después compara estos campos con los datos visibles de la página. Las herramientas de validación detectan problemas de sintaxis o de vocabulario, pero no pueden saber si un nombre de sitio antiguo, una URL desactualizada o una promesa no compatible reflejan el negocio real.
Prueba el grafo en la página de inicio, en las variantes de idioma y en las plantillas principales. El marcado a nivel de sitio suele inyectarse de forma global, así que un cambio puede duplicar un nodo o asignar a cada idioma una URL en conflicto. Si los sitios regionales o de idioma son entidades distintas, documenta la relación de forma deliberada en lugar de copiar sin cambios una misma declaración WebSite. Comprueba que las URL canónicas del grafo se resuelven directamente y de forma coherente.
No añadas una propiedad solo porque un tutorial antiguo diga que activa una función de búsqueda. Schema.org define el vocabulario, mientras que Google documenta por separado qué funciones de datos estructurados admite en cada momento y puede cambiarlas. Una entidad WebSite válida puede mejorar la coherencia legible para las máquinas, pero no garantiza un nombre de sitio visible, enlaces de sitio ni ninguna otra mejora en la búsqueda.