Boloop diagram (AI generated): Check the first hop to find the routing issue to the verification file.
Google's provided verification file has been added to the deployment package, and a Worker unit test also returns 200, but the formal address still cannot be read as expected. Boloop encountered this problem before the request reached the handler function.
The observed path was: the verification file request with a .html suffix got a 308 redirect to the URL without the extension, then returned 404. The file was not lost, and the code that would return it had no chance to run.
Check the first hop instead of the final page
When facing a verification failure, opening the address directly in a browser often hides a blind spot: browsers usually follow redirects. A page that finally shows up does not mean the original precise address returns correct content.
To troubleshoot such endpoints, I check both GET and HEAD separately, and retain the status code and Location of the first hop. GET confirms the body, HEAD checks the status and response headers when there is no body. They answer different questions, so a 200 from HEAD alone cannot be used to assert that the file content is correct.
At that time, the 308 gave a very clear direction: first inspect the platform route and static resource handling, do not modify Google console yet.
A convenience rule of Pages conflicts with the verification address
Cloudflare Pages by default sends static HTML addresses to the version without an extension. For example, /contact.html redirects to /contact. For ordinary pages this is the platform default address form; for an endpoint that must be read at a specific path, it requires a separate check. Cloudflare Serving Pages documentation
Boloop's build process generates _routes.json, which decides which requests enter the Worker and which go to static resources. The verification file at that time was put into an exclusion list, so the request entered static HTML handling and triggered the extension removal redirect.
The previous test called the Worker directly, bypassing this dispatch list. It proved the handler can return the file, but did not prove the formal request will actually reach the handler.
The minimal fix changes dispatch for this precise path
This round did not add a generic HTML fallback, nor did it allow all .html files. The change only applies to the specific verification file provided by the user: keep its original content and move it out of the Worker routing exclusion list, so the existing handler returns it directly before the platform static normalization.
The file is 53 bytes, and the build check verifies both length and SHA-256. The byte count and hash here are specific constraints of this file and cannot be copied verbatim for another site; the other site should use the original file obtained from Google itself.
The precise exception also has another benefit: it will not inadvertently change access to unknown HTML, background routes, or private files. A public verification endpoint has no reason to expand the whole site's static file boundary.
Regression testing must restore routing dispatch
The new test reads the actual _routes.json produced by the build, first determines whether the request enters the Worker, then executes the corresponding response. With the old exclusion item present, the test can reproduce the 308; with it removed, GET and HEAD should directly return 200, and there is no Location.
GET also checks the body byte by byte, while HEAD keeps an empty response body. The test retains ordinary static resources still going through the static layer, APIs still entering the Worker, and other control samples, so that verifying the file does not break other paths.
This round, 21 related builds and edge tests passed. The platform dispatch in the tests remains simulated; the exact address after deployment still needs verification.
Reusable troubleshooting sequence
First confirm the file is indeed in the final deployment artifact, then request the original address and look at the first hop. If there is a redirect, check which layer produces each hop; if there is none but the body is wrong, then check path handling, encoding, and the returned content. Only then go back to the verification UI to submit results.
For Boloop, the most valuable clue from this problem was not "verification failed", but "the Worker works alone but fails after going through actual dispatch". In the future, whenever I encounter similar discrepancies, I will first add the entry layer to the tests rather than keep adding assertions inside the handler.