Powtórz użycie znaczników Schema.org / Rich Snippets, tj. Danych LocalBusiness

11

Nie jestem w stanie znaleźć oficjalnego sformułowania i mam nadzieję, że niektóre Rich Snippets / Schema Guru mogą dać mi wgląd w odpowiednie użycie powtarzających się treści, jeśli chodzi o używanie znaczników.

Tworzę witrynę, która chce używać Schema.org jako typu znaczników, a właściciel chciałby jak najwięcej. Nazwa firmy, telefon i adres pojawią się teraz na każdej stronie, czy jest to poprawne, a nawet przydatne użycie fragmentów rozszerzonych na każdej stronie, na której wyświetlane są te informacje.

Na przykład ta informacja pojawia się w nagłówku i stopce każdej strony witryny, a także daje przykład mojego obecnego znacznika, patrz poniżej:

<body itemscope itemtype="http://schema.org/LocalBusiness">
<header>
    <a itemprop="url" href="http://www.domain.co.uk/">
        <img itemprop="logo" src="image.png" alt="Company Name Logo" />
    </a>
    <span itemprop="telephone">01202 000 000</span>
</header>
<div> This is where the content will go</div>
<footer>
  <span itemprop="name">Company Name</span>
  <span itemprop="description"> A small little bit about this company</span>
  <div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
    <span itemprop="streetAddress">Address Goes here</span>
    <span itemprop="addressLocality">Area Here</span>,
    <span itemprop="addressRegion">Region Here</span>
  </div>
 </footer>
</body> !-- Local Business Schema Now Closed -->

Jak widać powyżej, informacje te będą wyświetlane na każdej stronie. Czy powtarzanie użycia tych informacji w formacie Schema.org jest prawidłowe czy złe?

— Simon Hayter
źródło

Niektóre znaczniki semantyczne, takie jak autorstwo, zostały zaprojektowane do powielania na wielu stronach. Nie jestem jednak pewien, o co chodzi z miejscowymi znacznikami biznesowymi, czy w ogóle zmienia to sposób wyświetlania witryny w SERP?

— Stephen Ostermiller

1

Nie, ale 90% schematu nie wpływa na SERPS w żadnej formie ostrej ani w żadnej formie, a użycie tej logiki oznaczałoby, że schemat jest całkiem bezużyteczny - niemniej jednak chcą, aby był używany w jak największym stopniu, nie obchodzi mnie to, nie zła praktyka lub negatywne seo.

— Simon Hayter

6

Microdata nie ma pojęcia „strona”; każda strona jest osobna. Dlatego powinieneś umieścić wszystkie odpowiednie metadane na każdej stronie, na której widoczna jest odpowiednia treść (ale tylko jeden raz na stronę).

Pomyśl o dodatku do przeglądarki, który wyświetla wszystkie pary nazwa-wartość Microdata na pasku bocznym: dlaczego użytkownik powinien odwiedzić konkretną stronę witryny, aby zobaczyć metadane na pasku bocznym?
Pomyśl o kopiowaniu i wklejaniu lub przeciąganiu i upuszczaniu : dlaczego metadane powinny być uwzględnione w schowku tylko podczas kopiowania / przeciągania zawartości z jednej określonej strony witryny?
Pomyśl o agencie, który oferuje dodanie lokalnego adresu firmy do książki adresowej: dlaczego użytkownik powinien odwiedzić jedną stronę witryny, aby umożliwić automatyczne dodanie adresu?

— unor
źródło

mówi się, że „najlepszą praktyką jest utrzymywanie koncentracji i na ogół używanie jednego typu najwyższego poziomu na danej stronie”. Przechodząc LocalBusiness, Organizationitp jako typy najwyższego poziomu (za pośrednictwem tablicy najwyższego poziomu] wydaje się zaprzeczać tej idei powinniśmy dążyć do gniazda. LocalBusinessWewnątrz bardziej konkretnych typów, na przykład Articleczy Productteż po prostu przejść kilka rodzajów najwyższego poziomu jako tablica?

— Ronnie Royston

1

@RonRoyston: Najlepszą praktyką jest używanie właściwości do łączenia elementów, co zwykle skutkuje posiadaniem tylko jednego elementu najwyższego poziomu: WebPage- i Organizationjest publisher, Article/ Productjest mainEntityitp.

— unor

1

Myślę, że znaczniki na każdej stronie są w porządku, ale chciałbym, aby wszystkie instancje używały wspólnego adresu URL (strony o firmie) i wspólnego identyfikatora (itemid w mikrodanych). Będzie to sygnał wskazujący, że wszystkie dotyczą jednego podmiotu.

Odnośny adres URL powinien być stroną o firmie, która zawiera znacznie bardziej szczegółową wersję znaczników. Ponownie, używając tego samego identyfikatora, aby systemy mogły połączyć kropki.

— Tony McCreath
źródło