El schema Service es el nodo JSON-LD que describe un servicio profesional en lenguaje de máquinas: qué ofreces, quién lo presta, en qué zona y con qué oferta concreta. Para agencias, consultores y profesionales es el equivalente del schema Product de las tiendas: sin él, tus páginas de servicios son texto que los sistemas interpretan adivinando. Aquí va la anatomía completa del nodo, el código real de kom.pe como ejemplo vivo y la implementación paso a paso.
Tabla de Contenidos
- 1 ¿Por qué tus servicios necesitan schema propio?
- 2 ¿Qué campos componen un nodo Service completo?
- 3 El ejemplo vivo: el Service de diseño web de kom.pe
- 4 Cómo implementarlo paso a paso
- 5 ¿Catálogo con precios públicos o sin precios?
- 6 Cómo se ve esto desde el lado del cliente que pregunta
- 7 Errores comunes con el nodo Service
- 8 Preguntas frecuentes
¿Por qué tus servicios necesitan schema propio?
Las tiendas llevan ventaja estructural: el schema Product con precio y disponibilidad está estandarizado y los sistemas lo leen masivamente. Los servicios, en cambio, suelen vivir en páginas sin un solo dato estructurado, y eso obliga a buscadores y asistentes a deducir qué haces, dónde y por cuánto. Cuando un usuario pregunta por una agencia o un especialista en su ciudad, el sistema recomienda con la información que puede leer, y el que declara gana sobre el que insinúa.
Este nodo trabaja en conjunto con tu entidad: el Service apunta por @id a tu Organization, que es la pieza que explicamos a fondo en la guía de GEO para aparecer en ChatGPT, Gemini, Claude y Perplexity. Si quieres ver el sistema completo trabajando para un negocio, eso es lo que montamos en el servicio de posicionamiento GEO.
¿Qué campos componen un nodo Service completo?
| Campo | Qué declara | Nota práctica |
|---|---|---|
| name | El nombre del servicio | Como lo busca el cliente: diseño web, no soluciones digitales |
| serviceType | La categoría del servicio | Término genérico y reconocible del rubro |
| description | Qué incluye, en una o dos oraciones | Concreta y sin adjetivos de folleto |
| provider | Quién lo presta | Referencia por @id a tu Organization, sin redeclararla |
| areaServed | Zona de cobertura | País, región o ciudad según tu operación real |
| hasOfferCatalog | Los paquetes u ofertas del servicio | La joya del nodo: planes con nombre y, si son públicos, precio |
De los seis, los que más diferencian son provider con @id, porque conecta el servicio con una entidad verificable, y hasOfferCatalog, porque convierte tu lista de planes en datos que un asistente puede comparar y citar.
El ejemplo vivo: el Service de diseño web de kom.pe
Este es el patrón que usamos en nuestra propia página de diseño web, con los tres planes públicos. Los montos no incluyen IGV y son los vigentes al 11 de junio de 2026:
{
"@type": "Service",
"@id": "https://kom.pe/diseno-web/#service",
"name": "Diseño web profesional",
"serviceType": "Diseño de páginas web",
"provider": { "@id": "https://kom.pe/#organization" },
"areaServed": "Perú",
"hasOfferCatalog": {
"@type": "OfferCatalog",
"name": "Planes de diseño web",
"itemListElement": [
{
"@type": "Offer",
"name": "Plan Emprende",
"price": "1250.00",
"priceCurrency": "PEN"
},
{
"@type": "Offer",
"name": "Plan Crece",
"price": "1750.00",
"priceCurrency": "PEN"
},
{
"@type": "Offer",
"name": "Plan Pro",
"price": "2250.00",
"priceCurrency": "PEN"
}
]
}
}Dos detalles del ejemplo. El provider no repite nombre ni dirección: referencia el @id de la Organization que ya vive a nivel de sitio. Y los precios van porque en KOM son públicos desde 2017; si los tuyos no lo son, el catálogo funciona igual con nombres de plan sin el campo price, como veremos en un momento.
Cómo implementarlo paso a paso
Paso 1: haz el inventario de servicios y decide qué publicas
Lista tus servicios reales con su zona de cobertura y sus paquetes. Decide qué precios son públicos y cuáles se cotizan. Resultado verificable: una ficha por servicio con todos los campos del nodo resueltos por escrito.
Paso 2: redacta un nodo por servicio
Un Service por cada página de servicio, no un nodo gigante para todo. Adapta el ejemplo de arriba, valida la sintaxis y cuida que name y description coincidan con el texto visible de la página. Resultado verificable: JSON válido por cada servicio principal.
Paso 3: conecta el provider con tu @id
Verifica que tu Organization exista a nivel de sitio con su @id estable, y que cada Service lo referencie exactamente igual, carácter por carácter. Resultado verificable: el mismo @id en la portada y en todos los nodos Service.
Paso 4: inserta cada nodo en su página
El Service de diseño web va en la página de diseño web, no en la portada ni repetido por todo el sitio. Usa el campo de schema de tu plugin SEO o un bloque HTML. Resultado verificable: cada nodo aparece solo en su página correspondiente.
Paso 5: valida y revisa contra lo visible
Pasa cada URL por la prueba de resultados enriquecidos y haz la lectura cruzada: todo lo que el schema declara debe estar visible en la página, precios incluidos. Resultado verificable: validación limpia y cero contradicciones entre nodo y contenido.
¿Catálogo con precios públicos o sin precios?
Aquí hay una decisión comercial disfrazada de técnica. El catálogo con precios convierte tu nodo en la respuesta completa: un asistente puede decir cuánto cuesta tu plan inicial sin pasar por tu web, y eso filtra curiosos y atrae decididos. Nosotros elegimos ese camino hace años, con precios públicos desde 2017, y lo defendemos: la transparencia también es señal para las máquinas, y el cliente que llega sabiendo el precio cierra más rápido.
El catálogo sin precios sigue siendo válido cuando cada proyecto se cotiza: declara los planes con nombre y descripción, omite el campo price y deja que la página explique el rango. Lo que no recomendamos es el punto medio tramposo: precios en el schema que no aparecen visibles en la página, o montos gancho que después nadie sostiene. Esa incoherencia es exactamente lo que un sistema serio detecta y descuenta.
Cómo se ve esto desde el lado del cliente que pregunta
Vale la pena cerrar el círculo con la escena completa. Un gerente le pide a su asistente opciones de agencias de diseño web en el Perú con precios claros. El sistema recupera páginas de servicios: la mayoría describe pasión por los proyectos y resultados garantizados sin un dato estructurado; unas pocas declaran servicio, cobertura, planes y precios en un nodo legible. La respuesta del asistente se arma con las segundas, porque son las únicas que puede citar sin inventar.
Ese es el cambio de fondo que el nodo Service habilita: pasas de competir por adjetivos a competir por datos, y en esa cancha el tamaño de la agencia importa menos que la calidad de la declaración. Un profesional independiente con schema impecable puede ser citado antes que una corporación con páginas bonitas y vacías para las máquinas.
Errores comunes con el nodo Service
Los cuatro que más corregimos. El nodo único genérico, un solo Service llamado servicios digitales que no describe nada y compite contra páginas específicas bien marcadas. El provider redeclarado, con la empresa copiada dentro de cada servicio en versiones ligeramente distintas. El areaServed fantasioso, que declara cobertura nacional para un negocio que solo atiende una ciudad: las máquinas cruzan señales y la incoherencia resta. Y el catálogo desactualizado, con precios viejos en el schema mientras la página ya muestra los nuevos, que es la receta para que un asistente cotice por ti con datos vencidos.
Preguntas frecuentes
¿Uso Service o Product si vendo paquetes cerrados?
Si el paquete es un servicio prestado por personas, Service con su OfferCatalog es lo correcto aunque el precio sea fijo. Product corresponde a bienes, físicos o digitales, que se entregan como artículo. La confusión nace porque ambos aceptan ofertas con precio; la diferencia está en qué es la cosa, no en cómo se cobra.
¿Qué hago si mi precio varía por proyecto?
Declara el catálogo con los nombres y descripciones de tus planes sin campo price, y explica en la página cómo se cotiza. Si manejas un rango honesto, puedes publicarlo en el contenido visible. Lo importante es no inventar un número para el schema: el marcado debe reflejar tu realidad comercial, no decorarla.
¿Conviene un nodo por servicio o uno general de la agencia?
Un nodo por servicio, cada uno en su página. El nodo general no le da a las máquinas nada que comparar ni citar, y desperdicia la oportunidad de que cada página compita por su consulta específica. La agencia como entidad ya tiene su lugar: el nodo Organization, referenciado por todos los Service como provider.
¿LocalBusiness no cubre ya lo que hace Service?
Se complementan: LocalBusiness u Organization describen quién eres, dónde estás y cómo contactarte; Service describe qué ofreces y con qué planes. La arquitectura sana usa ambos conectados por @id: la entidad una sola vez a nivel de sitio, y un Service por cada página de servicio que apunta a ella.
Tu siguiente paso: toma tu página de servicio más vendida, escribe su ficha del paso 1 y arma su nodo con el ejemplo de kom.pe como molde. Valídalo hoy mismo; con el primero funcionando, el resto del catálogo es repetición con criterio.
