How to Add Custom Post Meta to WordPress REST API Responses
WordPress does not automatically return extra information stored with a post in a REST API response. This information is post metadata, often…
On a WordPress site, Yoast SEO builds XML sitemaps to list URLs that search engines can discover. An XML sitemap is a file of URLs; a sitemap index is a directory that links to separate sitemap files, such as files for posts, pages, or categories.
Yoast includes URLs in its sitemap when the site-wide XML sitemap feature is on and the content type is set to appear in search results. When you turn off search visibility for a content type, Yoast removes that type from the sitemap too. Use these settings to find out why a post type appears in the sitemap or is missing, and what to change.
Yoast generates and updates XML sitemaps as content is added or removed. You can find the site-wide switch under Site features > Technical SEO in Yoast SEO settings. When you disable XML sitemaps there, you turn off Yoast’s sitemap feature for the site. The Yoast sitemap documentation describes the setting and automatic updates.
When the feature is on, Yoast provides a sitemap index that links to the sitemap files. Those files can cover posts and pages. They can also cover authors and taxonomies such as categories and tags. Yoast also splits large sitemaps into files containing up to 1,000 URLs each, then lists those files in the index.
The site-wide switch determines whether Yoast produces any sitemaps. For an individual content type, the “Show [type] in search results?” setting controls whether Yoast includes that type in search results and in the sitemap. For example, turning off search visibility for a custom post type removes that type’s URLs from Yoast’s sitemap output. Yoast documents this behavior in its instructions for customizing the sitemap index.
This setting has a broader effect than sitemap inclusion. If you want a content type hidden from search results but still want its URLs listed in a sitemap, the Yoast toggle does not provide that combination. Check the consequences before switching it off.
Yoast also leaves content marked noindex out of the sitemap. This setting tells search engines not to include those pages in search results. Yoast's documentation lists it as another reason content may be missing. A content type that WordPress has not registered as public might not appear in Yoast’s settings. Yoast documents developer filters, which developers use to change sitemap output with code, as another way to exclude types.
Use the sitemap index to find Yoast’s individual sitemap files. When you hide a content type from search results, Yoast removes that type from the sitemap, so the index no longer lists its sitemap entries. Sitemap files for other eligible content remain available.
To check the result, open the sitemap index and look for the sitemap associated with the content type you changed. If the type still appears, confirm that the Yoast setting was saved and that you are viewing the sitemap served by Yoast rather than one generated by another plugin or a physical sitemap file on the server. Yoast warns that competing sitemap sources can cause conflicts.
A sitemap listing does not guarantee that a search engine will index each URL. Google decides independently whether to index a URL, even when it appears in a sitemap.
Yoast provides developer filters, which let developers change sitemap output with code, for settings the WordPress interface does not offer. Developers can use them to exclude post types and taxonomies. They can also exclude authors. Developers can also change the number of entries per sitemap with the wpseo_sitemap_entries_per_page filter. Yoast describes these options in its sitemap customization documentation.
Use the settings interface to control sitemaps site-wide or for a whole content type. Use a developer filter for a narrower rule, such as excluding one type while leaving its search-results visibility setting on. After changing either control, check the sitemap index and the relevant sitemap file to verify the output.
Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.
Take a look at vroni.com