I'm thinking through the structured data for our new website, and I've grinded to a halt.

In our new website, we'll have six services we offer, amongst which are Webdevelopment and Online Marketing. All of these have several subservices, for instance Webdevelopment>Front-end, Webdevelopment>Back-end, or Online Marketing>Remarketing.

I figured that, seeing as what we call services aren't really called services, entities like Webdevelopment and Webdevelopment>Front-end should be Creative Works. They're not Services as the schema might imply (delivery service, glass repair service), nor do they have set prices so they can't be Products.

My colleague disagrees, he insists that they're services because it's what we use to make the final product (like a website or a flyer).

Would it make more sense for Webdevelopment>Front-end>Product01 to be structured (with Schema.org) as CreativeWork>CreativeWork>CreativeWork, or as Service>Service>CreativeWork? Or should I structure it differently alltogether?

EDIT: Maybe this info will help: we're going to have one page on our website per 'service', and every 'subservice' gets another page, and the project pages too, ofcourse. Which means that if I use CreativeWorks for services, subservices, and projects, I can jump back and forth through the service hierarchy using exampleOfWork, hasPart, and their inverses.

1 Answer 1


Using a CreativeWork type does not seem to be appropriate. The result of your work is a CreativeWork, but not your work (i.e., the process to create it) itself. So you can use it for finished projects (e.g., in a portfolio), but not for the services you offer.

The Service type seems to be appropriate. I don’t think that there is a relevant semantic difference between a delivery service and web development. In both cases you provide a service for others, offering your expertise and time.

Another type that could be used is Offer. It has some overlap with Service ("An offer to […] to provide a service"), and you have to use Offer if you want to sell (i.e., with a price) your service, but you don’t have to provide a price.

If using Service, and you decide that you want to provide prices at some point, you can use the offers property to provide an Offer for the Service.

By the way, for a list of all your services, you could also use hasOfferCatalogOfferCatalog (where each item can be a Service). This also allows you to convey the hierarchy of related services (by using nested OfferCatalog items). But this doesn’t work so well if you use several pages instead of one page.

  • Yeah I figured CreativeWork wasn't that great for this situation, but I couldn't find how to show hierarchy with Services. I still can't, actually, because you can't add Services to the OfferCatalog, only Things, ListItems and Text.. Or can I add a Thing and give it '@type': 'Service'? Seeing as Service is part of Thing..
    – Sean
    Commented Jun 29, 2016 at 7:03
  • If the expected type is Thing, you can provide an item with type Thing or an item with one of the sub-types of Thing. As Service is a sub-type of Thing (as ony other type in Schema.org, too), using Service as value is expected. -- Re. hierarchy: Yes, Service doesn’t allow this. The only way to relate other services is via the isRelatedTo/isSimilarTo properties.
    – unor
    Commented Jun 29, 2016 at 8:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.