schema.org es un árbol. Thing en la raíz, y luego oficios. Organization es correcto y flojo. LocalBusiness ya admite dirección y horario. TravelAgency es el tipo que le dice a Google qué clase de negocio eres. En portadas de Cusco, Valencia Travel emite TravelAgency, TouristTrip, AggregateRating, PostalAddress, ContactPoint. La mayoría sigue en Organization + WebPage. Misma ciudad, distinta entidad. El validador no es el premio; el informe de GSC sí.

Vocabulario vs sintaxis

El vocabulario es schema.org. La sintaxis, hoy, es JSON-LD: un <script type="application/ld+json"> desacoplado del diseño. Microdatos (itemprop) mueren el día que el diseñador mueve un div. JSON-LD se inyecta desde el child theme o desde Yoast y sobrevive al constructor.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "TravelAgency",
      "@id": "https://www.agencia.com/#org",
      "name": "Agencia Ejemplo",
      "url": "https://www.agencia.com/",
      "telephone": "+51-84-000000",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "Calle Real 123",
        "addressLocality": "Cusco",
        "addressCountry": "PE"
      },
      "sameAs": [
        "https://www.tripadvisor.com/...",
        "https://www.instagram.com/..."
      ]
    }
  ]
}

@id es lo que convierte copias en un grafo. La ficha de tour referencia https://www.agencia.com/#org en brand o provider, no pega otra vez el teléfono. Yoast ya piensa en @graph. El trabajo es que el tipo no se quede en Organization y que sameAs no esté vacío.

El producto no es un Product genérico del todo

Google entiende Product + Offer para precio. En turismo hay un tipo más honesto para el itinerario: TouristTrip (itinerario, proveedor, itinerario por día si te atreves). Valencia ya lo usa. No es obligatorio para el rich result de producto. Es mejor entidad.

Una ficha seria:

  • TouristTrip o Product (o ambos en @type array, si sabes el grafo).
  • Offer con moneda y disponibilidad.
  • provider → @id de la agencia.
  • image, name, description alineados con lo visible.
  • Breadcrumbs en JSON-LD y en HTML. Uno solo de los dos es teatro.

FAQPage solo si las preguntas están visibles. Event solo si hay una fecha de salida concreta, no “todos los días”. Marcar el Camino Inca como Event eterno es mentir el calendario.

Tres validadores, tres verdades

HerramientaQué te diceQué no
Validador schema.orgSi el JSON es parseable y los tipos existenSi Google te va a pintar algo
Rich Results TestSi Google te considera elegible para un resultado enriquecidoCuántas URLs del sitio están mal
GSC → mejorasEl recuento real, con latenciaEl detalle de una URL (para eso, Inspección)

Pasar schema.org y fallar Rich Results es el caso Offer sin moneda: el vocabulario te acepta, Google no. Trabaja contra Rich Results y contra GSC, no contra un plugin que pone un visto verde.

Errores de turismo que el validador no grita lo bastante

  • TouristAttraction en la ficha de tu tour a Machu Picchu. Machu Picchu es la atracción. Tú eres el operador. La atracción puede referenciarse; no te hagas pasar por el santuario.
  • Dirección de un coworking o de un domicilio SUNAT distinto de la oficina que atiende. PostalAddress es lo que Maps va a intentar conciliar.
  • sameAs a un Facebook de otra marca del grupo sin aclarar. Un grafo, una entidad, o entidades distintas con relación parentOrganization.
  • Precio “desde” en Offer.price mientras la página muestra un rango. El número marcado = el número visible.

Orden de implementación

  1. TravelAgency en las cuatro homes, con dirección y sameAs.
  2. Offer + moneda en la plantilla de tour (el artículo del precio).
  3. Breadcrumbs coherentes.
  4. TouristTrip cuando el grafo de Offer esté limpio, no antes.
  5. Reseñas por tour, al final, bien hechas.

El validador en verde el viernes no es el KPI. El KPI es GSC sin errores de producto a 14 días, y una entidad que un humano y una máquina pueden reconocer como la misma agencia en Instagram, Tripadvisor y el .it.