A missing public document should show a clear explanation and return an appropriate HTTP status, usually 404. On a Mac, you can check both in Chrome, identify the mismatch, and give your publishing system a precise correction.

This workflow is for someone maintaining public document pages: guides, reference notes, or simple instruction sheets. Its task is to make the requested address, the server’s response, and the displayed message agree. All example paths below are synthetic.

Which response should a missing document return?

First decide what should happen at the document’s address. A page that has moved needs different handling from a page that no longer exists. Use this decision table before changing the missing-page design.

State of the document Intended response What readers should see
It exists at the requested address 200 OK The complete document
It has a clear permanent replacement 301 redirect The replacement document at its new address
It cannot be found, with no equivalent replacement 404 Not Found A useful missing-document explanation
It was deliberately removed and its absence is likely permanent 410 Gone is appropriate A clear removal explanation and useful navigation

HTTP defines 404 without saying whether the absence is temporary or permanent. It defines 410 for a resource whose unavailability is likely permanent; when permanence is unknown, use 404. These meanings come from RFC 9110, sections 15.5.5 and 15.5.11.

Google recommends a permanent redirect when a document has moved or has a clear replacement. If it has been removed without a similar replacement, Google recommends 404 or 410. See Google’s guidance for resolving missing-content responses.

For example, suppose /documents/paper-folding-notes has become /documents/paper-folding-guide, with substantially equivalent instructions. A permanent redirect fits that change. If the notes were removed without a replacement, keep a missing-document response at the old address. A general document directory can be offered as a link on that page.

Why a convincing missing-page design is insufficient

A page can visibly say Document not found while its server returns 200. Google calls this kind of mismatch a soft 404; an empty page or one without main content can also trigger that classification. Read Google’s explanation of soft 404 errors.

The status is part of the HTTP response, separate from the explanatory content. Consequently, changing the heading or adding a large 404 label cannot establish the response code. Check the actual document request before deciding that the problem is fixed. RFC 9110 describes the role of response status codes.

How do you check the document response on a Mac?

Use Chrome’s built-in tools for this inspection. Prepare one known working document address and one deliberately nonexistent path under the same public site. For example, the missing path might be /documents/missing-paper-example-731. Choose an address that you know has no published document.

  1. Open the public page in Chrome.
  2. Press Command + Option + I to open DevTools.
  3. Select the Network panel.
  4. With DevTools open, enter the test address in the address bar and load it.

Chrome documents the Mac shortcut in Open Chrome DevTools. Network activity is recorded while DevTools is open, as explained in the Network panel overview.

  1. Select Disable cache to avoid relying on the browser’s cached response during this check.
  2. Enable Preserve log if you need to follow navigation through redirects.
  3. Reload the test address.
  4. Select its main document request, then open Headers. Under General, read the request address and status code.

These controls and the location of the status information are documented in Chrome’s Network features reference.

Check the document request carefully. The log also contains requests for scripts, styles, and other resources. A missing supporting file does not establish that the document itself returned 404. Chrome’s request table distinguishes the HTTP code in Status and the resource category in Type; see Inspect network activity.

Now compare three observations: the address originally requested, the response code for that document, and the page visible after loading. Record them together. If navigation changes the address, inspect the original request and the destination rather than recording only the final page.

How do you turn the observations into a correction?

The following diagnostic table is a practical synthesis of the HTTP meanings and Google’s troubleshooting guidance. It is a decision aid, not a set of measured results.

Observed result What to investigate Intended correction
200 with a missing-document message The missing-route handler or fallback Return 404 with the explanation
404 with the expected document visible The response assigned to an existing route Serve that document successfully with 200
A redirect to a broad directory Whether an equivalent replacement exists Redirect to the equivalent document, or show a missing page
200 with a blank or incomplete document Content loading and rendering Restore the intended content if the document still exists
404 with a useful missing-page message Whether the address is genuinely absent Retain that behavior if absence is intended

Google’s troubleshooting documentation explicitly separates documents that are unavailable, documents that have moved, and documents that still exist but fail to load correctly. This distinction prevents an incomplete working page from being treated as intentionally removed. See Troubleshoot Google Search crawling errors.

For a concrete handoff, write: “For the synthetic missing path /documents/missing-paper-example-731, return 404 and display the custom missing-document page at that address. Keep existing document paths successful. Apply permanent redirects only where an equivalent replacement is identified.” Add the observed status and visible message from your check.

That request describes the required behavior without guessing your publisher’s menu names. The implementation belongs in the hosting configuration, application route, or publishing system that produces the response. Google explains that HTTP status codes are generated by the hosting server in its HTTP status-code documentation.

What if the editor only lets you change page content?

An editor that changes text or document metadata may not control HTTP responses. The WHATWG HTML Standard defines specific behaviors for meta directives using http-equiv; setting an HTTP response status is not among them. Adding http-equiv="status" is therefore not a supported way to create a 404. See HTML Standard: Pragma directives.

When response controls are unavailable in the editor, use the hosting or application layer’s documented missing-page mechanism. Ask whether it serves the custom content with 404 at the requested missing address. A setting that merely chooses an error-page layout does not answer that question; verify its result with the browser workflow.

A documented example for static pages on Netlify

For an existing static site on Netlify, the documented mechanism is a file named 404.html. Netlify automatically uses it for failed paths that do not resolve to a static file. This is a provider-specific example, with prerequisites: access to the site’s finished output and an existing static-page build. Netlify documents custom 404 handling.

  1. Use the site’s existing page template to create the missing-document page.
  2. Ensure the finished output includes 404.html at the root of the publish directory.
  3. Check that no earlier routing rule sends unknown addresses to another page.
  4. After the revised output is available at the public address, inspect both a missing path and a working document.

The routing check matters because Netlify processes routing before reaching its static-file and final missing-page handling. A request already handled earlier will not reach that final handler. Its Request Chain documentation explains the order. This example describes a correction path; it does not indicate that any site has been changed.

The boundary for browser-routed applications

Some applications discover that a document is absent only after JavaScript runs. Google acknowledges that meaningful status codes can be impractical in client-side routing. Its documented alternatives are a JavaScript redirect to an address whose server returns 404, or adding noindex metadata to the error page. See Google’s JavaScript SEO guidance.

Those alternatives have different outcomes. The redirect reaches a new address with a genuine missing-page response. The metadata approach addresses indexing while leaving the original HTTP status unchanged. If the requirement is to keep the original document address and return 404 there, the hosting or application response must support that behavior.

What should the missing-document page say?

Use a short, specific message such as This document could not be found. Follow it with one useful next action: a link to the document directory or another verified navigation destination. Keep the site’s familiar navigation and appearance. Google recommends clear language, consistent design, and useful links for custom missing pages.

For the synthetic paper-folding example, suitable copy would be: We couldn’t find this paper-folding document. Browse the document directory to choose another guide. Only describe a document as permanently removed when that is known. Keep the explanation visible rather than immediately sending every missing address elsewhere.

How do you verify that the response and page agree?

Repeat the inspection with a small comparison set. The expected outcomes below are illustrative acceptance criteria; they are not reported test results.

Test case Expected response and page
Known working document 200, with the complete document
Deliberately nonexistent path 404, with the missing-document explanation
Removed document without a replacement 404, or 410 when appropriate, with an accurate explanation
Moved document with an equivalent replacement Permanent redirect, followed by the replacement’s successful response

Retest by entering each address directly and reloading it, including documents normally reached through in-page navigation. This checks the response that a fresh document request receives. Keep the address, code, and visible result together so that a successful destination does not conceal an incorrect response earlier in the navigation.

If an old result persists, distinguish the browser cache from other caches. Disabling Chrome’s cache addresses its browser cache. HTTP caching can also store negative responses such as 404, so an outdated missing response may require checking the publishing system’s documented cache behavior. RFC 9111 explains cacheable negative results.

For Google Search, a genuine missing response has an intended consequence: Google does not index URLs returning 404 or 410, and previously indexed URLs are removed as those responses are processed. A successful 200 response also does not guarantee indexing. See How HTTP status codes affect Google’s crawlers.

Finish when each tested address tells a consistent story: available documents load successfully, moved documents lead to their replacements, and absent documents return an appropriate missing response with useful navigation. That gives you a concrete, repeatable publishing check on your Mac.

Sources