Hoy nos vamos a uno de esos episodios un poco más técnicos pero necesarios para seguir mejorando el posicionamiento local de nuestro negocio.
Y es que seguimos hablando de schema, y como es algo un poco complejo, si lo entendéis y lo aplicáis bien os vais a diferenciar sí o sí de vuestra competencia.
Pero antes decirte que si quieres suscribirte a la newsletter de Negocios Locales. Te dejo aquí el enlace.
O puedes hacerlo desde este breve formulario.
Newsletter
"*" señala los campos obligatorios
Este podcast está patrocinado por Bolsalea: Tu tienda de packaging sostenible en papel y en tela 100% personalizable.
Ya hemos hablado en otras ocasiones de qué es Schema y cómo podéis hacer el schema de la home de vuestro negocio local (de hecho en mi curso consigue más clientes posicionando tu negocio local lo hacemos paso a paso).
Pero voy a explicarlo de una forma más sencilla para que así entendáis cuáles son los próximos pasos que tenéis que hacer y cómo lo debéis conseguir.
Hoy os voy a hablar de mí y os voy a presentar mi knowledge graph.
Si analizamos de forma individual este gráfico personal, me encuentro con entidades independientes que no tienen a priori ninguna relación: Karlos Arguiñano, Dinamarca, mis hijos, un podcast de SEO.
Sin embargo, cuando conectas todos los puntos, todo cobra sentido porque cuentan una historia; mi historia.
Y en eso consiste el schema o etiquetado de datos; en contar una historia para que los buscadores lo entiendan.
Evita poner el mismo schema en todas las páginas.
Cuando un negocio local se decide por fin a generar el schema de su web, en muchas ocasiones pone el mismo código en todas las páginas y eso no es correcto.
Si tú a los buscadores les cuentas la misma historia en todas las páginas, les confundes. ¿Dónde mandan a los usuarios? Esto es algo muy parecido a lo que pasa con el contenido duplicado pero en este caso es etiquetado triplicado, quintuplicado y mucho más.
Entonces, teniendo en cuenta que debes poner un schema diferente es vital que determines que es lo importante de la página y en base a ello especifiques cuál es el etiquetado de datos que necesitas.
Debes ser lo más específico posible y si no encuentras el marcado que se ajuste, utiliza la expresión «aditional type» donde enlazas a wikipedia para que Google entienda mejor tu negocio. Ejemplo: en schema encontramos dentista pero no ortodoncista. Si tu quieres ser realmente especificar a Google de qué va tu negocio le tendrás que tu negocio es del type «dentista» y como aditional type «ortodoncista» y para ello le metes la url de wikipedia.com que lleva a la expresión de ortodoncista.
Si tienes una página de un producto, deberás poner el schema de producto.
¿Qué ocurre? Que si dentro de esa página te haces eco de las preguntas más frecuentes que te hacen respecto a ese producto, crearás un schema de FAQs y aquí cometerás el segundo error más común.
No crees islas de contenido schema, conéctalas.
Como os decía antes, el schema es contar una historia, y para hacerlo tienes que conectar los distintos puntos.
Sin embargo lo que hacéis en la mayor parte de los casos es crear islas de contenido y eso no vale de nada.
En este caso tienes que explicar a los buscadores que las preguntas de esa página corresponden a ese producto en concreto, de lo contrario estaríamos generando islas de contenido que no tienen nada que ver unas con otras
Para relacionar los diferentes elementos se usan lo que se llaman conectores. Hay diferentes conectores y hoy os voy a explicar 5:
- Subject of: Aquí indicas que las FAQs son una parte de la ficha de producto (que es lo más relevante).
- About: Utilizaríamos este conector si lo importante de la página fueran las FAQs y el producto lo secundario.
- Contains: Podemos decir que un hotel contiene un lugar que es un restaurante.
- Area Served: El restaurante sirve a un área en concreto que es el hotel.
- Available service: Un hospital dispone del servicio de este procedimiento médico.
- Knows about: Dentista sabe sobre un procedimiento
Una vez que tenemos creado nuestro schema, lo debemos meter en el heading de cada una de las páginas y comprobar que es correcto, para ello debemos ir al validador de schema.
Nos tiene que decir que todo es correcto pero no solo eso, tenéis que comprobar que todo el schema se ha recogido en un solo item porque si no estaremos haciendo islas de contenido y para eso no hagáis nada.
Como veis un episodio intenso, muy técnico, pero es importante porque quiero que reviséis cuál es el schema que tenéis puesto en vuestras páginas si identificáis islas de contenido ya sabéis que necesitáis conectarlas.
Os dejo aquí una herramienta super útil en la que yo me baso para saber que tipo de conectores debo usar en función del schema que tenga que realizar.
Como me habéis pedido que ponga un ejemplo, aquí os dejo el código que pondría para un tratamiento médico y sus preguntas frecuentes donde uso el conector «subject of».
<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "SurgicalProcedure",
"subjectOf": {
"@type": "FAQPage",
"name": "Preguntas Frecuentes: xxx",
"mainEntity": [
{
"@type": "Question",
"name": "Pregunta 1",
"acceptedAnswer": {
"@type": "Answer",
"name": "Respuesta a Pregunta 1",
"text": "Explicación xxxxxx",
"@id": "https://www.tunegociolocal.com/tratamientoX/#Answer"
},
"@id": "https://www.tunegociolocal.com/tratamientoX/#Question"
},
"description": "el tratamiento X consiste en xxxxxx",
"image": "https://www.tunegocio.com/imagen.jpg",
"name": "TratamientoX",
"url": "https://www.tunegocio.com/tratamientoX/",
}
</script>
Buenos dias Laura.
Gracias por esta información, muy útil
Tienes algún ejemplo web que podamos observar como se implementa en el código??
Gracias
Hola Alex,
Sin problema, he dejado un ejemplo de código en el artículo para que puedas verlo con detalle.