11 Jun 2025

Morsel #20: meta http-equiv status

Filed under: the Internet | SEO

An interesting question came up at work today where I was asked about a line of code and whether it’d work. The code in question was this:

<meta http-equiv="Status" content="401">

The idea was to use this as a replacement for server-side code to serve a 401 status code. I initially said “yeah, sure” until I took a second look and realised I’d not seen the Status value before.

meta http-equiv

A quick thing on http-equiv. It’s an attribute that simulates an HTTP response header (equiv is short for ‘equivalent’) and is mostly used for things called meta refreshes where the page refreshes or redirects on the client’s side instead of the usual server-side refresh/redirect (like a 3xx status code). In that case, it’d look like this:

<meta http-equiv="refresh">

It’s generally recommended not to do this for redirects but if you don’t have server access, it’s a close-enough substitute for the user, even if the UX isn’t ideal.

In the case of http-equiv="Status" it looked familiar but not quite, hence why I had to take a second look. A quick Google returned one exact result but it wasn’t from MDN or even W3Schools. It came from Indie Web:

meta http-equiv status is an HTML extension specification that adds the “Status” value to the existing meta element’s http-equiv attribute as a method for representing the HTTP Status code to be returned by a web server serving that HTML document, and for consuming applications like webmention receivers to parse and interpret as such for use-cases such as representing a 410 Gone deleted resource on static hosting that often disallow setting HTTP headers directly.

This sounded fair in theory but when I checked the only example in the doc, it returned a 200 status code instead of a 401. What’s more, the requirements were quite specific, both for the server and the “consuming application”. Because of all these factors, I figured it wasn’t a feasible solution.

Another thing to note: server activity happens before page load so offering a status during page load won’t work. It’s too late by then and this will miss the mark. As you saw above, meta refreshes only simulate server responses and would cause issues for users coming from a search engine expecting one page only for it to refresh on load. If the 401 was to work, the page would load as normal—serving a 200—and then suddenly give a 401 error page (with or without the code).

A word on 410 vs. 404

A 404 status code tells a server the resource in question could not be found. There are a number of reasons why that might be the case but the main ones are that the page was removed or the URL was incorrect in someway. A 410 status code tells a server the resource in question is permanently gone (literally). Now you might be thinking why we use 404s if we delete pages when 410 is probably more appropriate. If you deleted, it’s gone, right? Well, 404 is a softer default. You could delete something and decide to reinstate it and it’s easier to bring it back to the same URL and have a search engine pick it up and reinstate it to the index. But a 410 is meant to be a permanent goodbye.

If you really to nuke a page, 410s are objectively better and quicker to get picked up by Google and dropped from the index (but by a negligible amount, according to John Mueller). However, in most cases, 404 does the job. What’s more, 404 is better supported with CMS’s and other frameworks as they usually offer templates and functionality to serve them should a page gets deleted. 410s tend not to have the same level of support so you may have to create this routes and pages manually (if you even have access to do so). And you might not even see the difference once you have.

So yeah, if you’re getting traffic from a regularly visited external link and that page was deleted and it’s causing server issues, go for a 410. Otherwise, 404 works just fine.