Remove Theme Demo Content Before Launch: a WordPress REST API Audit

Premium WordPress themes ship a beautiful demo – and if you import it, that demo content is now your site. Before you go live (and especially before you apply for ad networks), you have to find and strip every leftover demo post, menu, and page-builder block. The fastest, most repeatable way to do it is through the WordPress REST API.

Demo content isn’t just untidy. Ad networks reject sites that look like an unfinished template, search engines index the placeholder text, and visitors lose trust the moment they hit a “Books / Games / Movies” menu that goes nowhere. The good news: almost all of it is discoverable and fixable over REST.

Why leftover demo content blocks a launch

A theme demo is designed to look full, so it plants content in several places at once:

• Demo posts – often dozens, styled to fill category blocks.
• Demo menus – fake top bars, “login/register” links, sample dropdowns, all pointing at #.
• Page-builder blocks – the front page and post templates carry demo category blocks and demo ad banners advertising the theme itself.
• Footer – a demo “about us” blurb and a “Made with <Theme>” copyright.

Left in place, this is the single most common reason a new site fails an ad-network review and reads as abandoned to a first visitor.

A theme demo is a showroom, not your house. Before launch, everything in it is a placeholder you haven’t replaced yet.

Find it: diff against the official demo

The reliable way to identify demo posts is to compare your site to the theme’s published demo. Both expose the REST API, so fetch the demo’s post list and your own and match on title and slug:

# the theme's official demo
curl -s "https://demo.example-theme.com/wp-json/wp/v2/posts?per_page=100&_fields=slug,title"
# your site (authenticated for drafts too)
curl -s -H "Authorization: Basic $APP_PW" "https://your-site/wp-json/wp/v2/posts?status=publish,draft&per_page=100&_fields=slug,title"
Code language: Bash (bash)

Any post whose title or slug matches the demo is demo content. Do the same read for pages (/wp/v2/pages), menus (/wp/v2/menu-items), and categories – leftover “Politics / Food / Celebrity” terms are a giveaway. This turns “hunt for demo stuff” into a deterministic list.

What the REST API can and can’t reach

The core content is fully REST-addressable, and that’s most of the job:

• Posts, pages, menus, settings – read and write over /wp/v2/*. Demote demo posts to draft (status=draft), fix menu URLs, publish real pages, set the privacy page.
• The static front page is a normal Page, so a page-builder’s blocks live in its editable content – you can fix a block’s category or remove a demo ad banner via the page content.

What standard REST cannot see is the page builder’s own storage: the theme options panel (footer, social, logo) and the builder’s template library (header/footer/archive templates). For those, add a small read-only REST endpoint with a code-snippet plugin that returns the relevant options and template bodies – enough to locate the exact demo strings. Then apply the change with a one-time setter snippet that writes fixed values and runs once. Resist the urge to build a general “set any option over REST” endpoint: that’s a backdoor, not a tool.

Read widely over REST; write narrowly with a one-time snippet. A generic option-writer endpoint is a security hole wearing a convenience costume.

Audit go-live readiness

Removing demo content is half of launch-readiness; the other half is a short, repeatable WordPress go-live audit you can run over REST:

• Maintenance response – while a “coming soon” wall is up, it should return HTTP 503, not 200, or search engines can index the placeholder. (See our note on maintenance mode and the 503 status.)
• Indexing – robots.txt and the sitemap resolve; no site-wide noindex; search visibility on at launch.
• Legal pages – privacy policy, about, contact, and (for ad-supported sites) an advertising disclosure, all published and linked.
• Navigation – every menu link resolves; custom links don’t 404 after a permalink change.
• Repetition – if the homepage has more article “slots” than you have articles, the same posts repeat across blocks; trim blocks or publish more. Fast sites help here too – see WordPress speed optimization and confirm image sizes exist via the REST API image-size check.

Always verify the public-facing checks anonymously (no login): a maintenance plugin often exempts the logged-in admin, so an authenticated request can show you a clean page the public never sees.

The short version

Importing a theme demo makes the demo your content, and it must go before launch. Find it by diffing your posts/pages/menus against the theme’s official demo over the REST API. Fix the core (posts, pages, menus, settings) directly through /wp/v2/*; for the theme panel and page-builder templates that standard REST can’t reach, use a read-only snippet to locate the demo strings and a one-time setter snippet to change them – never a generic write endpoint. Finish with a go-live audit: maintenance returns 503, indexing is clean, legal pages exist and link, navigation resolves, and the homepage has enough real articles not to repeat. Verify every public check anonymously.

Frequently Asked Questions

How do I find which posts are theme demo content?

Compare your site to the theme’s official demo through the REST API: fetch both post lists (/wp-json/wp/v2/posts) and match on title and slug. Any post that matches the demo is demo content. Repeat for pages, menus, and categories. This gives you an exact list instead of guesswork.

Should I delete demo posts or set them to draft?

Set them to draft first. It removes them from the site and every feed/archive immediately but is fully reversible, so you can restore the demo set if a template still references one. Delete permanently only once you’re sure nothing depends on them.

Can I remove page-builder demo blocks over the REST API?

The front page is a normal Page, so its builder blocks are in editable page content you can change over REST. The header, footer, and archive templates live in the builder’s own store, which standard REST doesn’t expose – use a read-only snippet to read them and a one-time setter snippet to edit them.

Why does the maintenance page need to return 503 instead of 200?

A 200 response tells search engines the placeholder is the page’s real content, so they may index “Site under maintenance.” A 503 (Service Unavailable) with a Retry-After header tells them to come back later, protecting your rankings while the wall is up.

Why check the site while logged out?

Many maintenance and membership plugins exempt logged-in administrators. An authenticated request can return the finished page while anonymous visitors still get the wall or a demo view. Verify every public-facing check anonymously so you see what real visitors and crawlers see.