@SantosGuillamot I’m opening this thread so we can have a public discussion about the implications of this announcement. I guess that the main questions to answer are:
I’ve been taking a look and the plugin seems great I still have to do more proper tests but I’ll share my findings so far:
The plugin is adding a new field to the REST API named yoast_head, which is a string of all the meta tags (it’s similar to what we’re doing with the REST API Head Tags plugin, but we are adding an array instead of a string). This way, if you go to a post, a category, a tag, etc, in the REST API, you can find this new field with all the meta tag of the specific entity. So if I go to https://myweb.com/wp-json/wp/v2/posts?slug=my-post, I can find this string:
It’s including this info in all the entities that we support with our current plugin, so that’s great .
As mentioned, we are using an array instead of a string, which we think is a better format for frontend packages like @frontity/head-tags package. This way, they can process each element of the array (each meta tag), and modify some aspects. For example, the canonical tag includes by default the url of your backend (wp.mysite.com), and the Frontity package is transforming it to the frontend url (mysite.com), which is the correct one. Doing these changes with a string instead of an array is more difficult.
Apart from that, with the current implementation of the plugin, if users substitute the REST API Head Tags plugin for the new version of Yoast, they have to be aware that they won’t be including some meta tags generated by WordPress (and maybe other plugins), as Yoast is just adding the ones related to the SEO. In most of the cases I guess this isn’t something critical, but it’s something to consider.
If the Yoast team (or other SEO plugins) decide to use an array instead of a string, it would be great to agree about the structure of that array. Right now, we are using three properties for each meta tag: tag , attributes and content, as explained here (you can see a real example at our web API). If other plugins use this same structure, or we agree to a different one, packages like @frontity/head-tags could create a setting to decide which field to use, and just by changing head_tag (our current field) for yoast_head (the one used by Yoast) it would work.
As I said, I still want to look into more things but it seems both implementations could be similar so far
Things I see we’re doing and it seems they are not yet. Correct me if I’m wrong @SantosGuillamot.
Adding the types endpoint to _links with embeddable: true to make sure that information is retrieved in a single fetch when you request a post-type archive using\_embed=true. This how we do it.
Adding all the head tags including the ones generated by WordPress or other plugins, like the XML feed, the REST API link and so on. Can you confirm this Mario?
Parsing the tags in a format that is easy to filter in the frontend. We are using an array and they are using a string of HTML.
Other than that, I’m really happy to see this finally happening!
There’s another thing that is missing in the REST API:
Archive pagination. We need to find a way to expose how the - Page X part is setup in Yoast.
Maybe this could be a new attribute of the title tag:
{
tag: "title",
content: "The Beauties of Gullfoss - Frontity Test - WP Title",
pagination: " - Page %page%"
}
According to @javier this is also important for the descriptions meta as well, although I’m not 100% sure that Yoast supports that in a similar way to the title with - Page X.
I got some questions regarding this SEO solution.
Is there any update planned for merging Frontity’s REST API Head tags solution with Yoast’ REST API endpoints?
However i installed REST API Head tags, but i can’t see them in the DOM. Do i have to include them somewhere?
Regarding adding support for the Yoast REST API endpoints, yes is something that we will do. Right now we are doing some research and collaborating with the Yoast Team making some suggestions. We will keep updating this thread.
I still have to do more proper tests but I’ll share my findings so far:
.
That would be another difference you’re right.