A slug is a fragment and a url is a fact, so take yours from the sitemap

Never assemble a url from a slug. Read it out of your sitemap and use it exactly as published. On this site a page can be live under one path prefix and absent under another, so a url built by gluing a prefix onto a slug is a guess with a convincing failure mode: it returns a not found response, and a not found response is not evidence about anything except that you built the wrong url. Every url in our sitemap returns 200 when it is fetched from the sitemap, 1,721 of them on the day that check ran, and the constructed form of a page that lives under the other prefix returns a 404 carrying an 18KB shell with no article in it.

This sounds like a detail and it is a structural problem, because almost every piece of automated work in search and AI visibility starts from a list of urls. An access test, a link audit, a rendering check and a citation study all begin by deciding what to fetch. If that list is assembled rather than read, every number downstream of it inherits the guess.

How a site ends up with two shapes

Nobody designs this. It arrives through history: a platform migration that kept the old paths alive, a multi tenant application that serves some content under a tenant path, a section added by a different team under a different route. Our own split runs that way. A minority of our urls sit under a second prefix, thirty two of them when the rule about this was first written down, and the count moves whenever pages are published. That movement is the argument. A count is a snapshot and an index is a file you can fetch, and only one of them is still correct tomorrow.

Several of the pages under our second prefix are method pages, which is the worst possible luck. They are exactly the pages a sceptical reader wants to open, and they are the ones a constructed url is most likely to miss.

The three failures that follow from a constructed url

What breaks	What it looks like	What it actually was
A conclusion about your site	An empty body with no article text	The page exists at a different path
An internal link you published	A reader clicking through to nothing	The right page, the wrong prefix
An audit's coverage	A clean report with no issues found	A scan that fetched almost nothing and counted no failures

The first of those cost us an hour on the most serious claim available about a product that sells being read correctly by machines. Somebody built a url, got the shell, and reported that no page body on this site was server rendered. The page was live at the other url, and its article comes back identical to eleven agent strings at 63KB and 1,789 words.

The second is the quiet one. Across the distinct internal links we have published, one of the three that did not resolve pointed at the wrong prefix of a page that exists, and it has been repointed rather than removed. A reader who clicked it got nothing while the destination was sitting there under its real url.

The practice, which is four lines and no judgement calls

• Fetch the sitemap and parse it. Read the location elements and keep the strings verbatim, including the host, the scheme and any trailing form. Do not normalise them into a shape you prefer.
• Treat the sitemap as the inventory, not as a sample. If a page you know exists is missing from it, that is the first bug to fix, and it is a bigger bug than whatever you were about to audit.
• Record the final url after redirects as a separate field. A url that resolves by redirecting somewhere else is a different fact from a url that resolves directly, and the two need different follow up.
• Refuse to run when the inventory is missing. A check that cannot load its url list has not run. Our own planning scripts now exit rather than proceeding on an empty inventory, because planning without the inventory offers work that is already published.

If your sitemap is itself unreliable, that is the thing to repair first, and the two submission routes and how to read what each one reports back are set out in our guide to submitting a sitemap and reading the result.

Why this matters more for assistant visibility than for search

A search crawler discovers your pages over weeks through links and a sitemap, and a missing path eventually gets found another way. The checks people run to see what an assistant can read are single shot fetches against a url somebody typed, and there is no discovery step to rescue a wrong guess. The reading simply comes back wrong, looking exactly like a reading that came back right.

That is also why these url lists deserve a place in your internal documentation rather than in a spreadsheet one person maintains. The structural question of which pages point at which, and how to find the ones nothing points at, is covered in our page on internal linking and the audit that finds the gaps.

Questions about building urls from slugs and reading them from a sitemap

Is it ever safe to construct a url from a slug?

Only on a site where you can prove there is exactly one path shape, which means you have read the sitemap to check. At that point you have the real urls anyway, so the construction saves nothing.

What does a 404 actually tell me?

That the url you sent does not resolve. It carries no information about rendering, about access, about blocking or about whether the content exists somewhere else on the same site. Treat it as a question rather than an answer.

My sitemap has thousands of entries. Do I check them all?

Fetch them all and count every result, including the failures. A scan that quietly swallows its errors reports a clean site having read almost nothing, which is the most dangerous shape of bug in this work. Print the number you fetched beside the number you expected.

Should a page exist under two urls?

Generally no, and where history has given you two, a canonical pointing at the one you want is how you tell a crawler which is which. The thing to avoid is believing a page is missing because you asked for the form you do not use.

How do I find the pages under an unexpected prefix?

Group every entry in your sitemap by its path prefix and print the counts. It takes one pass over the file and it will usually surprise somebody on the team, which is the point of doing it.

The inventory is the cheapest thing you own

Every expensive mistake in this seam has begun with a list of urls that somebody made up rather than read, and the file that prevents all of them is already sitting on your domain. We hold ourselves to the same discipline in public: the windows, the export dates and the denominators behind every number we publish, including two Google Search Console exports and a dated blind scan, are on our proof page, and the url list behind each reading comes out of the sitemap rather than out of a spreadsheet. Running these checks on other companies' domains and fixing what they surface is our business, which is why the mistake that taught us this is written down here with its cost attached.