We Found 9 Invisible Pages Hiding on a Client's Server (Here's How)

We Found 9 Invisible Pages Hiding on a Client's Server

A client asked a simple question: "Why does this page look different from the others?"

That question kicked off a 30-minute investigation that uncovered nine orphan files silently overriding an entire template system, serving outdated content to Google, and receiving zero organic traffic.

This is the story of how we found them and the technical SEO lesson hiding inside it.

The Setup

We manage a plumbing company's website with roughly 600 location pages. The site uses a PHP template system: a single file dynamically generates pages for hundreds of suburbs. A URL like /plumber-parramatta/ hits an Apache rewrite rule, which routes the request to the template, which reads the suburb name from the URL and renders the page.

It is an elegant system. One template file, hundreds of pages. Update the template once, every page updates.

We had recently overhauled the hero section across all templates. New H1 format with the USP baked in, trust pills, a description paragraph, Google review badge, and an updated quote form. We verified the changes on a dozen pages. Everything looked correct.

Then the client sent us a link.

"Found Another Template We Haven't Been Updating"

The page in question looked fine at first glance. It loaded, no errors. But the hero section was wrong. The H1 used a generic format instead of our updated one. No trust pills. No description paragraph. The old layout.

Our first instinct: maybe this suburb was hitting the wrong branch in the template. The template file has four code paths based on geography. Different suburbs route through different branches. Perhaps this one was caught by a branch we hadn't updated.

We checked. Every single branch had the updated H1. All four code paths were consistent. The old heading format did not exist anywhere in the template file.

That ruled out a template branch issue. Something else was serving this page.

The Hypothesis: A Physical File Override

Apache's mod_rewrite has an important behaviour that is easy to forget: if a physical file or directory exists at the requested path, the rewrite rule may never fire.

Our .htaccess had a catch-all rule:

RewriteRule ^plumber-([^/.]+)/?$ suburb-template.php?suburb=$1 [L,QSA]

This should route any /plumber-{suburb}/ URL to the template. But if there is an actual file called plumber-carlingford.php sitting in the webroot, Apache serves that file directly instead of applying the rewrite.

We checked the server. There it was:

plumber-carlingford.php — 28,384 bytes

A standalone PHP file with its own hero section, its own H1, its own layout. Completely disconnected from the template system. Every time we updated the template, this file sat there unchanged, serving the old design.

How Many More?

If one orphan file existed, there could be others. We listed every file in the webroot matching the pattern plumber-*.php:

plumber-avalon.php        (26,634 bytes)
plumber-blue-mountains.php (46,758 bytes)
plumber-brooklyn.php      (28,528 bytes)
plumber-carlingford.php   (28,384 bytes)
plumber-chiswick.php      (28,724 bytes)
plumber-dee-why.php       (26,313 bytes)
plumber-kogarah.php       (28,253 bytes)
plumber-lindfield.php     (28,724 bytes)
plumber-wollongong.php    (46,572 bytes)

Nine standalone files. Nine pages that had been silently bypassing every template update we had deployed for months.

The Performance Impact

We pulled Google Search Console data for the last 30 days to compare these pages against pages served by the template system.

The results were stark:

Template	Top Page	Clicks (30d)	Avg Position
Main template (catchall)	/plumber-blacktown/	35	16.1
Main template (catchall)	/plumber-parramatta/	30	13.0
Unique content template	/plumber-campbelltown/	24	15.8
Regional template	/plumber-liverpool/	12	13.1
Standalone (orphan)	None in top 50	0	N/A

Not a single orphan file appeared in the top 50 location pages. Zero meaningful organic traffic across all nine.

This makes sense when you think about it. The orphan files had outdated on-page SEO: a generic H1 that did not include the key USP, no trust signals above the fold, and none of the structured data improvements we had deployed to the template months earlier. Google had effectively deprioritised them.

Why This Happens

Orphan files like these are almost always a legacy issue. At some point before the template system existed, someone created individual PHP files for specific suburbs. When the template system was built, those files were never cleaned up.

The insidious part is that everything appears to work. The pages load. They do not return 404 errors. They look roughly similar to the other pages if you are not comparing closely. Unless someone checks a specific page against the current standard, the problem can persist indefinitely.

This is particularly common in:

• PHP sites using mod_rewrite where physical files take precedence over rewrite rules
• WordPress sites with custom pages where a static page with a matching slug overrides the dynamic template
• Sites that migrated from static to dynamic where old static files linger in the webroot
• Multi-developer projects where one developer creates files directly, another builds a template system, and neither cleans up

The Fix

The solution was straightforward: rename the orphan files so the rewrite rules can do their job.

For each file, we:

1. Backed up the original file
2. Checked for unique content that the template would not replicate
3. Renamed the file so it no longer matches the URL pattern
4. Verified the page now loads through the template with the updated hero

The pages immediately started serving through the template with the correct H1, trust pills, review badge, and all other improvements. No content migration needed because the template already handled these suburbs correctly.

How to Audit for This on Your Own Site

If your site uses a template system with URL rewrites, here is a quick audit process.

1. List Physical Files That Match Your URL Patterns

If your rewrite rule targets ^service-(.+)$, check for files matching service-*.php in your webroot:

ls -la public_html/service-*.php

Any file that matches your rewrite pattern is a potential override.

2. Compare Rendered Output

Pick a page you know should be served by your template. View source and compare it against what the template should produce. Key things to check:

• H1 text: does it match the template's format?
• Schema markup: is it the current version?
• Component includes: are shared components like headers, footers, and forms up to date?

3. Check Google Search Console

Filter your performance data by these specific URLs. Pages served by orphan files often have:

• Lower CTR than template-served equivalents
• Stagnant or declining impressions
• Missing structured data in rich results

4. Cross-Reference Your Rewrite Rules

Read your .htaccess (Apache) or nginx.conf and list every URL pattern that routes to a template. Then check whether physical files exist at any of those paths. The mismatch is your orphan list.

The Bigger Lesson

Technical SEO audits tend to focus on what Google reports: crawl errors, indexation issues, Core Web Vitals. Those are important. But some of the most impactful problems are invisible to these tools.

Google Search Console will not tell you that a page is being served by the wrong file. Crawlers see a 200 status code and valid HTML. Lighthouse gives you a performance score. Everything looks fine from the outside.

The problem only becomes visible when you ask a specific question: "Why does this one page look different?" And then follow that thread until you find the answer.

Nine pages. Zero traffic. Months of template updates silently ignored. All because of files that should have been cleaned up when the template system was built.

Sometimes the most valuable audit is just opening the page and comparing it to what it should look like.

Key Takeaways

• Physical files override rewrite rules in Apache. If a file exists at the URL path, mod_rewrite may never fire.
• Orphan files are invisible to standard SEO tools. They return 200, they have valid HTML, they just serve the wrong content.
• Template updates only work if all pages actually use the template. Standalone files bypass every improvement.
• The fix is simple once you find them. Rename or remove the orphan files and let the template system work.
• Regular visual audits catch what automated tools miss. Compare rendered pages against your current standard.