Considere el siguiente código marcado con atributos para proporcionar microdatos:
<!DOCTYPE html>
<html>
<head>
<title>Micro data test - Normal version</title>
</head>
<body>
<div itemscope itemtype="http://schema.org/Product">
<h1 itemprop="name">Product name</h1>
<img alt="" itemprop="image" src="http://placehold.it/200x200" />
<div itemprop="description">This is the product description.</div>
<div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
<meta content="in_stock" itemprop="availability" />
<span content="GBP" itemprop="priceCurrency">£</span><span itemprop="price">100.00</span>
</div>
</div>
</body>
</html>
El uso de la herramienta de prueba de datos estructurados de Google da resultados positivos.
Esto está bien en el ejemplo de prueba, sin embargo, queremos implementar microdatos en una variedad de sitios cuya estructura HTML varía mucho. Implementar los atributos de esta manera requerirá que alguien edite manualmente el marcado HTML en cada uno de los sitios individualmente.
Preferiblemente, nos gustaría poder llamar a una sola función que empaquete todos los microdatos en un solo lugar; técnicamente esto es posible mediante el uso de metaetiquetas de la siguiente manera:
<!DOCTYPE html>
<html>
<head>
<title>Micro data test - Meta tag version</title>
</head>
<body>
<meta itemscope itemtype="http://schema.org/Product" itemref="microName microImage microDescription microOffer" />
<meta id="microName" itemprop="name" content="Product name" />
<link id="microImage" itemprop="image" href="http://placehold.it/200x200" />
<meta id="microDescription" itemprop="description" content="This is the product description." />
<meta id="microOffer" itemprop="offers" itemscope itemtype="http://schema.org/Offer" itemref="microCurrency microPrice microAvail" />
<meta id="microAvail" itemprop="availability" content="in_stock" />
<meta id="microCurrency" itemprop="priceCurrency" content="GBP" />
<meta id="microPrice" itemprop="price" content="100.00" />
<div>
<h1>Product name</h1>
<img alt="" src="http://placehold.it/200x200" />
<div>This is the product description.</div>
<div>£100.00</div>
</div>
</body>
</html>
El uso de la Herramienta de prueba de datos estructurados de Google da los mismos resultados positivos que la primera prueba.
Como referencia (nunca haríamos esto en un sitio real), la Herramienta de prueba de datos estructurados de Google devuelve un error si intenta pasar microdatos ocultos por CSS.
Entonces, tanto el marcado normal como el metaetiquetado producen los mismos resultados, sin embargo, tengo algunas preocupaciones debido a las siguientes declaraciones de Google y Schema.org:
https://support.google.com/webmasters/answer/146750 declara:
En general, Google usará solo datos marcados que sean visibles para el usuario. Los datos ocultos serán ignorados. Sin embargo, en algunas circunstancias, puede ser útil proporcionar una versión de su contenido legible por máquina y legible por humanos. Por ejemplo, aunque la cadena de texto "El cumpleaños de Elvis" es significativa para muchos lectores humanos, no es tan significativa para los motores de búsqueda como el 1935-01-08. Del mismo modo, los lectores humanos pueden inferir el significado del símbolo $, pero puede ser útil decirle específicamente a los motores de búsqueda si sus precios están en pesos o dólares.
http://schema.org/docs/gs.html estados (en relación con el uso de metaetiquetas):
Esta técnica debe usarse con moderación. Solo use meta con contenido para información que de otra manera no se puede marcar.
http://schema.org/docs/faq.html#13 afirma:
Como regla general, debe marcar solo el contenido que sea visible para las personas que visitan la página web y no el contenido en div ocultos u otros elementos de página ocultos.
Mis preguntas son:
- Si bien no se devuelven errores, ¿nos penalizarían los motores de búsqueda por usar metaetiquetas de esta manera (es decir, contenido duplicado, ocultar información, etc.)?
- Si esto no es adecuado, ¿puede sugerir alguna forma de dividir los microdatos de los datos reales o tendremos que morder la viñeta e implementar esto en HTML caso por caso?
Respuestas:
Su plan de usar metadatos para microdatos no es viable. Aquí están las preguntas frecuentes de Google sobre por qué no muestra sus datos en los resultados de búsqueda :
La única forma de hacer que Google use los microdatos que usted proporciona es marcarlos donde se encuentra en la página, visibles para el usuario.
En este punto, Google no está penalizando por tratar de abusar de fragmentos enriquecidos que no sean simplemente desactivar fragmentos enriquecidos para ese sitio. No me sorprendería si Google comenzara a excluir los sitios de los resultados de búsqueda por completo cuando Google encuentra que el sitio está tratando de usar microdatos de una manera que no se ajusta a las pautas.
Mientras sus metadatos que está marcando también sean visibles en algún lugar de la página, es poco probable que Google penalice su sitio como malicioso. Sin embargo, sus herramientas automáticas detectan cuándo está marcando los datos en una ubicación no visible y no lo muestran en los resultados de búsqueda.
fuente
Usar
meta
(ylink
) elementos para Microdata está bien. A veces, incluso no hay una alternativa sensata, por ejemplo, si se deben proporcionar códigos específicos donde no tendría sentido mostrarlos a sus usuarios.Google incluso usa
meta
en algunos de sus ejemplos de Rich Snippets:Productos y aplicaciones de software :
Comentarios :
Videos :
Artículos :
Entonces la pregunta es, ¿cuánto es demasiado (si hay un límite)? Y creo que es seguro asumir que no hay un límite estricto, lo más probable es que dependa de varios factores adicionales.
Sin embargo, tendría sentido que Google no descarte el marcado de Microdata si solo se usa
meta
/link
. ¿Por qué? Porque también admiten (y a veces incluso recomiendan ) JSON-LD para proporcionar datos de Schema.org, y esto consiste solo en contenido "oculto" (es decir, unscript
elemento oculto utilizado como bloque de datos ).Y esto sería lo que sugeriría en su caso: si no desea agregar los datos estructurados marcando sus elementos existentes, use JSON-LD .
fuente
No puedo comentar si esto funcionaría para todas las situaciones, pero usamos Schema.org de la manera que usted describe, como meta "contenido" en las páginas del producto. ¿Por qué? Es mucho más portátil y no destruye temas. También permite un control más granular sobre el formateo de los datos, y obtiene datos relevantes justo después
<body>
(muy por encima del pliegue). Me vienen a la mente plataformas que están basadas en ganchos (o incluso basadas en F&R como vQmod): no hay forma de F&R de manera fluida con todas las directivas en la estructura sin codificarlo todo a la vista.No hemos notado ninguna penalización, Google todavía usa los datos, todavía los pone en widgets SERP. Todavía tenemos la mayoría de los datos en la página en alguna parte, pero en lo que respecta a la mayor parte del marcado, está en un solo metacontenedor jerárquico que usa
content=""
como su ejemplo inferior solo su organización envuelta como "haciendo una oferta". Ahora no lleves esto demasiado lejos: las cosas estructurales como el bucle de revisiones, las migas de pan, la descripción principal o las especificaciones son mejor omitidas de este meta contenedor. Intenta codificarlos a la vista.La mayoría de la gente dirá "no uses
content=""
metas" pero, de nuevo, la mayoría de esas personas nunca lo han intentado. Lo mismo ocurre con cosas como el marcado enriquecido en las listas de productos en categorías ... sí, también rompemos esa regla :) Solo recuerda que Google no es el único pez en el estanque RDF. Lo que dice G no es "hacer o deshacer" en esta circunstancia de usar formatos de datos de emisión estándar de una manera que sea perfectamente aceptable para el resto del estanque. Quizás incluso porque G mismo cambia de opinión en el futuro. Quiere datos por encima / por encima de todo, sin embargo, le hace codificar en los datos debajo / debajo, mientras que las metaatributos lo colocan al frente y al centro, en un lenguaje accesible para la máquina.fuente
<head>
o<body>
. A Pinterest le gustan los datos primero de Schema. Las tarjetas de Twitter funcionan de manera similar. Y no tenga miedo de usar el vocabulario de datos para las migas de pan y partes del ciclo de revisiones, es válido.