Why WordPress Preview Mode Does Not Work and How to Fix It

WordPress preview usually works but shows an older saved state or a cached response. Save the post, page, template, or site; open View → Preview in new tab; refresh that tab; test while logged out; then clear browser and WordPress or host caches. If it still fails, check the URL and template context, revisions, permissions, and editor or plugin compatibility.

Use this five-minute fix first

Confirm that you are editing the correct post, page, template, or site.
Save and wait until WordPress finishes saving.
Choose View → Preview in new tab (or View site in the Site Editor).
Refresh the new tab after every save.
Open the preview in a private window or while logged out. If it is still old, clear the browser cache and purge your WordPress, host, reverse-proxy, or CDN cache.

WordPress.com specifically advises saving changes and refreshing the preview tab each time. The Block Editor and Site Editor provide desktop, tablet, mobile, and resizable preview views.

What WordPress preview actually displays

The editor canvas is a working view. The preview tab renders the front end, including the active theme, templates, template parts, responsive CSS, and front-end scripts. Those layers can make the editor and preview look different even when the content is saved correctly.

In a block theme, page content and Site Editor templates are separate contexts. Editing a template changes every page that uses it; editing a page changes only that page’s content. A homepage may also be assigned to a different page than the one you edited.

Why preview shows old content or a blank page

Cause	What you see	Fix
Stale preview tab	The previous version remains after saving.	Save again, then refresh or close and reopen the preview tab.
Browser cache	Only your browser shows the old page.	Use a private window, hard refresh, or clear cached data.
WordPress cache plugin	Logged-out visitors see old content.	Purge the plugin cache and its page or object cache.
Managed host, reverse proxy, or CDN cache	Several browsers and devices show the same old response.	Purge the host, Varnish, reverse-proxy, or CDN cache, or ask the host which layer must be purged.
Wrong URL or context	You preview a different page, template, or site.	Compare the preview URL, page assignment, template, and site being edited.
Unsaved change or revision	The editor shows a change that the front end does not.	Confirm the save completed; inspect Revisions and restore the intended saved version.
Permissions	A draft preview returns an access error or login screen.	Ask an administrator to verify your role and capability to preview drafts.
Theme or plugin conflict	Preview is blank, broken, or differs only in one editor.	Record versions, then compare with the active theme and plugins disabled in a staging or controlled environment.

WordPress does not include a cache by default. Caching generally comes from an installed plugin or hosting infrastructure.

Diagnose the problem in the right order

Identify the exact URL. Copy the preview address and verify its domain, path, query string, and protocol. Make sure it is the post or page you edited.
Check the editing context. Determine whether you changed post content, a page, a block template, a template part, or Site Editor styles.
Verify the save. Wait for the save indicator to finish. Navigate away and back if the editor is uncertain about the state.
Refresh the preview. Use a full reload after each save; reopening the tab removes more browser state than a normal refresh.
Separate logged-in behavior from public behavior. Test in an incognito window or while logged out. A logged-in administrator may see draft, preview, or personalized output that visitors cannot.
Remove local caching. Clear the browser cache or use a private window. If only one browser is wrong, the issue is local.
Purge site and infrastructure caches. Clear the WordPress cache plugin, host cache, reverse proxy, and CDN in that order. Ask the host which cache layer serves HTML if you cannot identify it.
Inspect revisions. Open Revisions, compare the timestamps and content, and restore the intended saved draft or published update. Autosaves are separate revisions and do not overwrite the actual post.
Check permissions. Confirm that the account can preview unpublished content. Test with an administrator only as a controlled diagnosis, not as a permanent permission change.
Test editor compatibility. Record WordPress, theme, and plugin versions. If the issue exists only in one interface, compare Block Editor, Site Editor, and Classic Editor behavior. The official Classic Editor plugin can restore the older editing screen for this comparison.

Fixes for common symptoms

“Preview shows yesterday’s version”

Refresh the preview after saving, then test logged out. If both logged-in and logged-out views are old, purge the WordPress and host caches. Check whether a CDN is caching HTML longer than expected.

“I can see the change in the editor but not in preview”

Confirm that the change was saved rather than left in an autosave. Check whether the page uses a template or template part that overrides the area you edited. Verify the preview URL points to the same page.

“Preview in a new tab is blank”

Open the URL directly while logged out. An access-control rule, broken script, plugin conflict, PHP error, or incompatible theme can prevent rendering. Check the browser console and server error log, then compare with plugins disabled on staging.

The site may require authentication for drafts or have a membership or security rule blocking preview tokens. Verify your role and draft-preview capability with the site administrator.

“Mobile preview is wrong but desktop is correct”

Use the responsive preview widths, then inspect theme breakpoints, container widths, hidden blocks, and mobile-specific CSS. Preview is showing front-end responsive rules, which may differ from the editor canvas.

Capture the rendered result for a bug report

When support needs visual evidence, capture the front-end URL while logged out and include the timestamp, URL, viewport, browser, and whether caches were purged. A local browser workflow can use Playwright:

npm install playwright
npx playwright install chromium

const { chromium } = require('playwright');
(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage({ viewport: { width: 1440, height: 900 } });
  await page.goto('https://example.com/your-preview-url', { waitUntil: 'networkidle' });
  await page.screenshot({ path: 'wordpress-preview.png', fullPage: true });
  await browser.close();
})();

Use a staging or publicly accessible URL. Do not put administrator passwords or preview tokens in source control or shared logs.

Or skip the browser setup

ScreenshotNeo captures a URL with one request and supports PNG, JPEG, WebP, and PDF output. Its consent step accepts cookie banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing result. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.

See the ScreenshotNeo API documentation for all options. Basic request examples:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/your-preview-url -o preview.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://example.com/your-preview-url"}, timeout=90)
open("preview.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com/your-preview-url' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
require('fs').writeFileSync('preview.webp', Buffer.from(await res.arrayBuffer()));

You can set the viewport, full-page mode, device preset, wait condition, custom headers or cookies, user agent, timezone, geolocation, hidden selectors, custom CSS and JavaScript, resource blocking, cache TTL, and output format. For private previews, pass the required authentication headers or cookies and avoid logging them.

The Free plan includes 1,000 screenshots each month with no card. Paid plans start at $5 for 3,000 shots; every feature is included on every plan. Create a free ScreenshotNeo account.

Performance, reliability, and cost notes

Refreshes and private-window checks are the fastest diagnostics because they do not change site configuration.
Cache purges can be broader than a single page and may temporarily increase origin load. Purge the narrowest layer and path available.
Wait for network idle or a known selector when JavaScript renders the page. A fixed delay alone can be too short or unnecessarily slow.
Full-page screenshots load lazy images and can take longer than viewport captures. Capture only the element or viewport needed for a ticket.
With ScreenshotNeo, failed loads, bot checks, blank pages, timeouts, and cache hits are not billed; clean shots are billed. Use the X-Page-Verdict and X-Billed headers for accounting.

FAQ

Does WordPress automatically refresh preview?

No. Save the change and refresh the preview tab each time.

Are autosaves the same as revisions?

Autosaves are a special revision and do not overwrite the actual post. Revisions contain saved drafts and published updates.

Why does preview work for administrators but not visitors?

Administrators may have draft-preview access or bypass cached public output. Test while logged out to see the visitor response.

Should I disable every plugin?

Use a controlled staging test and record versions first. Disable only enough to isolate a conflict, then restore the working configuration.

Can a screenshot prove that WordPress saved my change?

It proves what a particular URL returned at capture time. Verify the saved state and cache status separately.