WordPress REST API for SEO: the essential checks for site owners

Using the WordPress REST API for SEO sounds more technical than it is, and for most sites it needs no action at all. The API already runs on your install, so the real questions are what it exposes, what it feeds, and when to leave it alone. You can answer all three without writing code. This post walks through each one, with honest limits.

What the REST API does on your site

According to the REST API Handbook on WordPress Developer Resources, the API lets applications interact with your site by sending and receiving JSON objects. It also forms the foundation of the block editor, so it works every time you save a post in Gutenberg. Endpoints are simply URLs that represent posts, pages, taxonomies and other built-in data types. Because any language that makes HTTP requests and reads JSON can use them, mobile apps and external tools connect easily.

Having the API does not earn rankings by itself. It is plumbing, and its SEO value is indirect. The handbook also describes it as a more predictable and structured option than admin-ajax for themes and plugins. So it matters most when other tools or a separate front end need to read your content cleanly.

Reading your own content as data

Every public post has a JSON address. Yoast's developer documentation shows the pattern: /wp-json/wp/v2/posts/607 returns a post by ID, while /wp-json/wp/v2/posts?slug=wordpress-seo returns one by slug. Custom post types use the post type name, which can differ from the archive slug, as with yoast_events versus /events/. Paste a pattern into your own domain and you see what a machine sees.

That view works as a quick sanity check. If a post's JSON lacks content you expect, or a custom post type is missing, you learn something about your configuration before any crawler tells you. Agencies can also pull titles, slugs and dates from many posts into one spreadsheet, which beats clicking through the admin one post at a time.

How Yoast SEO metadata shows up in the API

When Yoast SEO is active, it adds two fields, yoast_head and yoast_head_json, to those standard responses, according to Yoast's developer documentation for its REST API. It also offers a URL-based route: a GET request to /wp-json/yoast/v1/get_head?url= with any page address returns html, json and status properties. The html property holds ready-made meta tags and schema markup, while the json property splits the same data into fields, such as the width and height of the social image.

Yoast recommends the prefabricated html output wherever possible, because it applies the plugin's own logic to combine tags and values. The raw data suits custom builds, and the prefabricated version works as a reference to check them against. This matters most for headless setups, where a separate front end must print title tags, canonical links and structured data itself. If that front end leaves them out, search engines never see your SEO work.

The API carries your SEO data. It does not apply it.

When the metadata endpoint misbehaves

Yoast describes its API as read-only, so POST and PUT calls cannot update metadata. You change titles and descriptions in the editor, then read them back through the API. Sometimes the endpoint returns a 404 status for a post that exists. Yoast says this typically happens when the resource's data is missing from its indexables system, and its documentation lists the fixes.

Treat a status mismatch as a diagnostic signal. Compare the status the API reports with what a browser shows for the same address, because a disagreement means a headless front end may print empty or wrong tags. Yoast also returns full responses for genuine 404 pages, so you can optimise those too. If you do not run a headless site, you can switch the API off with the feature toggle under Site features in the Yoast SEO settings.

What the API exposes, and how to limit it

The handbook says public content is generally publicly accessible through the API, while private content, password-protected content, internal users, custom post types and metadata need authentication or an explicit setting. Private content, custom post types and metadata stay hidden unless authenticated or deliberately exposed. A quick review still makes sense.

1. Open your site's /wp-json/ path in a private browser window, where you are logged out.
2. Request a few post and page addresses and read what comes back.
3. Note any custom post type or field you did not mean to be public.
4. Fix the underlying visibility setting, or ask your developer to do it.

Avoid switching the API off blindly. The block editor depends on it, and modern plugin interfaces use it as well, so restricting it site-wide can interfere with editing. Test any restriction on a staging copy first, and ask your host or developer before you change it on a live site.

Platform openness, sitemaps and where the API fits

Ahrefs studied 1.8 million WordPress sites and 1.8 million Squarespace sites in its Squarespace versus WordPress study. It found that 45.5% of WordPress sites got some monthly search traffic, against 15.1% of Squarespace sites. Ahrefs itself warned that most ranking factors have nothing to do with the platform, and it called the results inconclusive. It did note that Squarespace does not let you edit robots.txt or the XML sitemap, which shows where WordPress's openness helps.

Sitemaps connect back to this topic. Semrush describes a WordPress sitemap as an XML file that lists every URL that should appear in search results. The sitemap feeds crawlers, while the API feeds applications, so each has a different reader. When a URL appears in one but not the other, that can signal a visibility or indexing setting worth checking.

Feeding scaled content through the API

If you build many similar pages from structured data, the API is one way to move that data into WordPress. Our explainer on what programmatic SEO is covers the template-and-data model, and the API can act as the transport between your source and your site. The trade-off is quality, since scale multiplies thin pages as fast as good ones. Before you automate, review your essential SEO tools for WordPress so plugins do not overlap. If you would rather skip the plumbing, Structura is a WordPress plugin that researches, writes and publishes posts on a schedule.

Action steps

1. Inspect your JSON: Open a post's REST address on your domain and confirm the content and fields look right.
2. Test logged out: Use a private window to see what a stranger can read through the API.
3. Check Yoast output: Query the get_head route for key URLs and compare the status with what a browser shows.
4. Compare with your sitemap: Look for URLs that appear in one place but not the other.
5. Change nothing blindly: Test any API restriction on a staging copy before touching the live site.

Frequently asked questions

Does the WordPress REST API affect my rankings?

Not directly. It is an interface for applications. It matters for SEO when a headless front end or external tool depends on it to display your content and metadata.

Is the REST API safe to leave on?

The handbook says it applies the same authentication rules as your site, so private content, internal users and password-protected content need authentication. Review what a logged-out visitor sees.

Can I edit SEO titles through the Yoast REST API?

No. Yoast's API is read-only and does not support POST or PUT calls. Edit metadata in the editor and read it back through the API.

Should I disable the REST API?

Not without testing, since the block editor relies on it. If you only want to switch off Yoast's own endpoint, use the feature toggle in its Site features settings.