Schema LegalService bien hecho, paso a paso

De cada diez despachos que audito, ocho tienen algún tipo de Schema. Y de esos ocho, siete lo tienen mal o incompleto. No estoy exagerando. La razón es que la mayoría se instala por plugin (Rank Math, Yoast Premium) con valores por defecto que no se revisan. El resultado es un Schema técnicamente presente pero funcionalmente inútil para diferenciar al despacho.

El núcleo mínimo correcto

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "@id": "https://bufete.com/#legalservice",
  "name": "Bufete García Asociados",
  "image": "https://bufete.com/img/fachada.jpg",
  "url": "https://bufete.com",
  "telephone": "+34963123456",
  "priceRange": "€€",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Calle Colón 15, 3º",
    "addressLocality": "Valencia",
    "postalCode": "46004",
    "addressRegion": "Valencia",
    "addressCountry": "ES"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 39.4699,
    "longitude": -0.3763
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "09:00",
    "closes": "19:00"
  }],
  "areaServed": [
    {"@type": "City", "name": "Valencia"},
    {"@type": "AdministrativeArea", "name": "Comunidad Valenciana"}
  ]
}

Los cuatro errores que veo siempre

• priceRange mal usado. Es un indicador de gama (€, €€, €€€, €€€€), no un texto libre. «Desde 60€ la consulta» no es válido. Si no quieres comprometerte a una gama concreta, omite la propiedad entera —es mejor que ponerla mal.
• areaServed con texto plano. «Toda España» no sirve. Tiene que ser un objeto con @type. Si sirves a varias provincias, lista las cinco principales como objetosAdministrativeArea separados.
• NAP inconsistente entre Schema y página. El teléfono del Schema no coincide con el del header. El código postal del Schema es el viejo, el de la página el nuevo. Google detecta la inconsistencia y desconfía. Hay que tener un único origen de verdad para NAP (yo lo guardo en JSON en el repo y lo importo en Schema, header, footer y aviso legal).
• Sin @id. Sin @id no puedes anidar entidades (que la página de servicio apunte al LegalService padre, que las reviews apunten al mismo). Esto se nota cuando el Knowledge Graph del despacho se construye flojo —faltan piezas que Google podría conectar y no conecta.

Service como hijo de LegalService

Cada página de servicio (herencias, despidos, cláusula suelo) merece su propio Service que apunta al LegalService padre vía provider. Esto es lo que permite que las páginas de servicio aparezcan en el Maps con CTR más alto.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://bufete.com/servicios/herencias/#service",
  "serviceType": "Asesoramiento en herencias y testamentos",
  "provider": { "@id": "https://bufete.com/#legalservice" },
  "areaServed": { "@type": "City", "name": "Valencia" },
  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "Servicios de herencias",
    "itemListElement": [{
      "@type": "Offer",
      "itemOffered": {
        "@type": "Service",
        "name": "Primera consulta orientativa"
      }
    }]
  }
}

Y un último detalle: valida siempre en validator.schema.org (no en Rich Results Test de Google, que es más permisivo). El validador estricto detecta los problemas que Google no te dirá pero que afectan a cómo se construye tu entidad. Si Schema.org dice que el campo es inválido, lo es —da igual lo que diga Rich Results.