How to migrate an architecture portfolio without breaking project links.

Start with the addresses people already use.

Architects tend to plan a redesign around images and page layouts. But the old portfolio also has a structure: project detail URLs, service pages, team profiles, competition entries, PDFs and sometimes a second language. Those addresses are part of the published work. Changing the design does not automatically justify changing them.

Before drawing a new sitemap, export the URLs you can find from the current site's crawl, its XML sitemap, the CMS and analytics or Search Console where access is available. Add known links from publications, award pages, collaborators and project documentation. A sitemap alone may miss an old project page that is still reachable through an external link.

Record the page title, language, project name, current status and whether a replacement exists. Mark URLs with inbound links or useful search traffic for careful review, but do not assume an unmeasured page has no visitors. Check the actual response of each URL; a visually identical page may already have several aliases or redirects.

Keep a good URL when nothing important has changed.

There is no SEO benefit in renaming every project slug to match a new visual identity. If an existing address accurately describes a project and can be retained, keep it. Redesign the HTML around it. A stable URL is especially useful for projects repeatedly referenced by journals, collaborators and clients.

If the content has moved, choose a destination that answers the same visitor's question. An old page about a school should lead to that school's new project page, not the studio homepage. If two entries have genuinely been combined into one substantive page, both old addresses may point to that consolidated destination. If a project is no longer public and has no meaningful replacement, a genuine 404 or 410 is usually clearer than an unrelated redirect.

Preserve the distinction between built projects, proposals and competition work when reorganising. Do not quietly redirect an unbuilt concept to an unrelated completed building simply because both are residential. The migration should preserve the editorial meaning of the portfolio.

Make one explicit decision for every old project address.

A redirect spreadsheet is less glamorous than a new hero animation, but it is a deliverable that can be reviewed by the studio and the developer. Give it columns for the old absolute URL, the intended new URL, the action, the reason, the reviewer and the test result. Use exact URLs rather than relying on a broad wildcard rule that might send unrelated pages to the same place.

All paths in this table are fictional examples, not live client URLs. A permanent server-side 301 or 308 is appropriate for a genuine permanent move. A 302 or 307 signals a temporary move instead. Avoid using JavaScript navigation as the primary migration mechanism when the server can send the redirect directly.

Test the entire route, not just the first hop. An old project address should normally reach its final public page without a chain through a legacy domain, an intermediate slug and a trailing-slash rewrite. Update your own menus, related-project links and editorial references to point directly to the final URL. Google documents the distinction between permanent and temporary redirects; the redirect is a signal, not a promise of unchanged search rankings.

Do not forget the drawings, photographs and press files.

A studio may move every project page correctly and still break links to a press kit, competition board or PDF floor plan. Publications and collaborators sometimes link straight to files rather than to the surrounding project page. Include known downloadable assets in the migration inventory, and check whether the new CMS changes their filenames or storage paths.

If an approved PDF remains relevant, keep its original URL where possible or map it to the corresponding updated file. If the file has changed substantially, consider whether the old document should remain accessible as an archive with its date and status made clear. Never replace an old approved drawing with a different project revision without checking what the link was meant to communicate.

Image ownership and publication rights also need a fresh review when moving between systems. Possessing a source image does not itself establish permission for every new use. Preserve credits, captions and the distinction between visualisations and built photography. The project preparation guideimage delivery guide

Make the destination's technical signals agree.

Every indexable destination should return 200, contain the intended project content and declare the appropriate absolute canonical URL. Its navigation, structured data, internal links and sitemap entry should agree on that address. Do not leave a canonical pointing to the old page while the server redirects visitors to the new one.

Check for leftover staging noindex tags, blocked assets and password protection on the public site. A preview URL is useful for review but should not be treated as the public canonical or submitted for indexing. An XML sitemap is a discovery aid; it should list canonical destination URLs, not the old addresses that now redirect.

Multilingual project pages need separate decisions.

When a studio has English and German versions of a project, map each old language URL to its corresponding new language page. Keep hreflang only between real, published equivalents. Do not send a deleted German project page to an English homepage just to avoid a 404. If a translation is not ready, do not advertise a nonexistent language counterpart.

A domain move is a different operation from changing paths on the same domain. If the domain itself changes, follow the additional verification and Search Console steps in Google's site-migration documentation. Do not use the Change of Address tool merely because /work/ became /projects/.

Test a migration with real requests before switching traffic.

Review the redirect map with the architect who knows the project archive. Then test it in an environment that can serve the intended production host and redirects without exposing a public, indexable preview. Check at least one example of each rule type and every high-priority old URL. Automated tests should assert the status and destination, while a person checks that the page really contains the expected project.

• Every retained project URL responds with 200 and the correct project content.
• Every moved project has a relevant permanent redirect to a live destination.
• There are no accidental chains, loops or broad homepage redirects.
• Direct links to important PDFs, drawings and image files still work or have reviewed replacements.
• Canonical tags, indexability, language alternates and the XML sitemap agree.
• Project cards, filters, related links and mobile navigation use final URLs.
• The new project detail is readable on a phone, including plan downloads and enquiry links.
• Contact forms, project references and any relevant conversion tracking work on the intended host.

Monitor the live move, not only the launch checklist.

Once the public deployment is confirmed, repeat the redirect tests against the real production host. Review server errors and crawl reports, inspect a sample of old and new project URLs in Search Console, and check whether the production sitemap contains the expected destinations. Do not request indexing of preview addresses.

Compare search impressions, landing-page visits and enquiries with a pre-launch baseline when those measurements exist. Changes can take time, and the data may be sparse for a small practice. Do not present a stable redirect configuration as a guarantee of rankings, traffic or leads.

Keep permanent redirects in place for the long term. Google generally advises retaining them for at least a year, and longer retention is useful when old links remain in print, articles and saved bookmarks. If the studio has moved to a new domain, remember to renew that domain and its hosting arrangements while the redirects are still needed.

Make URL ownership part of the website handover.

After the redesign, someone will publish the next project and eventually rename an existing one. Decide who can edit public slugs, who approves a permanent redirect, where the mapping file lives and how a broken link gets reported. Otherwise the careful migration work can unravel the first time a project title changes.

The CMS selection guide