Hi Everyone, I would like your suggestions in implementing Structured Data on my homepages.
Structured Data supports domain-level homepage, like for example : https://example.com (this is a domain-level home page)
My websites have a subdirectory-level home page.
For example:
1.For my UK website in English
https://www.example.co.uk/en-gb
2. For my Belgium website in French
3. For my Ireland website in English
@Aleyda Solis Can you please give your suggestions how I can implement the Structured Data for the above website which have a subdirectory-level home page:
My Structured Data - for Ireland website
<script type="application/ld+json">
{
"@context" : "https://schema.org",
"@type" : "Website",
"name" : "Company Name Ireland",
"url" : "https://www.example.ie/"
}
</script>
Please feel free to give your suggestions. Many Thanks
I realized I overlooked the fact your examples make use of different top level domains (as opposed to a single one, which my previous example was based on). Now before making another suggestions I would like to ask you whether the root domains get 301 redirected to their language/region folder? For example, does example.co.uk redirect to example.co.uk/en-gb ? If so, than you can keep things simple by only serving the schema.org/WebSite markup on language/region folder as that's effectively the root of the site. And if not, what do you serve people at the root of each top-level-domain?
@Tony McCreathand I had a chat about this, and IMHO if one follows internationalization standards you could get quite the ways in expressing the situation you're describing. Like Tony already said, Google hasn't documented anything about this, so it's uncertain whether they'll actually consume this, but nonetheless, this could be a way of doing it.
Root of domain
<script type="application/ld+json"> { "@context": "https://schema.org/", "@type": "WebSite", "name": "Example site", "url": "https://example.com", "hasPart": [{ "@type": "WebSite", "name": "Example site en-US", "url": "https://example.com/en-us/", "inLanguage": "en-US", "publisher": ... }, { "@type": "WebSite", "name": "Example site en-GB", "url": "https://example.com/en-gb/", "inLanguage": "en-GB", "publisher": ... }] } </script>
Root of language-Country
<script type="application/ld+json"> { "@context": "https://schema.org/", "@type": "WebSite", "name": "Example site en-US", "url": "https://example.com/en-us/", "inLanguage": "en-US", "isPartOf": { "@type": "WebSite", "name": "Example site", "url": "https://example.com" }, "publisher": ... } </script>
TLDR; I suspect you can only tell Google what the whole domain is about, and I'd recommend using Organization for that.
Are you forcing users to go to those sub-directories via a redirect from the root domains? e.g. redirecting based on language.
Google only documents using WebSite to define how your site search works and says it should only be added to the home page. So I don't think it is of much use to you.
https://developers.google.com/search/docs/appearance/structured-data/sitelinks-searchbox
"Add this markup only to the home page, not to any other pages."
If you are trying to define the business details for your subdirectories, then using Organization may help. Google supports a lot more information for that:
https://developers.google.com/search/docs/appearance/structured-data/organization
Google is still trying to work out how to deal with Organization markup and decide when they will use it. A clue is if it shows up in the Rich Result Test tool, but the rules keep changing, and the Search Console never shows it!
I suspect they would pick one pages Organization markup for the whole domain.
"We recommend placing this information on your home page, or a single page that describes your organization, for instance the about us page. You don't need to include it on every page of your site."
I suspect you want to mark up the information in different languages. Google has not documented any way of doing this yet. JSON-LD has @language, which may be supported in the future.
You should also put an organization on the root page that talks about the larger organization. This is the data Google will most likely work with.
You could experiment by adding Organization entities to each subfolder using the relevant language. The Organization on the root page could reference the others in a subOrganization array. With each sub organization referencing back via parentOrganization. You could also use sameAs between them.