I shipped four HTML pages that convert email archives to PDF. Their addresses were /eml-to-pdf, /msg-to-pdf, /mbox-to-pdf and /pst-to-pdf. They are ordinary Next.js pages. They return text/html. They are not PDF files.

Sixteen days after launch, according to the commit that moved them, Google still listed every one as "URL is unknown to Google". Bing, which had crawled the rest of the site and indexed 32 pages there, had held /eml-to-pdf at "Discovered but not crawled" since the launch date. The same commit records that the responses, including for Googlebot and bingbot, matched pages those engines did crawl. I did not re-open Search Console or Bing Webmaster myself.

The one trait they shared

Other pages on the site were being crawled in the usual way. These four were not. The thing they have in common — and that an earlier rename had kept — is a path that ends in pdf.

On 2026-11-02, /eml-to-pdf was moved to /convert-eml-to-pdf, the convert-<x>-to-<y> shape other crawled converters on the site already use. The content did not change. After three days the new address was still unknown to Google, like the three pages that had stayed put, so that move was undone. /convert-eml-to-pdf also ends in pdf. Changing the prefix was not enough.

A crawler that looks at the last segment of a URL can treat …/eml-to-pdf the way it treats …/report.pdf: as a document to skip, or to fetch with an Accept header that does not expect HTML. That is a hypothesis, not a proof. When the four pages were renamed, there was no control left on purpose. This change cannot show that the ending was the cause. It only removes the shared trait.

What the paths are now

Each page now ends in -converter. The old addresses, including the short-lived experiment URL, send a permanent redirect straight to the new one — no chain:

{ source: "/convert-eml-to-pdf", destination: "/eml-to-pdf-converter", permanent: true }, { source: "/eml-to-pdf", destination: "/eml-to-pdf-converter", permanent: true }, { source: "/msg-to-pdf", destination: "/msg-to-pdf-converter", permanent: true }, { source: "/mbox-to-pdf", destination: "/mbox-to-pdf-converter", permanent: true }, { source: "/pst-to-pdf", destination: "/pst-to-pdf-converter", permanent: true },

I confirmed the live responses myself: /eml-to-pdf-converter returns 200 with content-type: text/html; charset=utf-8. /eml-to-pdf and /convert-eml-to-pdf both return 308 to /eml-to-pdf-converter.

A test in tests/tool-pages.test.ts pins those five redirects, requires each /<format>-to-pdf-converter path to be in the page registry, requires that no registered path matches /pdf$/i, and requires that no redirect's destination is another redirect's source. I read that test. I did not run the suite.

Takeaways

  • An HTML page can still look like a PDF file if its path ends in pdf. The Content-Type you send does not help if the crawler never requests the URL.
  • /convert-eml-to-pdf has the same problem as /eml-to-pdf. If the ending is the cause, the last token is what matters, not the words in front of it.
  • If you move a URL, point every old address at the current one in a single hop. A 308 to an address that 308s again is a chain you will have to explain later.
  • Pin the rule, not just today's slugs: no registered path ends in pdf, and no redirect lands on another redirect.
  • Treat the "crawlers took it for a file" reading as a hypothesis until a later crawl shows the new addresses being fetched. I do not have that result yet.

One of the four pages is now the EML to PDF converter. Disclosure: I built it.

Source note (2026-11-13): I read Mailward commit 1f8960f (AuthorDate 2026-11-11 10:32:30 +0800), the current permanent redirects, the four registry paths, and the new assertions in tests/tool-pages.test.ts. I did not run the test suite, and I did not re-open Search Console or Bing Webmaster. I did confirm the live 200 and the two 308s myself.