Start with the identity of the page
A portfolio card may grow into a detailed case study. That is more than a navigation-label change: previously shared addresses, search results and outside references should still reach the intended subject. Begin by listing old paths and assigning an appropriate destination to each. A list containing only the new design’s routes overlooks the links people already have.
kaahn.com presents projects on separate Turkish and English pages. In that arrangement, moving an English project URL should normally preserve both the project and its language. Switching language is a different decision from moving content. Sending every former address to the home page can discard what the visitor came to find.
Redirects and canonical annotations answer different questions
Google treats permanent server redirects as a strong signal that the destination should become the preferred URL. A canonical annotation expresses a preference among accessible versions; it does not move the visitor’s browser. These mechanisms therefore produce different user behavior. For a retired address, consider the move itself. For versions that remain accessible, consider their relationship.
Keeping internal links and sitemap entries aligned with the chosen final address also helps maintenance. When one template uses an old path and another uses a new one, small changes can accumulate into redirect chains. This article does not claim that a particular redirect type produces a ranking gain in every situation.
Keep the migration table actionable
The following paths describe a hypothetical portfolio, not existing errors or a completed migration on kaahn.com. Each row can drive both a server rule and a test case. An old page without a real successor needs a content decision rather than an automatic home-page destination.
| Old address | Decision | Reason |
|---|---|---|
| /work/example/ | Permanent move to the project’s final URL | Preserve subject identity |
| /en/work/example/ | Move to the English project equivalent | Preserve subject and language |
| /old-event/ | Return a removed-page response if no successor exists | Avoid an unrelated destination |
| New internal links | Use the final address directly | Avoid an unnecessary hop |
Let the link text describe the destination
Three links labeled “click here” make their different purposes hard to understand. “Inscribi Director source code”, “voting-flow explanation” and “live demo” set distinct expectations. Google’s link guidance recommends crawlable HTML links and descriptive anchor text. Enhancing a menu with JavaScript does not prevent its basic destination from being expressed in an href.
For an editorial check, read the paragraph and identify the question answered by each link. Source code supports implementation details, a research article explains a method and a demo offers an experience. Choose the destination that answers the reader’s next real question. Repeating a person’s name in additional links to the same profile is not a substitute for that judgment.
Verify the move in two layers
First inspect the old URL’s status and Location header. It should reach the intended final page without a loop and preserve the expected language. Then inspect the destination’s title, canonical address and visible body. A response can have the right HTTP status and page title while still presenting the wrong project. Checking only the status cannot catch that mistake.
After publication, crawl records and Search Console data can provide additional evidence. A technical URL check establishes what the server returns; it cannot guarantee when a search engine recrawls it or where it ranks for a query. A good migration keeps the page’s identity understandable to the visitor and to the person maintaining the site.
Keeping that checklist with the last successful release gives the next URL change a concrete starting point: a record of the behaviors that need to remain intact.