Tag: technical seo

Quick answer: When a headless WordPress post is published but does not appear on a Next.js or React website, check the publishing chain in order: WordPress status, public REST API response, frontend slug route, build or cache strategy, webhook delivery, blog listing, and sitemap. A successful WordPress publish is not proof that the public frontend refreshed. Fix the failed step, then test the actual public URL as a logged-out visitor.

This 2026 guide is for businesses using WordPress as a content management system and Next.js or React as the public website. It focuses on headless WordPress blog updates, not general Google indexing. If your article is already visible publicly but absent from search, use our separate React, Next.js and WordPress indexing checklist.

Why does WordPress say Published while the Next.js blog is still outdated?

Headless publishing has at least two independent systems. WordPress stores and exposes content. The frontend decides when to request it and what HTML visitors receive. Between them may sit a deployment service, an application cache, a CDN, an API gateway and a scheduled build. Publishing changes the CMS record; it does not necessarily clear every cache or rebuild every page.

For example, a Delhi NCR agency publishes a new service guide at 10 AM. WordPress displays the post and its image, but the public blog still lists yesterday’s articles. That could mean the frontend uses a static build created before 10 AM, a cached post list, a missing webhook, a route that cannot resolve the new slug, or an outdated CDN response. Each cause requires a different fix.

Start with a seven-step diagnostic flow

1. Confirm publication: Check the WordPress post status is publish, not draft, future or private.
2. Check the content API: Request the published post by slug from the public WordPress REST endpoint. Verify it returns the correct title, content, featured media and updated date.
3. Check the React route: Open the expected /blog/your-slug/ address directly in a private browser window.
4. Identify the rendering strategy: Is the site fully static, built on deploy, server-rendered, or using Next.js caching and revalidation?
5. Trace the webhook: Inspect whether the publish or update event reached the frontend and received a successful authenticated response.
6. Inspect listing and sitemap: A working detail page may still be missing from the archive and XML sitemap if those use separate data sources or caches.
7. Validate SEO output: Confirm the public URL, canonical, metadata, indexability and featured image. Do not equate a working WordPress URL with a working public URL.

Record the time, post ID, slug and expected frontend address at each step. This evidence prevents teams from repeatedly publishing the same article to solve an unrelated cache issue.

1. Confirm the WordPress REST API contains the new article

WordPress’s REST API commonly exposes public posts under /wp-json/wp/v2/posts. Query the exact slug and inspect the response. Published posts should be visible without admin authentication unless the site intentionally restricts the API. A successful response from the CMS narrows the fault to the integration or frontend.

GET https://your-cms.example/wp-json/wp/v2/posts?slug=your-post-slug&_embed

Check the returned status, slug, date, modified, content.rendered and featured media details. If the response is empty, look for incorrect slugs, status filters, API security rules, multilingual variants, or an outdated proxy. Never expose private drafts or API credentials merely to make the public listing work.

When the API contains the article but the frontend does not, stop editing the WordPress post. The next investigation belongs in the frontend fetch, cache or deployment layer. Our WordPress development services cover CMS integrations as well as traditional WordPress builds.

2. Identify whether your frontend is static, server-rendered or cached

These are not interchangeable. A site exported as static files cannot suddenly support server-side revalidation without an appropriate runtime. If a hosting workflow requires a new build for every post, automate that deployment and confirm completion rather than calling a Next.js cache API that is not available in production.

3. Use the correct Next.js revalidation model in 2026

Next.js documentation updated on 3 March 2026 distinguishes applications using cacheComponents: true from the previous caching model. With Cache Components, cached functions can use use cache, cacheLife and cacheTag. A CMS webhook can invalidate the appropriate tag with revalidateTag('posts', 'max'), or target a route with revalidatePath. The exact implementation depends on the installed Next.js version and caching configuration.

Important: In a Route Handler, revalidateTag with the max profile uses stale-while-revalidate behavior. The next request may briefly receive stale content while fresh data is generated. updateTag is intended for Server Actions, not external webhook Route Handlers. Do not copy outdated code that assumes every fetch is automatically cached.

Read the official Next.js revalidation guide and, if you do not use Cache Components, its previous-model caching guide. Match the documentation to your application before deploying changes.

4. Build a secure WordPress-to-Next.js webhook

A typical event flow is: WordPress publishes or edits a post, a trusted server sends an authenticated POST request, a Next.js Route Handler validates it, and the application revalidates the affected blog data or route. The webhook must also handle unpublishing and trashing so deleted posts do not remain publicly visible.

For an App Router project, the following is an illustrative server-side pattern. Adapt authentication, error handling, deployment environment and caching to your actual codebase:

import { revalidatePath, revalidateTag } from 'next/cache';
import { NextResponse } from 'next/server';

export async function POST(request: Request) {
  const secret = request.headers.get('x-revalidate-secret');
  if (!secret || secret !== process.env.REVALIDATE_SECRET) {
    return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
  }

  const body = await request.json();
  const slug = typeof body.slug === 'string' ? body.slug : '';
  if (!/^[a-z0-9-]{1,160}$/.test(slug)) {
    return NextResponse.json({ error: 'Invalid slug' }, { status: 400 });
  }

  revalidateTag('wp-posts', 'max');
  revalidatePath('/blog');
  revalidatePath('/blog/' + slug);
  return NextResponse.json({ accepted: true, slug });
}

The tag name must match the cache tag actually used by your data-loading code. For some setups, revalidating the archive and the specific article path is sufficient; for others, a shared cached query also needs invalidation. Protect the endpoint with a strong secret stored in server-side environment variables, use HTTPS, and consider signed payloads, request-size limits, rate limiting and replay protection for production use.

Do not treat a 200 webhook response as proof that the public page already contains the new article. It confirms the handler accepted the request, not necessarily that a rebuild completed, a stale-while-revalidate cycle finished, or a CDN cache refreshed.

5. Handle publish, edit, unpublish and trash events differently

A robust blog automation does more than create new URLs. Publishing should update the article and listing. Editing should refresh the detail page, related-article cards and any modified date shown publicly. Unpublishing or trashing should remove the post from the archive and sitemap and make its former route return the intended response, often 404 or a carefully justified redirect.

• Publish: Revalidate the post detail, blog archive, category pages and sitemap source where needed.
• Edit: Refresh title, body, excerpt, metadata, featured image and modified date.
• Slug change: Update the new route and plan a redirect from the old address where appropriate.
• Trash or unpublish: Remove the post from public lists and ensure the old page is not incorrectly cached as live.
• Restore: Repopulate the route and internal links after the CMS again reports a published status.

Use idempotent event processing so a retry does not create a second article or trigger conflicting deployments. Include a unique event identifier and post ID in operational logs, but never place webhook secrets in browser-visible JavaScript.

6. Why does the article page work but the blog listing stay stale?

Blog archives often fetch a paginated list while article pages fetch by slug. These queries may have different cache keys, revalidation tags or deployment paths. It is possible to refresh the detail page and forget the archive. Also check sort order, publication date timezone, category filters and pagination. A newly published post may appear on page two if the frontend sorts by a stale date field.

Verify the actual public blog listing after publication. Check both the first page and any relevant category filter. If the article appears only after a hard refresh, inspect browser and CDN caching; if it never appears, inspect the server data query and its invalidation policy.

7. Refresh the public sitemap and canonical URLs

Google discovers the public frontend URL, not merely the WordPress editor address. If your canonical articles live under https://yourdomain.example/blog/, the XML sitemap should list those canonical frontend addresses. A backend sitemap containing CMS URLs is not a substitute for the public sitemap. Generate or revalidate the sitemap from the same published-content source used by the frontend.

After publishing, check the article URL, canonical tag, robots meta tag, sitemap entry, internal links and server-rendered HTML. A sitemap helps discovery but does not guarantee indexing. For detailed crawling and canonical diagnosis, follow our website indexing troubleshooting guide.

8. Do not confuse cache revalidation with Google indexing

Three distinct checks are required. CMS published means WordPress stored the post as public. Frontend live means a visitor can open the correct React or Next.js page with real content. Google indexed means Search Console reports that Google has indexed the public URL. These events can occur at different times, and none automatically proves the next.

Once the frontend is live, inspect the exact URL in Google Search Console and monitor sitemap processing. Do not promise immediate indexing or assume that repeatedly requesting indexing fixes a broken frontend route. If a page returns 404, empty content, noindex, or the wrong canonical, fix that first.

9. Test featured images and SEO metadata after a publish

Headless frontends sometimes render the title but omit the featured image or excerpt because those fields are fetched separately. Confirm the CMS media URL resolves, image dimensions are appropriate, alt text is meaningful and the React component displays it. Also verify the page’s HTML title, meta description, Open Graph image, canonical and article dates.

Large images can create loading problems even when the publishing pipeline works. Our Core Web Vitals INP guide explains interaction responsiveness, while the separate LCP guidance covers main-image loading. Do not solve a stale-content bug by disabling all caching and accidentally making every page slow.

10. Monitor every publication with a real end-to-end test

Build a small verification record for each new article: CMS post ID, expected public slug, publish timestamp, webhook response, deployment or revalidation outcome, public HTTP status, article title in rendered HTML, featured image status, archive visibility and sitemap presence. Retest after edits and removals. This creates evidence for a failure instead of a vague “connected successfully” message.

A practical 2026 rollout plan for Delhi NCR business websites

Day 1: Map the WordPress API, frontend hosting, deployment mode and public URL pattern. Day 2: Test a controlled publish and capture API, webhook and frontend responses. Day 3: Implement version-appropriate cache invalidation or build automation. Day 4: Add edit, trash and slug-change handling. Day 5: Verify public article HTML, archive, metadata, featured image and sitemap. Day 6: Add retries, alerts and idempotency for failed events. Day 7: Run end-to-end tests and document rollback procedures.

This is an example work plan, not a guaranteed one-week fix. A custom deployment pipeline or legacy React build may require more investigation. For WordPress and React integrations across Delhi, Noida, Gurugram and Ghaziabad, our website maintenance team can scope the full publishing chain instead of treating CMS publication as the final step.

Frequently asked questions

Why is my WordPress post published but not showing on my React website?

Because the React frontend is separate from WordPress. Check the public REST API, slug routing, build or cache configuration, and any webhook used to refresh the site.

Do I need to rebuild Next.js every time I publish a blog?

Not always. Fully static exports commonly need a new build. Next.js applications with an appropriate runtime can use version-compatible caching and on-demand revalidation. Check your actual deployment model.

What is a WordPress-to-Next.js revalidation webhook?

It is a server-to-server notification that tells the frontend content changed so affected cached data or routes can be refreshed. It must be authenticated and tested.

Can revalidatePath make a page update instantly?

It marks the specified route for revalidation under the framework’s documented behavior. A Route Handler response alone does not guarantee a visitor already sees new HTML, especially with additional caches or build steps.

Why does the new article open directly but not appear in the blog archive?

The detail route and archive often use separate queries and caches. Revalidate the post list, inspect sorting and pagination, and confirm the category filter includes the new post.

Should a WordPress draft trigger public indexing or a frontend article?

No. Drafts should remain private. Publish only approved content, and make sure unpublish and trash events remove content from public routes and sitemaps.

Does updating a sitemap mean Google has indexed the post?

No. Sitemap inclusion helps discovery. Search Console URL Inspection is needed to check Google’s actual indexing status for the canonical public URL.

What should I check if the featured image does not update?

Confirm the CMS featured media ID and URL, the frontend image fetch and cache, the image component’s remote-domain configuration, and any CDN caching. Test the public image rather than assuming an upload is displayed.

Final takeaway

A reliable headless blog is a connected system, not just a WordPress Publish button. Verify CMS status, API content, authenticated webhook, cache or build refresh, public React route, archive, image, canonical and sitemap before calling the job complete. If your business relies on frequent content updates, Keshav Enterprises’ WordPress and web development team can help review the integration and define measurable publication checks.