Czy można zaimplementować mikrodane w metatagach?


12

Proszę wziąć pod uwagę następujący kod oznaczony atrybutami w celu zapewnienia mikrodanych:

<!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>

Korzystanie z narzędzia do testowania danych strukturalnych Google daje pozytywne wyniki.

Jest to w porządku w przykładzie testowym, jednak chcemy wdrożyć mikrodane w różnych witrynach, których struktura HTML jest bardzo zróżnicowana. Aby zaimplementować atrybuty w ten sposób, konieczne będzie ręczne edytowanie znaczników HTML w każdej z witryn z osobna.

Najlepiej byłoby, gdybyśmy mogli wywołać pojedynczą funkcję, która pakuje wszystkie mikrodane w jednym miejscu; technicznie jest to możliwe przy użyciu metatagów w następujący sposób:

<!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>

Korzystanie z narzędzia Google do testowania danych strukturalnych daje te same pozytywne wyniki, co pierwszy test.

Dla porównania (nigdy nie robilibyśmy tego na prawdziwej stronie) Narzędzie do testowania danych strukturalnych Google zwraca błąd, jeśli próbujesz przekazać mikrodane ukryte przez CSS.

Tak więc zarówno normalny, jak i znacznik metatagowy dają takie same wyniki, jednak mam pewne obawy z powodu następujących stwierdzeń Google i Schema.org:

https://support.google.com/webmasters/answer/146750 stwierdza:

Zasadniczo Google będzie używać tylko oznaczonych danych, które są widoczne dla użytkownika. Ukryte dane zostaną zignorowane. Jednak w kilku okolicznościach przydatne może być dostarczenie zarówno treści do odczytu maszynowego, jak i czytelnego dla człowieka. Na przykład ciąg tekstowy „Urodziny Elvisa” jest znaczący dla wielu ludzi, ale dla wyszukiwarek nie jest tak znaczący, jak 1935-01-08. Podobnie, ludzcy czytelnicy mogą wywnioskować znaczenie symbolu $, ale przydatne może być wskazanie wyszukiwarkom, czy ceny podane są w peso, czy w dolarach.

http://schema.org/docs/gs.html stany (w związku z użyciem metatagów):

Tę technikę należy stosować oszczędnie. Używaj meta z zawartością tylko do informacji, których inaczej nie można oznaczyć.

http://schema.org/docs/faq.html#13 stwierdza:

Zasadniczo należy oznaczać tylko treść widoczną dla osób odwiedzających stronę internetową, a nie zawartość ukrytych elementów div lub innych ukrytych elementów strony.

Moje pytania to:

  1. Mimo że żadne błędy nie są zwracane, czy wyszukiwarka karałaby nas za używanie metatagów w ten sposób (np. Powielanie treści, ukrywanie informacji itp.)?
  2. Jeśli to nie jest odpowiednie, czy możesz zasugerować jakikolwiek sposób rozdzielenia mikrodanych od rzeczywistych danych, czy też będziemy musieli ugryźć punktor i zaimplementować to w HTML indywidualnie dla każdego przypadku?

2
Tego rodzaju rzeczy stanowią dla Google dość trudną czynność równoważącą. Nawet jeśli dzisiaj nie będzie problemu, Google może łatwo zmienić swoje zasady. Google zarabia na tym, że posiada wyszukiwarkę, która prowadzi użytkowników do najbardziej odpowiednich treści lepiej niż ich konkurenci. Ukryta treść w jakikolwiek sposób może to podważyć, więc zawsze będzie bezpieczniej oznaczać widoczne treści.

@Alohci Tak, boję się tego i nie mogę powiedzieć, dopóki nie będzie za późno! Dzięki za komentarze, myślę, że możemy po prostu ugryźć pocisk w ten i zrobić to normalnie.

Odpowiedzi:


6

Twój plan wykorzystania metadanych dla mikrodanych jest nieopłacalny. Oto najczęściej zadawane pytania Google dotyczące tego, dlaczego nie wyświetla Twoich danych w wynikach wyszukiwania :

Czy Twoje oznaczone treści są ukryte przed użytkownikami?

Zasadniczo Google nie wyświetla treści w fragmentach rozszerzonych, które nie są widoczne dla użytkowników. Nie ukrywa, że zawartość oznaczony dla fragmentów sformatowanych przy użyciu technik, takich jak display:none, value-titleczy CSS. Google zignoruje treści niewidoczne dla użytkowników, dlatego należy oznaczyć tekst, który odwiedzający zobaczą na twoich stronach internetowych.

Jedynym sposobem, aby Google wykorzystał dostarczone przez ciebie mikrodane, jest oznaczenie ich tam, gdzie leży na stronie, widocznym dla użytkownika.

W tym momencie Google nie karze za próby nadużywania fragmentów rozszerzonych innych niż tylko wyłączenie fragmentów rozszerzonych dla tej witryny. Nie zaskoczyłoby mnie, gdyby Google zaczął całkowicie wykluczać witryny z wyników wyszukiwania, gdy Google znajdzie witrynę próbującą użyć mikrodanych w sposób niezgodny z wytycznymi.

Tak długo, jak metadane, które zaznaczasz, są widoczne gdzieś na stronie, Google nie będzie karać Twojej witryny za złośliwe. Jednak ich automatyczne narzędzia wykrywają, gdy zaznaczasz dane w niewidocznej lokalizacji i nie wyświetlają ich w wynikach wyszukiwania.


Dziękuję za odpowiedź. Podnosisz kilka interesujących punktów; implementacja mikrodanych w metatagach wydaje się nieco bezcelowa, jeśli dane nie zostaną wykorzystane!

4

Używanie elementów meta(i link) do mikrodanych jest w porządku. Czasami nie ma nawet sensownej alternatywy, np. Jeśli trzeba podać konkretne kody tam, gdzie nie ma sensu pokazywanie ich użytkownikom.

Google używa nawet metaniektórych przykładów fragmentów rozszerzonych:

  • Produkty i aplikacje :

    <meta itemprop="priceCurrency" content="USD" />
  • Recenzje :

    <meta itemprop="datePublished" content="2006-05-04">
    <meta itemprop="bestRating" content="10"/>
    <meta itemprop="worstRating" content="1"/>
  • Filmy wideo :

    <meta itemprop="uploadDate" content="2015-02-05T08:00:00+08:00"/>
    <meta itemprop="duration" content="PT1M33S" />
    <meta itemprop="interactionCount" content="2347" />
  • Artykuły :

    <meta itemprop="datePublished" content="2015-02-05T08:00:00+08:00"/>

Pytanie brzmi: ile to za dużo (jeśli w ogóle jest limit)? I myślę, że można bezpiecznie założyć, że nie ma twardego limitu, najprawdopodobniej zależy to od różnych dodatkowych czynników.

Rozsądne byłoby jednak, aby Google nie odrzucał znaczników Microdata, jeśli użyto tylko meta/ link. Dlaczego? Ponieważ obsługują one (a czasem nawet zalecają ) JSON-LD do dostarczania danych Schema.org, a to składa się tylko z „ukrytej” treści (mianowicie ukrytego scriptelementu używanego jako blok danych ).

I to właśnie sugerowałbym w twoim przypadku: jeśli nie chcesz dodawać danych strukturalnych poprzez oznaczanie istniejących elementów, użyj JSON-LD .


Dziękuję za sugestie. Rzucę okiem na JSON-LD.

1

Nie mogę komentować, czy to zadziała we wszystkich sytuacjach, ale używamy Schema.org w sposób, który opisujesz - jako meta „treść” na stronach produktów. Dlaczego? Jest o wiele bardziej przenośny i nie niszczy motywów. Pozwala także na bardziej szczegółową kontrolę formatowania danych i pobiera odpowiednie dane zaraz po <body>(znacznie powyżej zakładki). Przychodzą mi na myśl platformy oparte na hakach (a nawet oparte na F&R, takie jak vQmod): nie ma możliwości płynnego F&R ustrukturyzowania wszystkich dyrektyw bez zakodowania tego na widoku.

Nie zauważyliśmy żadnych kar, Google nadal korzysta z danych, nadal umieszcza je w widżetach SERP. Wciąż mamy gdzieś większość danych na stronie, ale jeśli chodzi o większość znaczników, jest ona w 1 hierarchicznym meta kontenerze, używając, content=""jak twój dolny przykład, tylko swojej organizacji opakowanej jako „składającej ofertę”. Teraz nie posuwaj się za daleko - strukturalne rzeczy, takie jak pętla recenzji, bułka tarta, główny opis lub specyfikacje, najlepiej pozostawić poza tym kontenerem. Spróbuj utrwalić je na sztywno.

Większość ludzi powie „nie używaj content=""metas”, ale z drugiej strony większość z nich nigdy tego nie próbowała. To samo dotyczy takich rzeczy, jak bogate znaczniki na listach produktów w kategoriach ... tak, my również łamiemy tę zasadę :) Pamiętaj tylko, że Google nie jest jedyną rybą w stawie RDF. To, co mówi G, nie oznacza „zrobienia lub złamania” w tych okolicznościach używania standardowych formatów danych w sposób, który jest całkowicie akceptowalny dla reszty stawu. Być może nawet dlatego, że sam G zmienia zdanie w przyszłości. Chce przede wszystkim danych, ale powoduje, że kodujesz w danych poniżej / poniżej, podczas gdy meta atrybuty umieszczają je na pierwszym planie, w języku dostępnym dla maszyn.


Uwaga Flaggellum, OpenGraph (OG) i inne działają w podobnej metodzie: jako meta z zawartością w <head>lub <body>. Pinterest lubi przede wszystkim dane ze schematu. Karty na Twitterze działają podobnie. I nie bój się używać słownika danych do bułki tartej i części pętli recenzji, to jest poprawne.
dhaupin

Dzięki za odpowiedź, warto wiedzieć, że metoda metatagu została pomyślnie wdrożona bez żadnych oczywistych kar.
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.