We have several Schema.org items on a single page. For example, a category page has BreadcrumbList markup to show navigation and ItemList markup to show products. A product page has Product markup plus BreadcrumbList markup and (sometimes) several ItemLists (upsells and crossells). ListItems are always Product markup.
Some are implemented as <script type="application/ld+json"> and some are inline markups.
Structured Data Testing Tools show no error or warning.
All these markups are unrelated (physically) to each other. That is they are not included in a single "GlobalPage" markup.
Is it correct to include several markups on a single page?
In fact I used Microdata all the time and I think it is more "natural" but after GWT (now Search Console) showed the only "correct" example for product I change it to ld+json format (w/out seo improvement). SDTT means nothing. GWT still shows "Start with..." even if everything were 5* for years.
I understand that no true answer may exist (untraceable route of Google) but I want to hear an expert opinion on the subject.
Yes, it’s fine to describe multiple entities on the same page. But, if possible, you should use properties to relate these entities.
For your examples:
For a category page, you can use CollectionPage and its properties breadcrumb (for the BreadcrumbList entity) and mainEntity (for the ItemList entitiy that contains the products).
For a product page, you can use ItemPage with the same properties, but here the mainEntity property references a Product entitiy as value. Schema.org also defines properties for related products (but they don’t expect an ItemList as value).
If using different syntaxes on the same page (e.g., JSON-LD and Microdata) this becomes harder; you would have to define a URI for each entity (in JSON-LD with #id, in Microdata with itemid) and reference these URIs as values for the properties. If using only one syntax, you can simply nest the entities.
Related
Inherited a Sitefinity website. There's a news list page, which I discovered is reused by the news detail pages to display content. If I update the list page, the changes are reflected on the detail pages.
Sometimes.
I have a content block that contains a "header" text - updating this in the list page is replicated across the details pages. Adding a javascript widget to the page to inject some custom javascript replicates across the details pages as well.
Adding a new content block or css widget does not replicate across the details pages.
Is there some rhyme or reason to this behavior that I'm missing?
My specifics:
I've successfully created widgets in the MVC several times now. I essentially need to add a new widget to just the news pages. Which seemed simple enough until I discovered that news pages are not individually created pages like... well, pages... but instead are just a content piece that is dynamically inserted in the news widget on the "parent" listing page. At least as far as I can tell that's how it appears to be working.
Adding my widget to the page didn't work, as I explained above. I then tried recreating it in the page itself using javascript, content block, and css widgets, at which time I discovered that the javascript is the only one making it to the details pages. I imagine this has to do with the way javascript widgets actually make it to the page - their placement is selected in advanced options, rather than simply appearing inline.
Sitefinity widgets go beyond presentation, and actually control routing.
As such content widgets (baseline or custom) have two 'modes' that they operate in: list and detail. Slugs for details are automatically generated in the following format.
/News
/News/{News-item-slug}
Of course, a list and a detail should look very different. To accommodate that, the widgets have two separate configurable templates.
So, add your custom html and javascript to the appropriate template to have it only apply in a given mode.
I have 100 dance classes offered by different people on the page x.com/dance-classes.
Each page only lists 20, so you navigate through 5 pages to see "ALL" the dance classes.
x.com/dance-classes
(with a Title, some content describing the results that are displayed on the page and then the results. Results are "ALL DANCE CLASSES" targeting keywords like "Dance classes")
user searches for dance classes for kids/adults from google
x.com/dance-classes?for=kids
(with a different title, results that are may/maynot have been on the /dance-classes page, results are for "ALL DANCE CLASSES FOR KIDS")
http://x.com/dance-classes?for=adults
(with a different title, results that are may/maynot have been on the /dance-classes page, results are for "ALL DANCE CLASSES FOR ADULTS")
Duplicate content?
I want google to index all three URLs as they specifically aim at different sets of keywords. So, rel=canonical is not an option.
This blog by Matt Cutts talks about something relevant to my case. Should i be worried?
https://www.mattcutts.com/blog/search-results-in-search-results/
Your x.com/x?=x is not friendly for SEO. It would be better to change your URLs to this type:
x.com/dance-classes/kids , x.com/dance-classes/adults
Or you can use jQuery and anchor text.
For example:
x.com/dance-classes#Adults , x.com/dance-classes#kids
In the first type, you can set a focus keyword for any page, but I don't know about jQuery and anchor text.
I'm building a WordPress theme. The LocalBusiness entity is stated in the header of the website (present on every page). I would like to "itemref" the business description, which is only present on the home page. I can put the reference in and it will work on the home page, but on every other page there will be a reference to a non-existent item. Is this a bad thing or not?
The itemref attribute can only be used for referencing elements from the same document.
What to do instead?
You could duplicate the description on each page. If you don’t want to have it as visible content, you could use a meta element.
You could omit the description on the additional pages.
You could (and should anyway) provide the url for the item (typically the homepage, if the whole site is about this business), and hope that consumers interested in this item will follow the URL to learn more about it (so they would find the description).
We have a list of faculty and units for a SiteFinity 7.1 site. We have these as custom content items in the site, because we are programming against them and building a few widgets around them.
However, we also have news about these faculty and units, and we'd like to use the existing news items in SiteFinity.
How do we easily tie faculty and units (custom content items) to news items (another content item baked into SiteFinity)? I wasn't sure if we create classifications that list faculty and units, and use these as the grouping mechanism? Or is there an easy way to tie two content items together?
It kind of depends on how you're going to (or how you want to) display the data at the end. Here are a couple of different ways to achieve what you're after.
You're planning on using the stock News widget to display the content.
If this is true, using a custom taxonomy would be pretty easy in this case. Here's a video that outlines this method.
You're planning on displaying the news items in close proximity to one of the custom content types you've created.
In this case, adding a related data field to the custom type would allow you use related content items with widget templates.
Where should I put schema.org tags?
I have 3 options:
at detail page of article
at category page where are articles of
category
at search page
Should I put schema.org tags on all these pages or?
You can use Schema.org on all pages.
Various consumers might find it useful. Why should they have to visit a specific page to see your Schema.org markup for content they already see?
Just make sure that you don’t create several items for the same thing on the same page, unless you denote them as being about the same thing (e.g., with Microdata’s itemid or by using the same subject URI in RDFa).
You could use mainEntity/mainEntityOfPage to denote which item the page is primarily about.