Type php.net/sitemap.xml into a browser and the answer arrives before you have let go of the return key. Not because the server is quick. Because there is almost nothing in the file.
It is 2,576 bytes. It lists 39 URLs. That is the entire declared surface of the site that documents PHP: the downloads page, the credits page, the licence, the mailing lists, a few section directories, and the homepage.
The manual is in there. It is one line, written as /manual/, indistinguishable from any other entry. Behind it is a reference library we could not finish counting in a day.
We went looking for a story about scale. We found a story about hygiene. Every URL in that file points at a host php.net does not serve from, and one is a server error the site's own robots.txt forbids crawlers to fetch.
Results at a glance
php.net publishes a sitemap of 39 URLs. We fetched every one individually — no sampling, the file is small enough to read whole. The PHP manual, the reason almost anyone visits the domain, appears exactly once, as a directory entry.
The interesting part is not the brevity. Not one of the 39 entries is written on the canonical host, so every one redirects before it resolves; one returns a persistent server error while also being blocked in robots.txt; and the site scores 93 regardless. The sitemap is the worst-maintained artefact on an otherwise well-built site.
The whole manual is one line
Split the 39 entries by shape and you get a tidy picture. There are 29 root-level .php pages, the administrative furniture of a project site; 7 section-index directories; 2 policy subpages under the licence directory; and the homepage. That adds to 39 with nothing double-counted, and an independent recount reproduced the same buckets exactly.
Nothing in that list is the documentation. The manual enters as a single directory reference, and a crawler following it does not even land where it was pointed — it ends up on the English index page inside the manual. Everything past that must be found by following links.
So we followed them. The English function index carries 9,144 unique internal links, all pointing under the manual, and every one we sampled resolved. Add the examples index and the manual landing page and the floor becomes 9,704 unique English pages, none listed individually. The manual also ships in 11 languages, so the true number is far larger than anything we counted, and we are not going to pretend otherwise.
Every entry points at the wrong host
Here is the part that surprised us most, because it is trivially checkable. All 39 URLs are written with an http:// scheme on the bare php.net host, while the site serves from the secure www host. So no declared URL is the canonical form of the page it describes, and every request begins with a redirect.
Most settle after two hops. A few take three. The security entry takes five and lands inside the manual — the sitemap advertises a section that is really one documentation page.
None of this stops anything working; search engines follow redirects. But a sitemap exists to give a crawler the canonical address of each page, and this one gets that wrong on every line.
One entry is broken and blocked
38 of the 39 URLs eventually reach a working page. The exception is the distributions directory, which returns a server error. We retried twice and got the same result.
That alone would be an ordinary sitemap bug. What makes it worth writing down is that the same path is disallowed in php.net's robots.txt. The sitemap invites crawlers to a broken URL, and the robots file forbids them from going there to find out. A compliant crawler never sees the error, so nobody gets a report, and the entry sits there indefinitely.
There is a second version of the same pattern: one root-level entry redirects to the site's search page, which is also disallowed. These contradictions surface only when somebody reads the sitemap and the robots file side by side, which almost nobody does.
The metadata is almost entirely absent
There is no lastmod value anywhere in the file, and no priority value anywhere. There is exactly 1 changefreq in the whole document, plus a version-control placeholder in a comment that was never expanded — a small, human detail: the file was templated once and then left alone.
We are not going to claim the missing lastmod costs php.net anything. The point is the diagnosis, not the penalty: a sitemap with no timestamps, no priorities, a stale placeholder and non-canonical URLs on every line is not a file anyone is tending.
Worth noting too: robots.txt declares no sitemap location at all, and the usual alternative filenames return 404. The file we read is the only one, and nothing advertises it.
A links-per-page ratio nobody can match
Our backlink tool reports 468,843 referring domains for php.net and a domain rank of 97, just under MDN and Eventbrite in this series and just above PyPI. Nearly 99% of the links are dofollow.
Divide those referring domains by the 39 URLs the site declares and you get roughly 12,022 per listed page. That is about 84 times calculator.net's 143, the previous high in this series, and it dwarfs MDN's 3.9 and PyPI's 0.082 by margins not worth writing out.
It is also, to be blunt, a number that says more about the sitemap than the site. The denominator is 39 because 39 is what php.net publishes, not because php.net has 39 pages. The honest reading is that php.net's declared surface is a rounding error against its actual one.
The site underneath is in good shape
Given everything above, the audit result is the twist. php.net scored 93, the highest we have recorded in this series, ahead of PyPI at 91 and MDN at 88. No critical issues, 2 warnings, 3 notices, 117 checks passed. Mobile was clean, on-page lost a single point, speed lost 2, technical lost 3.
Read that as a fact about construction rather than a grade. The pages are plain, the markup old and stable, with very little script and almost no third-party weight. Sites built that way audit well unoptimised.
Which sharpens the lesson. The sitemap is not neglected because the team is careless, but because it is the one file nobody sees. Every other surface gets used constantly and stays honest as a result. This one has no users, so nothing corrects it.
Copy this in an afternoon
None of these checks needs a crawl budget or a tool subscription. They need somebody to open the file.
1. Read your sitemap end to end. Not a sample — the whole thing, or one whole child file if you use an index. Ask whether the pages you most want found are named in it. If your equivalent of the manual is one directory entry, that is a decision somebody made, and you should know who.
2. Check the scheme and host on every entry. Compare each declared URL against the canonical form your site serves. Mixed http and https, bare host versus www, trailing slash drift — any of these turns every entry into a redirect, and the fix is a find-and-replace in whatever generates the file.
3. Diff the sitemap against robots.txt. Any path you list and also disallow is a contradiction, and it hides failures from you as well as from crawlers. Do the same for status codes: fetch every URL, not just the first few.
4. Decide what stays unlisted, then link it properly. Leaving a large section out is survivable if internal linking carries it, which is what php.net's index pages do. It is fatal if nothing links to it. Pick one deliberately.
What you cannot copy
php.net can afford this. You almost certainly cannot. Close to half a million referring domains and a domain rank of 97 mean search engines crawl the domain thoroughly whatever the sitemap says. Those links were earned by being the reference documentation for a programming language, not by any file in the web root. A site without that gravity needs its sitemap to be found.
We counted the sitemap, not the site. The 9,704 figure is a floor built from 2 index pages and the manual landing page, all in 1 language. The manual ships in 11 languages, so the real total is much larger and we did not try to establish it. Nor did we crawl the manual exhaustively: we verified the index links are unique and all point under the manual, and that a random sample, plus 2 pages chosen by hand, return working pages. Treat every page number here as a minimum.
Our backlink tool does not quite reconcile with itself. Its dofollow and nofollow figures add up to slightly more than the total backlinks it reports for the same domain. The gap is small, but it is our defect rather than php.net's, and it is why we lean on referring domains and treat the raw total as approximate.
Every status code is a snapshot, and the audit score is one tool's opinion. The redirects, hop counts and server error were measured on one day, from one location, with one user agent; retrying the failing entry twice makes it more than a blip, but we cannot say how long it has failed. And 93 reflects what our checks look for, not whether the documentation is any good.
Everything we found on php.net is discoverable without special access: non-canonical URLs, entries that redirect, an entry that errors, and paths robots.txt blocks. Our Website Audit runs those checks and tells you which apply to your pages.
- Flags redirect chains and non-canonical URLs
- Checks robots.txt and sitemap agreement
- Separates critical issues from warnings and notices
Frequently asked questions
How many URLs are in php.net's sitemap?
39, exactly. The file is 2,576 bytes of plain XML, served uncompressed with an HTTP 200: 39 url elements, 39 loc values, no duplicates. We fetched every entry individually, so nothing is sampled or estimated.
What do those 39 entries actually cover?
29 root-level .php pages such as downloads, credits, licence, support, git and mirrors; 7 section-index directories covering archive, conferences, distributions, licence, manual, releases and security; 2 policy subpages under the licence directory; and the homepage. An independent recount reproduced those buckets.
Is the PHP manual in the sitemap?
Only as a single directory entry. The English function index alone carries 9,144 unique links to manual pages, and adding the examples index and the manual landing page brings the floor to 9,704 unique English pages. The manual ships in 11 languages, so the true count is far higher, and none of those pages is listed individually.
Do the sitemap URLs work?
38 of the 39 eventually return a working page, but all redirect first: every entry is written as http:// on the bare host while the site serves from the secure www host. The distributions directory returns a persistent server error and is also disallowed in robots.txt. One root entry redirects to the search page, which is disallowed too.
Is php.net's sitemap really a sitemap index?
No. Its root element is a flat urlset with zero child sitemap references, so there is nothing to walk. It is also the only sitemap on the domain: robots.txt declares no sitemap location, and the usual alternative filenames return 404.
What metadata does the file carry?
Almost none. Zero lastmod values, zero priority values, exactly 1 changefreq in the entire document, plus an unexpanded version-control placeholder in a comment — suggesting the file was generated from a template once and never revisited.
What did the site audit find?
A score of 93 with 0 critical issues, 2 warnings, 3 notices and 117 checks passed. On-page scored 24 of 25, technical 64 of 67, speed 27 of 29, mobile 2 of 2 — the highest in this series, ahead of PyPI at 91 and MDN at 88.
How does php.net compare on referring domains per page?
468,843 referring domains against 39 listed URLs works out at roughly 12,022 per page, against calculator.net's 143, MDN's 3.9 and PyPI's 0.082 measured the same way. Not like for like: php.net's denominator is small because its sitemap is small, not because the site is.
The pattern here is one we keep meeting in different costumes. A file gets written, it works, and then nobody reads it again — including the people who own it. Nothing breaks loudly, so nothing prompts a fix. php.net's sitemap now describes a site that no longer matches it, on a host it no longer uses, pointing at one URL failing quietly behind a robots rule that guarantees no crawler will report it.
What saves php.net is that its internal linking is genuinely good. The index pages do the discovery work the sitemap declines to do, well enough that we counted 9,704 pages from them without touching the sitemap once. That is the real lesson: your links are load-bearing, your sitemap is a courtesy, and most sites have it the wrong way round. To find out which way round it is on yours, fetch your sitemap, read it whole, and compare it against your robots file and your canonical host — our Website Audit runs those checks free.
Measured on 29 August 2026. All 39 sitemap entries were fetched individually with no sampling; page counts inside the manual come from unique internal links on its index pages and are floors, not totals. Backlink and audit figures come from the UNmiss Backlink Analyzer and Website Audit on the same date; referring domains per page uses the 39 declared URLs as the denominator, which describes the sitemap, not the site.