I was poking around on the Google developer site and came across the Structured Data Markup for Job Posting. I would like to take advantage of Structured Data for my job postings. I plan on using JSON-LD for my markup.

Google says the following for the description field:

The full description of the job in HTML format.

The description should be a complete representation of the job, including job responsibilities, qualifications, skills, working hours, education requirements, and experience requirements. The description can't be the same as the title.

Additional guidelines:

  • You must format the description in HTML.

  • At minimum, add paragraph breaks using <br>, <p>, or \n.

  • Valid tags include <p>, <ul>, <li>, and headings <h1> through <h5>.

  • You can also use character-level formatting tags such as <strong> and <em>.

However, if you pop on over to JobPostingon schema.org and look at the JSON-LD sample they have posted, the responsibilities, qualifications, skills, working hours, education requirements, and experience requirements are all separate fields.

So I'm a little confused because the guidelines from Google tell you to wrap; responsibilities, qualifications, skills, working hours, education requirements, and experience requirements all into the description field and mark it up with HTML. But this doesn't seem to line up with the Schema.org guidelines which show everything separated out in their own fields.

To me it seems to make more sense to separate everything into their own field like Schema.org says, but I want my job post to be as Google friendly as possible. What is the correct way to do this?

1 Answer 1


If you absolutely want to qualify for Google’s enhanced job search results, you should of course follow Google’s guidelines, even if they go against Schema.org’s definitions.

If you don’t care about Google’s enhanced job search results, you can simply ignore their documentation and just follow Schema.org. This won’t affect your Google SEO in other areas, you just don’t get that specific feature.

That said, I don’t see a conflict¹ with Google’s guidelines and Schema.org’s defintions in this case:

  • Google describes what the description should (not must) contain. Schema.org places no specific requirements on the content of description.

  • Google doesn’t disallow adding additional properties; they only list the ones they require/recommend, but it’s perfectly fine to provide additional properties, of course. As they say:

    The full definition of JobPosting is available on schema.org/JobPosting.

So you could give a description that Google would like to see, and provide the details in the corresponding properties in addition:

The description should of course be expressed prose, while the properties just contain the data.

Why does Google want to see all this data in the description?


  • Maybe Google doesn’t need these job details. The details they make use of have to be given in the properties they list (baseSalary, employmentType etc.), and everything else is for human consumption (hence why the description should contain HTML), so it’s easier for them to display this text (that should contain everything else users might be interested in) and be done with it.

  • Schema.org has equivalent properties for all the 6 fields Google would like to see in the description, but 5 of these properties are still in Pending (i.e., they are just drafts). Maybe Google only considers them if they go out of Pending.

  • Maybe Google has made research and found out that many job sites don’t provide this data in separate fields, so it would be too hard for these sites to provide these specific properties.

¹ Just one problem:


I think it’s bad practice to put HTML in JSON-LD values, unless the property explicitly expects it. The description property doesn’t expect this, its expected value is explicitly given as Text.

By definition, JSON-LD string values get interpreted as plain text. So adding something like <p> has to be interpreted as part of the content, not as markup. Of course Google now seems to expect it in this specific context, but other consumers likely don’t.

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.