Wordpress-seo: Expanding out yoast_head in REST API

Created on 29 Jun 2020 · 5Comments · Source: Yoast/wordpress-seo

I'm running WP headless and notices that you now have access to yoast_head via the rest API which I am then pulling in to GraphQL. Having this output in this raw HTML format doesn't make it great to work with things like React Helmet or gatsby-plugin-next-seo.

It would be great if this could be expanded down further to allow access to individual elements

For example
yoast_head.title - would access the title
yoast_head.meta_description - would return the meta content
yoast_head.robots - would return the robots meta content

At the moment there are a number of React / Gatsby plugins that attempt to do this but they're not very reliable. Having this support natively in the Yoast plugin would be amazing.

patch welcome feature request

Source

shanejones

Most helpful comment

Hey Jono!

If you want to have a look at the formats I'm specifically playing with have a look at these libraries.

React Helmet - https://github.com/nfl/react-helmet
This allows us to add tags into the <head> within our React components.

Gatsby SEO Next - https://github.com/ifiokjr/gatsby-plugin-next-seo
This is a wrapper for the above plugin that lets us pass data into generated the head. This is a plugin I'm looking to contribute a bit more to in the future. Would be great for this to line up with Yoast SEO.

With both of these plugins we ideally need the data returning as a string. In my specific example, I'm pulling the REST API into GraphQL.

I think the easest format for anyone to work with would be something like

yoast_head - _best to keep that separate for the people already using it
yoast_head_parts
-- title
-- description
-- ogImage
-- ogDescription
-- ogImage
-- ogImageID

and so on.

A number of other plugins have been made to do this but they're all a bit buggy and I have had pretty mixed results so far. In one example it was pulling the same meta information for all post even when querying a specific WordPress ID. As you can imagine that's something I want to avoid!

Regarding your last point. I think if people were to use this feature they're probably going to pull in what they need. So long as developers know to include all assets in a certain order then all should be fine. I wonder if it might be worth you guys reaching out to the chap behind Gatsby SEO Next to see if he can see up his plugin to work to your exact standard or failing maybe an official Yoast React plugin could be something to add to your roadmap.

I was tempted to have a go at contributing some bits to the plugin around this but want to make sure everything aligns with what your future plans are around this.

shanejones on 29 Jun 2020

👍2

All 5 comments

Hi Shane!

We've been nervous to break out each of the individual pieces, as people have a tendency to make mistakes when reconstructing them. The order, dependencies and logic of which pieces are output when/where is important, so we're keen for people to use the output 'as is', when we've already done the hard work of returning the correct structure based on the request.

That said, I completely understand that there's a data format issue here, which we need to think about if we're going to make it easy for people to plug-and-play with their libraries/frameworks of choice.

Would you just want the _values_ of each tag (e.g., as k/v pairs), or each individual (complete HTML) tag? And, how much does this vary by approach? What are our options/constraints?

And, from a more general perspective, do you have any thoughts on how we might make that output safe / fool-proof, to reduce the risk of people making mistakes with it?

jono-alderson on 29 Jun 2020