PUBLISHED 03.10.26 · 10 MIN READ

A WEBSITE REDESIGN CHECKLIST FOR AN ESTABLISHED INTERIOR STUDIO

What to audit, preserve, prepare and verify before replacing a website that already carries years of projects and search history.BY PRIYESH TIWARKAR
Atmospheric interior study

An established studio is not redesigning from zero. Its current website contains search equity, project history, working enquiries, external links and knowledge about what clients already respond to. A responsible redesign improves positioning and experience without casually discarding those assets.

01 / DEFINE THE CHANGE

Write down why the redesign is happening and what should be different after launch. Common triggers include changed positioning, better work than the website shows, poor mobile presentation, difficult publishing or low-quality enquiries. Turn the trigger into a small set of outcomes. A visual refresh without a business purpose will struggle to make consistent decisions.

02 / AUDIT THE CURRENT SITE

Record every live route, title, description, heading, canonical URL, status code and important internal link. Review search and analytics data where available. Identify pages with impressions, backlinks, enquiries or useful rankings before changing their URLs. The audit becomes the migration map and prevents valuable pages from disappearing unnoticed.

03 / PROTECT SEARCH EQUITY

Choose one preferred hostname, retain strong URLs where sensible and prepare a one-to-one redirect for every address that changes. Carry forward meaningful page topics, metadata and internal relationships rather than redirecting everything to the homepage. Update the sitemap, test canonical tags and keep old redirects active after launch.

04 / REASSESS POSITIONING

The studio may have moved beyond the language written several years ago. Clarify the clients, sectors, locations and project scale the practice wants next. Replace broad claims with evidence the portfolio can support. UK focus should be expressed honestly; do not imply an office, team size, award or geographic presence that does not exist.

05 / REVIEW EVERY PROJECT

Create a project inventory with status, strategic value, photography readiness, permissions, credits and missing information. Decide what should be featured, archived, rewritten or omitted. A redesign is an opportunity to improve the edit—not an obligation to migrate every old page into a newer visual shell.

06 / ASSIGN CONTENT OWNERS

Name who supplies project facts, selects photography, confirms credits, approves copy and makes final decisions. Set dates early. Content delays are rarely solved by more interface design. Real material should enter wireframes and prototypes before development is complete so image crops, titles and page lengths are tested under realistic conditions.

07 / TEST THE SYSTEM

Review navigation, project discovery, enquiry paths and editing workflows before polishing motion. Test responsive layouts with the longest title, weakest image and densest case study—not only the perfect example. Include keyboard access, reduced motion, image alternatives, loading behaviour, browser coverage and form errors in the quality-assurance plan.

08 / PREPARE THE LAUNCH

Freeze final content, confirm domain access, back up the current site and agree a release window. Validate redirects, analytics, consent behaviour, metadata, social previews, forms, sitemap and robots rules in production. Crawl the new website after launch and compare it with the route inventory rather than assuming a successful deployment means a complete migration.

09 / PLAN THE FIRST MONTH

Monitor errors, indexing, enquiries and real user behaviour after release. Keep a short care period for urgent fixes and document how the studio will publish projects going forward. A redesign becomes valuable through continued use; without ownership and a publishing rhythm, even a flexible new system can become another static archive.

THE GO / NO-GO QUESTION

Do not launch because the new homepage looks finished. Launch when the important content is approved, critical journeys work, changed URLs have verified redirects, tracking is operating and the team understands the system. If those conditions are not met, record the dependency and move the date rather than hiding the risk.