# Does your sitemap point attackers to a private area?

By Mark Kashef, founder of Lockpick. Published 2026-10-08, updated 2026-10-08.

This check flags sitemap entries whose names suggest an admin, app, API or test area. Listing is not a flaw; an unprotected area would be.

This check flags entries in your sitemap whose names suggest an admin, app, API or test area. Attackers read the same list to decide where to look first, so the listed area must ask for sign-in.

## What does this check look at?

It looks at whether your sitemap lists an area whose name suggests an admin, app, API or test section. Your robots.txt and sitemap can point to private areas too. They tell search engines what to skip or read, and anyone can read them. Listed pages are never requested.

Pulse and Deep scans both run it.

## What does a result mean?

| What the report shows | What it means | What to do |
| --- | --- | --- |
| Info finding | The sitemap lists a private-looking area. | Confirm the area needs sign-in, and drop it from the sitemap if nobody outside should find it. |

Listed pages are not requested, so being listed does not show they are unprotected. A clean result means nothing was found in what the scan read. It does not prove the problem is absent from parts the scan never sees.

## How serious is a finding?

This is information only. It claims no weakness, so it carries no verdict, and you decide whether anything should change. Confidence starts high, because a response from your site shows the thing itself. The report lists what to fix by how directly someone could use it, not by the severity label.

## Which standards does it relate to?

| Standard | Reference |
| --- | --- |
| OWASP Top Ten | `A01:2025` Broken Access Control |

Each one is a related control, not a verification. A scan sees what anyone online can see, so it never proves a whole requirement is met.

## Fix it with your AI

Fix the sitemap generator, not the file by hand, so the entry does not come back on the next deploy.

:::fix-prompt any
My public sitemap lists an area that looks private: [paste the entry from the report]. First confirm every page in that area requires sign-in before showing anything private. Then change my sitemap generator so it only lists public marketing and content pages, excluding admin, dashboard, app, API, staging and test sections. Show me the generator change and the new list of sections it includes.
:::

## How to check

Say Atlas, our example app at `atlas.example`, generates its sitemap from every route, so its dashboard appears in it. The check flags the entry without requesting it.

Run a Pulse scan from your Lockpick account to see it for your site. [Pulse or Deep](/docs/get-started/pulse-or-deep) explains what each scan reads, and the [full list of checks](/checks) shows the rest.

## Questions people ask

### Should I hide private areas with robots.txt instead?

No. robots.txt is public too, and listing a private area there points people straight at it. Sign-in protects an area. Leaving it out of public lists just avoids advertising it.

### Is this a search issue or a security issue?

A little of both. Unlike the other sitemap checks, it relates to access control, but being listed is still not a flaw on its own.

## Sources

- [Files you forgot were public](https://www.lockpick.app/docs/learn/files-you-forgot-were-public), Lockpick docs, read on 2026-10-07
- [How we rate findings](https://www.lockpick.app/docs/security/how-we-rate-findings), Lockpick docs, read on 2026-10-07