Datos estructurados para servicios locales: qué marcar y evitar

12.08.2026 · Lectura: 7–9 min

Los datos estructurados de una página de servicios deben describir lo que el visitante puede leer y contratar de verdad: quién presta el servicio, qué servicio es, dónde se atiende, cómo contactar y qué página es la fuente principal. En España, para una empresa de servicios, el valor no está en añadir muchos tipos de Schema, sino en mantener una relación limpia entre la página visible, la ficha de empresa, los datos legales y el marcado JSON-LD.

La tentación habitual es tratar Schema.org como un atajo SEO. Se añaden propiedades porque existen, se copian ejemplos genéricos y se rellenan campos con promesas que no aparecen en la página. Ese enfoque puede producir una prueba técnica «verde», pero no una web más clara. Una implementación útil empieza al revés: primero se ordena la información visible y después se marca lo que ya está bien explicado.

Qué problema resuelve el marcado en una página de servicios

Google explica que los datos estructurados ofrecen pistas explícitas sobre el significado de una página. No sustituyen el contenido ni obligan al buscador a mostrar un resultado enriquecido, pero ayudan a clasificar entidades, relaciones y atributos. En páginas de servicios locales, esas entidades suelen ser la organización, la sede o área atendida, el servicio concreto y la URL canónica que representa la oferta.

Para una empresa española que vende diseño web, mantenimiento, SEO, campañas SEM o desarrollo de aplicaciones, el objetivo práctico es reducir ambigüedad. La página debe responder sin rodeos: qué haces, para quién, qué incluye la primera conversación, qué limitaciones existen y cómo se solicita una valoración. El marcado solo convierte esa claridad en una capa legible por máquinas.

Organization, LocalBusiness y Service no significan lo mismo

Organization describe a la entidad que publica o presta servicios. Suele encajar en la página principal y en datos generales del sitio: nombre de marca, URL, logotipo si procede y canales públicos confirmados. Conviene usar solo datos estables. Si una dirección es legal, comercial o de atención bajo cita, esa diferencia debe estar clara también para las personas.

LocalBusiness es más delicado. Schema.org lo define como un negocio físico o una sucursal de una organización. Puede ser apropiado si existe una ubicación real vinculada a la atención de clientes o a la presencia local. No debe usarse para inventar una oficina, inflar cobertura o simular cercanía. En un mercado como España, donde la confianza local pesa bastante, forzar una dirección que no representa la operativa real es una mala idea comercial, no solo técnica.

Service describe la prestación concreta: diseño web, mantenimiento, SEO, gestión de campañas, desarrollo de apps o fotografía de producto. Funciona mejor en páginas específicas, no como una lista interminable en la home. Cada servicio debería tener su nombre natural, una descripción visible, un proveedor, una URL y, si se usa un área de servicio, una forma prudente de expresarla sin aparentar sedes inexistentes.

El marcado debe coincidir con lo visible

Las directrices generales de Google para datos estructurados insisten en que el contenido marcado debe estar representado en la página y cumplir las políticas de calidad. Dicho en términos sencillos: si el JSON-LD dice que la empresa ofrece soporte técnico web, la página debe explicarlo; si marca una dirección, el usuario debe poder verla o entender su papel; si menciona una categoría, esa categoría debe corresponder con la oferta real.

Esta regla evita muchos errores. No se marcan opiniones si no hay reseñas visibles y verificables. No se añaden precios si el presupuesto depende de alcance, tecnología e integraciones. Tampoco se usa una ficha local para prometer atención presencial cuando el proceso comercial empieza por formulario o correo.

Coherencia con la ficha de empresa

Cuando existe Google Business Profile, la web y la ficha no deberían contar historias distintas. La ayuda oficial de Google sobre ranking local recomienda mantener la información completa y actualizada: dirección, horario, categoría y otros detalles relevantes. Además, sus directrices para representar un negocio exigen que la empresa pueda hacer contacto presencial con clientes en una ubicación o desplazarse hasta ellos, salvo excepciones.

Por eso, antes de tocar JSON-LD, conviene hacer un inventario: nombre público, dirección mostrada, teléfono si se publica, email, URL principal, categorías, servicios, zonas de atención, fotos y páginas enlazadas. Si la ficha dice una cosa y la web otra, el marcado no arregla el problema; solo lo hace más evidente.

Una estructura razonable para una página de servicio

Una página de servicio local no necesita parecer una ficha técnica. Necesita tener orden. El primer bloque debe explicar el servicio con lenguaje de cliente: qué se entrega y para qué situación encaja. Después pueden aparecer el proceso, los requisitos para valorar el proyecto, los límites honestos y un camino de contacto.

El JSON-LD puede reflejar esa estructura con una entidad principal de tipo Service, un proveedor de tipo Organization o LocalBusiness cuando proceda, y una referencia clara a la URL canónica. Si la empresa tiene varias sedes reales, cada sede necesita sus datos consistentes y sus páginas no deben competir entre sí por el mismo texto genérico. Si solo hay una dirección de contacto, es mejor decirlo así que fabricar una red local que luego no se sostiene.

Qué campos suelen aportar valor

En servicios profesionales, los campos útiles suelen ser pocos y bien mantenidos: name, description, provider, areaServed si está justificado, url y una relación coherente con la organización. En la entidad de empresa, pueden tener sentido name, url, email, address si se publica correctamente y enlaces oficiales en sameAs cuando existen.

La clave es no convertir el marcado en un cajón de deseos. Una lista completa pero dudosa es peor que un marcado corto y verificable. Google recuerda en su documentación que es preferible aportar propiedades completas y precisas antes que intentar rellenar todo con información incompleta o errónea. Esa frase debería estar pegada al monitor de cualquiera que edite Schema en una web comercial.

Validación técnica y validación editorial

Pasar el Rich Results Test o un validador de Schema.org es necesario, pero no suficiente. La prueba técnica responde si el código está bien formado y si ciertas propiedades se reconocen. La prueba editorial responde si el contenido marcado se corresponde con la página, si no exagera la oferta y si no introduce datos que el negocio no quiere o no puede sostener.

Una revisión mínima debería comprobar cinco cosas: la URL canónica coincide; el título y la descripción no contradicen el marcado; los datos de contacto son los aprobados; la dirección no se confunde con domicilio social si cumple otro papel; y las páginas de servicios no compiten con artículos informativos por la misma consulta.

Medir el efecto sin autoengañarse

Google propone comparar páginas antes y después durante varios meses, usando Search Console y URLs concretas. Es una recomendación sobria: los datos estructurados rara vez producen una señal aislada y limpia. Pueden mejorar interpretación, elegibilidad para ciertas apariencias o consistencia de entidad, pero conviven con contenido, autoridad, competencia, enlazado interno, velocidad, reputación local y demanda.

Para una empresa en España, la medición debería mirar consultas de servicio, páginas de entrada, clics orgánicos, formularios y calidad de las solicitudes. Si suben impresiones pero no contactos, quizá el marcado es correcto y el problema está en el copy, la confianza o el ajuste del servicio. Si aparecen consultas de zonas donde no se atiende, el área marcada puede estar demasiado amplia.

Errores frecuentes que conviene evitar

1. marcar datos no visibles o no aprobados por la empresa;
2. usar LocalBusiness sin una presencia local real y explicada;
3. duplicar la misma entidad con versiones contradictorias en varias plantillas;
4. añadir reseñas, valoraciones o precios no verificables;
5. usar categorías genéricas que no reflejan el servicio principal;
6. olvidar actualizar JSON-LD cuando cambia una página, un email o una dirección;
7. confundir validación técnica con impacto SEO demostrado.

El marcado bien hecho acompaña una página clara, ayuda a los buscadores a entenderla y reduce inconsistencias entre web, ficha y datos públicos. En proyectos de diseño web y desarrollo a medida, posicionamiento SEO o mantenimiento web, conviene tratarlo como una capa de precisión, no como una decoración técnica.

Preguntas frecuentes sobre datos estructurados y VOWE

¿Puede VOWE revisar los datos estructurados de una web de servicios?

Sí. Dentro del posicionamiento SEO, el desarrollo web y el soporte técnico, VOWE puede revisar la estructura visible de las páginas, preparar JSON-LD coherente con el contenido y comprobarlo antes de publicarlo. El alcance depende del sitio, el gestor de contenidos, las sedes reales y los servicios que se quieran priorizar.

¿Qué necesita VOWE para preparar una propuesta?

Para una primera valoración hacen falta la URL, las páginas de servicios, los datos públicos de la empresa, las ubicaciones reales si existen, el estado de la ficha de empresa y los objetivos SEO. También conviene indicar qué información no debe publicarse, por ejemplo precios no aprobados o sedes que no atienden visitantes.

¿Añadir Schema garantiza mejores posiciones?

No. Los datos estructurados ayudan a los buscadores a interpretar la página y pueden habilitar ciertas apariencias cuando cumplen las normas, pero no sustituyen una página útil, rastreable, rápida y coherente con la oferta real. La mejora debe medirse con Search Console y datos de negocio, no solo con una prueba técnica válida.

La decisión final debería ser conservadora: marcar menos, pero marcar mejor. Si una propiedad no se puede defender con el contenido visible y con los datos reales de la empresa, es preferible dejarla fuera hasta que la página y el negocio la sostengan.