Redirections

When a page moves, you can keep its old url working and send visitors to the new one. Two frontmatter keys declare a redirection:

• redirect_to_full_url: the complete destination url. A path starting with / is also accepted, for a page that moved inside the same blog.
• redirect_to_domain: another domain, keeping the current path. example.com and https://example.com both work, and a missing protocol is assumed to be https.

Example:

---
title: My old page
listed: false
redirect_to_full_url: "https://www.example.com/2024/01/my-new-page"
---

The markdown file has to stay at the old path: it is what makes the old url exist. Setting listed: false keeps that leftover file out of the listings, the RSS feed and the related posts, while the url stays reachable and gets generated.

What Bloggrify generates

For a page that declares a redirection, the generated html contains:

• a <meta http-equiv="refresh" content="0; url=...">, which redirects immediately and works with JavaScript disabled,
• a location.replace() on the destination, which covers navigation from inside the blog and leaves no entry in the browser history, so the Back button does not come back to the redirecting page,
• a <link rel="canonical"> pointing at the destination, not at the page itself,
• a noindex, follow robots directive.

The page is also left out of the sitemap, and no article metadata (og: tags, schema.org, generated social image) is emitted for it.

This is not an HTTP 301

Bloggrify only generates static files, so there is no server to answer with a real 301. An instant meta refresh is the closest portable equivalent, and Google documents it as a permanent redirect.

If your host lets you declare redirect rules (_redirects on Netlify and Cloudflare Pages, a redirects block on Vercel, a rewrite rule on nginx), those give a real 301 and are worth using for large batches of moved urls. The frontmatter keys remain the option that travels with the content and works everywhere.