WordPress Content Integration After You Publish

Opening answer

A successful "publish" from an automated blog is not a ranking event. It is a plumbing event. WordPress content integration only counts if the post is actually public, has a public URL, lands in the XML sitemap, is not blocked by a `noindex` rule, carries a self-referential canonical (the page naming itself as the preferred URL), sits in real categories, and can be inspected in Google Search Console. If any of those pieces fail, the REST API (WordPress's built-in HTTP interface for creating and updating posts) can report success while Google never sees the article.

That distinction matters for SMBs and marketing teams that rely on a managed blog rather than an in-house writer. Drafting is the visible half of the job. Indexing is the half that makes the investment show up in search. The rest of this article is the publish-and-index path after a post exists.

What "publish" has to mean in WordPress

WordPress does not treat every saved post as public. The REST API's `status` field accepts `publish`, `future`, `draft`, `pending`, or `private`.[1] Only `publish` (and, when the scheduled date arrives, `future`) produces a page that anonymous visitors and crawlers can fetch. Drafts stay in the dashboard. Pending posts wait for an editor. Private posts require a logged-in user with the right role. Password-protected posts can sit at a public URL while hiding the body, which is a poor match for SEO.

When a remote system creates a post through `POST /wp/v2/posts`, the response includes a `link` field: the public URL WordPress generated for that record.[1] Verify that URL. If the payload left `status` as `draft`, or a review workflow overwrote `publish` with `pending`, the `link` can exist in the API response while the live page returns a login wall or a 404 to Googlebot.

A second, quieter failure is site-wide visibility. Settings, Reading includes "Discourage search engines from indexing this site." When that box is checked, WordPress (since version 5.3, released 2019) outputs `<meta name='robots' content='noindex,nofollow' />` in the document head.[5] Staging copies often ship with that box still checked. The REST API can keep publishing indefinitely. Search engines are asked not to index a single URL.

REST API publishing and application passwords

Remote publishing needs authenticated write access. Cookie authentication works inside wp-admin, but a third-party service cannot rely on a browser session. Since WordPress 5.6 (December 2020), the supported method is Application Passwords: revocable, per-application credentials tied to a user, intended for the REST API, and shown only once at creation.[2] They are sent with HTTP Basic Authentication over HTTPS. WordPress's REST handbook documents the same pattern: generate the password on the user profile, then pass `username:application_password` on HTTPS requests.[3]

That setup is where WordPress content integration most often breaks before a post ever becomes public:

• The credential belongs to an Author who cannot publish, so posts land as `pending` instead of `publish`.
• A security plugin, a reverse proxy, or a host strips the `Authorization` header, and the API returns 401.
• The site is not correctly detected as HTTPS, so Application Passwords never appear on the profile (they are intended for HTTPS requests).[2]
• The password was copied with a typo, or an old password was revoked while the integration still uses it.

None of those errors produce a public blog post. They produce a dashboard item, an email from the integration, or silence. After a publish job, open the URL in a private browser window. If you cannot read the full article without logging in, Google cannot either.

WordPress documents Application Passwords for third-party services that post content or upload media, so you do not hand over the user's main password.[2] Create one per integration. Rotate them when staff or vendors change.

Public URL, categories, and the XML sitemap

A public URL is not enough. Google still has to discover it. A sitemap is a file that lists the pages you consider important so crawlers can find them efficiently.[13] Google can usually discover well-linked sites without one, but new blogs, large archives, and pages with few inbound links benefit from a sitemap. Submitting a sitemap is a hint, not a guarantee that Google will crawl or index those URLs.[6][13]

WordPress core has shipped XML sitemaps since version 5.5. The index lives at `/wp-sitemap.xml`. By default it covers public, publicly queryable post types and taxonomies, author archives, and the homepage. WordPress also adds a reference to that index in the robots.txt file it generates.[4] A single sitemap page holds a filterable maximum of 2,000 entries. The index can list up to 50,000 sitemaps.[4] Google's protocol limit is 50,000 URLs or 50 MB uncompressed per file. WordPress's smaller page size is a performance choice, not a Search Console error.[6]

Two conditions disable that core sitemap. Discouraging search engines in Reading settings turns sitemaps off.[4][5] Many SEO plugins also replace the core index with their own (often `sitemap_index.xml`). Submit the live index in Search Console, not a leftover from staging.

Categories and tags are part of discovery, not decoration. The REST API accepts `categories` and `tags` arrays on create and update, and it exposes `/wp/v2/categories` for term records.[1][14] Core sitemaps include public taxonomies, so category archives become crawl paths into related posts.[4] Posts dumped into Uncategorized, or published with empty term arrays, are technically public and still weakly connected. If a published post is missing from the sitemap, look for a `noindex` flag, a non-public post type, or a plugin excluding that ID. Draft and private posts will not appear.

Canonical URLs that point to themselves

A canonical URL is the address you want search engines to treat as the main version of a page. Google supports `rel="canonical"` as a strong signal, sitemap inclusion as a weaker signal, and redirects as a stronger one still.[9] Google also recommends putting a self-referential canonical on the preferred page itself: the live article should name its own public URL in `<link rel="canonical" href="...">`.[9]

WordPress core does this for singular published posts. `wp_get_canonical_url()` returns the permalink, and `rel_canonical()` prints the tag. If the post does not exist or is not published, the function returns `false` and no canonical is output.[11] That is correct for drafts. It is a problem if an SEO plugin or a cloned theme points the canonical at a staging host, a `?p=123` shortlink, the www/non-www twin, or another article. Search Console may then show "Duplicate, Google chose different canonical than user."[7]

Use absolute HTTPS URLs. Google supports relative canonicals but does not recommend them, in part because a testing site can accidentally become the declared canonical.[9] Keep the sitemap, internal links, and the canonical tag aligned. Do not list one URL in the sitemap and a different URL in `rel="canonical"` for the same page.[9]

Search Console is the proof, not the publish receipt

Google Search Console is the account where you verify a site and see how Google crawled and indexed it. Two tools matter after an automated publish.

The Sitemaps report is where you submit your WordPress sitemap (core uses `/wp-sitemap.xml`, or your plugin's sitemap index). Google records last-read time and processing errors. You can also declare the sitemap in robots.txt with a `Sitemap:` line. WordPress core already does that for `/wp-sitemap.xml` when sitemaps are enabled.[4][6] Submitting the same unchanged sitemap many times a day does not help. A sitemap is a suggestion, not a crawl order.[6]

The URL Inspection tool tests one URL. An owner or full user can request indexing after a live test. There is a quota for individual URL submissions. Requesting the same URL repeatedly does not speed crawling. Crawling can take anywhere from a few days to a few weeks, and a request does not guarantee inclusion in results.[10]

The Page indexing report (Indexing, Pages) is the site-wide view. New content can take a few days to show as indexed. Google does not promise that every URL will enter the index, and duplicate URLs should not be indexed. The report's example list is capped at 1,000 URLs per status and is not guaranteed to be complete.[7] For a specific post, trust URL Inspection over the sampled table.

Indexing failure modes that hide auto-published posts

These are the patterns we see when a WordPress site is "publishing" on a schedule and still absent from search.

The post never became public

The API created a `draft`, `pending`, or `private` record. Or the user connected to the REST API lacks `publish_posts`. Or a password was set on the post. Logged-in editors see a preview. Googlebot does not.

"URL marked noindex"

Google crawled the page, found a `noindex` robots meta tag or `X-Robots-Tag` HTTP header, and skipped indexing.[7][8] Causes include the Reading setting above, an SEO plugin default, a leftover tag on a cloned template, or a security header applied too broadly. `noindex` means "do not show this page in search results."[8] Remove it only if the page should rank. Google has to recrawl the page without `noindex` before it can index it.

A related trap: blocking the URL in robots.txt (the file that tells crawlers which paths they may fetch). Google cannot read the `noindex` tag on a URL it is not allowed to crawl, so the directive is ignored.[8][12] robots.txt is not a way to keep a page out of Google. A disallowed URL can still appear in results if other sites link to it, often with a limited snippet.[12] To keep a page out of results, use `noindex` and allow crawling so Google can see it, or password-protect the page.[12]

"URL blocked by robots.txt"

A `Disallow` rule from staging (`Disallow: /`), a plugin that blocks `/blog/`, or a firewall that treats Googlebot as abuse can all produce this status.[7] If a physical `robots.txt` file exists in the web root, it overrides the virtual file WordPress would have served, including the sitemap line.[5]

"Discovered - currently not indexed"

Google found the URL (often via the sitemap or an internal link) but has not crawled it yet. Search Console documents the typical reason: Google wanted to crawl the URL but expected that doing so would overload the site, so it rescheduled. The last crawl date is empty.[7] This is not a `noindex` bug. It is a crawl-priority state. Server errors, slow responses, huge volumes of low-value URLs, and weak internal links all compete with a new post for crawl time.[7] Repeated "Request indexing" clicks do not make crawling faster, and there is a quota.[10]

"Crawled - currently not indexed"

Google fetched the page and chose not to index it. Search Console says there is no need to resubmit that URL for crawling.[7] This is a quality or duplication decision, not a REST API failure. Near-duplicate posts, thin pages, and parameter variants often stay here on purpose.

Sitemap never submitted, or the wrong sitemap submitted

Core sitemaps help, and robots.txt can point crawlers at `/wp-sitemap.xml`.[4] Search Console still needs a verified property and, for monitoring, an explicit sitemap submission. Staging properties or a sitemap that lists HTTP while the site redirects to HTTPS waste the hint. Google wants fully qualified absolute URLs that match the URLs you want in results.[6]

Staging leftovers and host confusion

www versus non-www, HTTP versus HTTPS, and staging canonicals split signals. Google prefers HTTPS over HTTP when certificates are valid.[9] Pick one host, redirect the rest, and keep the canonical, sitemap, and internal links on that host.

A cloned production site may still discourage indexing, serve `Disallow: /`, point canonicals at staging, or hold Application Passwords that were never issued on the live host. Or posts publish on production while Search Console is verified only on staging. Any of those can make an automated blog look broken when the writer and the API did their jobs.

WordPress content integration: a post-publish checklist

Use this as an operational gate after every automated batch, not as a plugin shopping list.

1. Auth works. A test `GET /wp-json/wp/v2/users/me` with the Application Password returns the connected user over HTTPS.[2][3]
2. Status is `publish`. The stored post is not `draft`, `pending`, or `private`.[1]
3. The public URL loads. A logged-out browser receives 200 and the full article.
4. Search visibility is on. Settings, Reading does not discourage indexing.[5]
5. No `noindex`. View source (or the HTTP headers) for `robots` / `X-Robots-Tag`. Google must be allowed to index the page.[8]
6. Canonical is self-referential. The tag matches the live permalink on the preferred host.[9][11]
7. Categories exist. The REST payload assigned real term IDs, not an empty array.[1]
8. The sitemap lists the URL. Open `/wp-sitemap.xml` or the plugin index and find the post.[4]
9. Search Console knows the sitemap. The Sitemaps report shows a recent successful read.[6]
10. URL Inspection is clean. Coverage shows indexing allowed, robots.txt allowed, and a sensible Google-selected canonical.[7] Request indexing for important new URLs, then wait days, not minutes.[10]

If you already run a WordPress blog and are evaluating how a managed service should connect, our features page outlines the content side, and the FAQ covers common product questions. We wrote separately about whether WordPress's own writing tools replace a managed blog. This piece is the other half of that decision: the index path after the post exists. See AI content for WordPress if you need that comparison.

Practical takeaways

• Treat "API 201 Created" as the start of publish, not the end. Confirm `status`, the public `link`, and a logged-out 200.
• Keep Application Passwords on HTTPS, one per integration, and revoke them when vendors change.[2]
• Core sitemaps at `/wp-sitemap.xml` only help if the site is public and the post is published. Discourage-search-engines disables them.[4][5]
• A sitemap is a discovery hint. Google does not promise to crawl or index every listed URL.[6][13]
• `noindex` and robots.txt do different jobs. Blocking a URL in robots.txt can hide the `noindex` tag Google needs to honor.[8][12]
• "Discovered - currently not indexed" means not crawled yet, often because Google rescheduled to avoid overload.[7]
• Self-referential canonicals and one preferred host prevent staging and duplicate-host accidents.[9]
• Search Console's URL Inspection and Page indexing report prove the plumbing, with a delay of days to weeks.[7][10]

How we can help

DraftDash AI writes and maintains SEO-oriented blog content for teams that need a consistent WordPress publishing cadence without hiring a full-time writer. WordPress content integration is part of that work: the post has to leave draft, keep a public URL, stay in the sitemap, and remain eligible for indexing. Our team plans categories, canonical-safe URLs, and a publish path that marketing leads can inspect in Search Console rather than guessing from a dashboard badge.

Have more questions or want to get in touch? Contact DraftDash.

Citations

1. WordPress REST API Handbook, "Posts" (status values, `link`, categories, tags; last updated January 16, 2024). https://developer.wordpress.org/rest-api/reference/posts/
2. WordPress Advanced Administration Handbook, "Application Passwords" (introduced in WordPress 5.6, December 2020; HTTPS Basic Auth; third-party posting; last updated January 28, 2026). https://developer.wordpress.org/advanced-administration/security/application-passwords/
3. WordPress REST API Handbook, "Authentication" (Application Passwords over HTTPS Basic Auth; last updated June 4, 2025). https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/
4. Pascal Birchler, "New XML Sitemaps Functionality in WordPress 5.5" (Make WordPress Core, July 22, 2020; `/wp-sitemap.xml`, 2,000 URLs per sitemap, robots.txt reference, disabled when search engines are discouraged). https://make.wordpress.org/core/2020/07/22/new-xml-sitemaps-functionality-in-wordpress-5-5/
5. WordPress.org Documentation, "Settings Reading screen" (Discourage search engines; since 5.3 outputs `noindex,nofollow`; last updated June 8, 2024). https://wordpress.org/documentation/article/settings-reading-screen/
6. Google Search Central, "Build and submit a sitemap" (50,000 URL / 50 MB limits; submission is a hint; Search Console Sitemaps report; last updated July 8, 2026). https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
7. Google Search Console Help, "Page indexing report" ("Discovered - currently not indexed"; "Crawled - currently not indexed"; `noindex`; robots.txt; indexing delay of a few days). https://support.google.com/webmasters/answer/7440203
8. Google Search Central, "Robots meta tag, data-nosnippet, and X-Robots-Tag specifications" (`noindex`; robots.txt hides indexing rules; last updated March 24, 2026). https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag
9. Google Search Central, "How to specify a canonical URL with rel=canonical and other methods" (self-referential canonical; sitemap as a weak signal; last updated July 10, 2026). https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
10. Google Search Central, "Ask Google to recrawl your URLs" (days to weeks; quota; request does not guarantee indexing; last updated December 10, 2025). https://developers.google.com/search/docs/crawling-indexing/ask-google-to-recrawl
11. WordPress Developer Resources, `wp_get_canonical_url()` (returns false if the post is not published; introduced 4.6.0). https://developer.wordpress.org/reference/functions/wp_get_canonical_url/
12. Google Search Central, "Introduction to robots.txt" (not a mechanism to keep a page out of Google; disallowed URLs can still be indexed if linked; last updated December 10, 2025). https://developers.google.com/search/docs/crawling-indexing/robots/intro
13. Google Search Central, "Learn about sitemaps" (discovery aid, not an indexing guarantee; last updated December 10, 2025). https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview
14. WordPress REST API Handbook, "Categories" (`GET`/`POST /wp/v2/categories`). https://developer.wordpress.org/rest-api/reference/categories/