The menu item that pointed at an unfinished draft

A clinic’s main navigation had an item called Athlete Care. It pointed at /elementor-685/.

That’s a page-builder template. Not a page anybody wrote. It’s the numbered artefact a builder creates when you start something and don’t finish it. It was in the header menu of a live site, on every page, being crawled every time, and it had been there long enough that nobody in the business saw it any more.

I find something in this family on almost every site I’m called into, and it’s a category of problem that doesn’t have a name. Nobody audits for it because it isn’t in any tool’s checklist. It’s the accumulated debt of a site being edited by a page builder over years by people who each left something behind.

Here’s what it looks like in the wild.

The five shapes it takes

1. Draft and template URLs escaping into the site.
The /elementor-685/ above. Its siblings: /page-2-copy/, /home-new-final/, a duplicate service page from when someone was rebuilding it. These get linked from a menu by accident, or picked up by the sitemap, and then they’re real pages as far as Google is concerned.

Related, and worth knowing: on WordPress, Elementor registers its templates as a post type, and if your sitemap plugin is generating an entry for it you can end up submitting an XML sitemap of template files. I found exactly that on an agency site, where the sitemap index included wp-sitemap-posts-elementor_library-1.xml alongside taxonomy sitemaps full of noindexed URLs.

2. The header that isn’t the same header everywhere.
On that same clinic, the menu rendered differently on different pages. Not responsively differently. Structurally differently, because more than one header template existed and different pages were pulling different ones.

On another clinic, the blog posts had no header menu at all. Every post on the site was a dead end for navigation, and since the header is the main internal linking mechanism on a small site, that removed the only path from the blog to anything that sells.

3. Headings emitted for layout.
Seven H1 tags on a home page, several of them blank. Blank H2s scattered through. Nobody wrote those. A builder emits a heading element per section container whether the section has a heading or not. I’ve written that one up separately because it turns up on themes as well as builders.

4. Elements that exist in the markup and nowhere on screen.
An agency site had H1 and H2 tags bound to the logo. Every page, every post, invisible to anyone looking at the site. The heading structure of the entire site began with an element that rendered as nothing.

5. Embeds that work until they don’t.
A med spa’s booking form embed was dead when I audited it. It had been working the day before. Nobody had touched the page. A third-party widget had changed, or a script had failed to load, and the primary conversion point on the site was simply gone.

That one isn’t really the builder’s fault, but it’s the same underlying condition: a page assembled from parts that update independently, with nobody watching the whole.

Why it accumulates

Page builders are genuinely good at what they’re for. They let people who can’t write HTML change their own website, which is a real and valuable thing, and I’m not going to write the sniffy post about how everyone should hand-code.

The problem is what they optimise for. A builder makes it easy to add. Every operation is additive: new section, new template, duplicate this page and edit it. Removing things is harder, riskier and invisible in the interface, so nobody does it.

Multiply that by three people over four years and you get a site with several header templates, a handful of orphaned drafts, headings emitted by containers, and a sitemap listing the lot. No single decision was wrong. Nobody was careless. It’s just what an additive tool produces over time when nothing prunes it.

This is not a niche condition. HTTP Archive’s 2025 Web Almanac puts 54% of the web on a CMS, WordPress at 64.3% of those, and, the number that matters here, roughly 60% of WordPress sites running a page builder, Elementor alone at 43%. What I am describing is not an edge case on badly built sites. It is close to the default construction method for a fifth of the web.

It also never fails loudly. Every one of the five above renders fine, returns a 200 and looks completely normal to the person who owns the site.

How to find yours

Fifteen minutes, no tools you don’t already have.

Crawl the site and sort the URL list alphabetically. Not by status code. Alphabetically. Draft artefacts announce themselves: elementor-, -copy, -2, -new, -final, -test, -old. They cluster together and you can see them at a glance.

Then read your own menus, on three different pages. A service page, a blog post, and the contact page. Click every item. Compare what you see on each. If the header differs structurally between them, you have more than one template in play.

Then open your XML sitemap index and read the list of child sitemaps. Anything you don’t recognise as a real content type is worth chasing. Template libraries, tag archives with one post in them, author archives on a single-author site.

Then export headings from the crawl and sort by count. Blank headings and pages with more than one H1 are the builder’s signature.

Then load the pages that carry a form or a booking widget and actually complete the first step. Not look at it. Use it.

Fixing it without breaking the site

The instinct is to clean everything at once. On a site with four years of accumulated changes, that’s how you take down the home page on a Friday.

Delete the draft artefacts first. They’re the safest thing on the list, because nothing depends on a template nobody finished. Remove them from the menu, then delete them, then confirm they 404 or 410 rather than redirecting somewhere odd.

Consolidate the header templates second, and do it on a staging copy if you have one. This is the change most likely to have unexpected consequences, because builders let templates be conditionally assigned in ways nobody documented.

Fix headings at the template level, not the page level. A change made in the editor gets overwritten by the next template update. I’ve watched a heading fix survive three weeks and then quietly revert, and nobody noticed for months because, again, it doesn’t show on screen.

Then write down what you changed. I keep a log for every site I touch: what changed, when, and what it was meant to do. It sounds like bureaucracy until the first time a theme update reverts something and you can’t remember whether you fixed it or dreamt it.

The honest framing

None of this is why a site with no authority doesn’t rank. If your domain is new and nobody links to you, cleaning up template artefacts changes nothing and I’d rather say so.

There is one number that makes me less relaxed than that paragraph sounds. In the same Almanac data, 45% of WordPress sites pass Core Web Vitals on mobile, against 74% for Wix and 85% for Duda. WordPress is not slower by nature. It is slower by accumulation, and every one of the five shapes above is a small deposit into that account. Individually none of them matters, which is exactly why nobody removes any of them. The pass rate is what they add up to.

What it does is remove the reasons a site that should be working isn’t. A menu item pointing at a template, a blog with no navigation, headings describing containers. Individually each is small, and I’ve never seen one of them be the single cause of anything. Collectively they’re the difference between a site that has been maintained and one that has merely been added to, and Google is fairly good at telling those apart even if it can’t tell you why.

The short version

1. Draft and template URLs escape into live menus and sitemaps. Sort your crawl alphabetically and they’re obvious.
2. Check the header on three different page types. More than one template is common and invisible.
3. A blog with no header menu is a dead end for the only internal linking a small site has.
4. Builders emit headings for layout. Fix at template level or it reverts.
5. Use your own forms and booking widgets. Don’t look at them. Use them.
6. Delete drafts first, consolidate templates second, on staging.
7. Keep a change log. You will need it after a theme update.

If a site should be ranking and it isn’t, that’s the work I do. Technical SEO covers this layer. If you’re not sure which of several plausible problems is costing you, that’s what an SEO audit is for.