A permalink is the address other pages cite, readers bookmark, feeds repeat and search engines index. It is not merely a routing preference. Once published, it becomes part of the entry's identity, and the cost of changing it is distributed across systems the site owner does not control.
Common patterns
Blog engines have used query-string identifiers, GUID-based routes, date paths and readable slugs. A query such as ?id=42 can be stable if the identifier never changes. A GUID avoids title collisions but is difficult to read. A date path communicates chronology but can become misleading when an entry's displayed date is corrected. A title slug is legible but needs a collision policy and should not be regenerated on every edit.
The URI syntax specification explains how identifiers are composed; it does not choose a blog's editorial policy. That policy should answer which characters are allowed, whether paths are case-sensitive, how Unicode is represented, and what happens when two entries request the same slug.
Separate identity from presentation
A title can change without an entry becoming a different entry. If the title is used to create the first permalink, keep the established path after later edits. The current title belongs in the page heading and metadata; the existing URL continues as the public identity. A database key or UUID can remain the internal identity even when the route is readable.
Feeds make this separation visible. An RSS guid or Atom id should remain stable even if the HTML route is redirected. Changing the feed identifier and the permalink together can cause an old entry to appear new.
Canonical URLs reduce ambiguity
A site may technically serve several forms—uppercase and lowercase paths, an extension and an extensionless form, or both slash variants. Pick one canonical form and use it in internal links, feeds, sitemaps and page metadata. Redirect other legitimate forms directly where the serving layer permits. Consistency is more valuable than any particular convention.
<link rel="canonical" href="https://example.test/entry.html">Build a redirect map from evidence
Before migration, inventory internal links, feed item URLs, sitemap entries, server logs and known inbound links. Map each old address to the closest equivalent new page. Keep mappings exact when possible. A broad rule that sends every unknown path to the homepage hides missing content, makes debugging difficult and can revive addresses that should stay dead.
HTTP defines permanent redirection semantics in RFC 9110. In practice, the important design detail is the destination: it should answer the same intent. A retired entry with no replacement is often more honestly represented by a not-found or gone response than by an unrelated page.
Prevent redirect chains
When the site changes again, update old rules to point straight to the current canonical URL. A chain adds latency and creates more places for a rule to break. It can also produce loops when slash normalization, host normalization and content migrations are managed separately. Test the complete path with query strings, encoded characters and both host forms.
What to record
- The canonical public URL and immutable internal identifier.
- The first publication date and current display date.
- Every known historical URL for the entry.
- The chosen redirect target and reason.
- Feed identifiers and enclosure URLs.
- Paths deliberately left as 404s.
Test the negative space
A URL plan must test addresses that should not work as carefully as those that should. Probe a random path, an old deleted entry, a retired service endpoint and a misleading near-match. Correct 404 behavior proves that routing rules are scoped; it prevents a broad normalization rule from turning unrelated paths into apparently valid pages.
The whole game
Storage engines, frameworks and templates are replaceable. A public link has already escaped the application. Treat that fact as a design constraint from the first post, and a later migration becomes a controlled translation rather than a search for lost identity.