A project page can effectively disappear in a redesign even if its photographs survive. Without the building type, location, scope of work and completion status, a prospective client cannot tell whether the project is relevant. Start by listing what each existing page tells visitors and what needs to remain available after launch—not by choosing a new layout.
Define what the redesign must preserve
For an architecture practice, developer or property owner, a website may explain services to prospective clients, document completed buildings, give tenants or visitors practical information, and host reports for project partners. Better navigation is useful, but it should not come at the expense of those functions.
Set content objectives before choosing a design direction. Identify the audiences and tasks the site must support: finding a service, assessing relevant experience, locating a building, understanding an approval or construction process, or downloading a current document. Record legal, contractual and organizational requirements separately from marketing preferences. An old annual report, for instance, may need to stay accessible without appearing in the main navigation.
Agree on who can authorize removal. A communications lead may edit project descriptions, while a facilities manager may need to approve changes to visitor instructions. Public-sector and institutional sites may also need review by records, accessibility or legal teams. Identify these owners early, before a supposedly obsolete page turns out to serve an important purpose.
Inventory pages, files and information hidden in components
Export current URLs from the content management system, then supplement the list with a public-site crawl and, where available, analytics and search data. No source tells the whole story: a crawl may miss unlinked pages, and a CMS export may omit files, embedded applications or pages managed elsewhere.
For each item, record its URL, title, content type, owner, audience, last review date and proposed action. A short list of actions is enough: retain, revise, combine, archive or remove. Add the intended new destination so the inventory becomes a migration plan rather than a spreadsheet of decisions.
Look beyond standard pages. Useful information may be tucked into PDF brochures, project galleries, expandable panels, staff biographies, downloadable plans, FAQs or older news posts. Check whether visitors use those files and whether their facts are still accurate. A frequently downloaded PDF is not necessarily the best way to present information, but deleting it without understanding its purpose leaves a gap.
Judge value separately from traffic
Page views help prioritize review, but low traffic does not make a page expendable. A specialist healthcare project might get few visits yet answer a decisive question for a prospective client. A heavily visited page, meanwhile, might describe services the practice no longer offers. Assess each page against four tests:
- Use: Does it help a defined audience complete a task or make a decision?
- Accuracy: Are names, dates, claims, contacts and documents still valid?
- Distinctiveness: Does it contain information not adequately covered elsewhere?
- Obligation: Must it remain available for operational, contractual or records purposes?
Write down why a page is removed or combined with another. That note will help when someone later asks where a particular case study, specification or project update went.
Map the new structure before rewriting pages
A navigation menu is only the visible part of a content structure. Group material around what visitors need to understand, then check that every existing and planned page has a sensible place. A portfolio may need filters for building type and project stage; a property site may need a direct route to access information and tenant documents. Avoid categories that look tidy in a menu but leave individual pages hard to classify.
Create a URL map for every address that will change. Record the old URL, intended new URL and treatment of the content. If two older pages become one stronger page, both addresses can lead there if the replacement genuinely covers both subjects. If no suitable replacement exists, do not send visitors to an unrelated homepage just to avoid an error. Consider an archive, a relevant parent page or a clear unavailable-page response instead.
Keep URLs stable where practical. Changing addresses, titles, navigation labels and content at the same time makes post-launch problems harder to trace. For moved pages, use permanent server-side redirects and test each one. Avoid redirect chains, and check that downloadable files and image assets with important inbound references have appropriate destinations.
Protect the meaning of project and service pages
Photography-heavy pages are particularly easy to over-edit. A useful project record identifies the client's brief, the practice's actual role, the building's use and location, its stage, and relevant design constraints. Do not suggest that a proposal was built or that one contributor delivered every part of a multi-party project. If the work is confidential, agree on what can be published rather than leaving visitors with an unexplained image gallery.
Service pages also need clear boundaries. Explain what the work includes, what information a client must provide, and how decisions or approvals are handled. A shorter page may be easier to use, but stripping out these distinctions makes the service harder to assess. Rewrite for clarity instead of transferring every sentence unchanged or reducing the page to a slogan.
Plan the migration as a controlled editorial task
Use a staging site and assign content owners to review pages after migration. Automated transfer saves time, but it cannot reliably resolve differences between old and new page components. Tables may collapse on mobile screens, captions may detach from images, and embedded maps or forms may stop working. Set up a small number of page templates, migrate representative examples first, and fix the process before moving the full library.
Review each page in three passes. Is all required material present? Is it accurate and approved? Does it work in the new presentation? That order helps prevent an attractive page from being signed off while its downloadable brief or accessibility information is missing.
Check headings, body text, captions, image alternatives, file links, contact details and metadata. Keep original publication and update dates where they help readers interpret the material; moving an old project announcement should not make it appear new. Retain a version of the old site or a reliable content export until post-launch checks are complete, subject to applicable privacy and retention rules.
Test what visitors can actually find and use
Test realistic tasks rather than relying on a visual approval meeting. Ask someone unfamiliar with the new structure to find a comparable project, identify a service contact, locate site access information or retrieve a specified report. Notice where they hesitate. If success depends on knowing an internal term, change the label or provide another route.
Check common screen sizes and keyboard navigation. Headings should follow a logical order, links should make sense out of context, and essential information should not appear only as text inside an image. Give meaningful images concise alternative text; decorative images do not need descriptions that repeat nearby copy. If a project diagram carries technical meaning, explain enough of it nearby for readers who cannot interpret the diagram alone.
Test forms carefully: required fields, confirmation messages, error handling and delivery to the right team. If the redesign changes how personal information is collected, review the associated notice and internal handling process. A polished contact form that silently fails is an operational problem, not merely a technical defect.
Launch with checks that continue after publication
Before launch, confirm redirects, navigation, site search, forms, downloadable files and access to the content management system. Check that public pages are indexable and staging pages are not. Keep a launch log of known exceptions, with an owner and resolution date for each.
After launch, test a sample of old URLs from each major content type, including deep project pages and documents. Watch broken-page reports, search queries and support requests for signs that visitors cannot find something. Traffic changes may point to a problem, but assess them alongside seasonality, campaigns and any deliberate removal of outdated material. A decline alone does not explain its cause.
Keep the inventory active through the first review cycle. If visitors repeatedly search for a former project name, check its mapped destination and whether the new page actually uses that name. Updating a heading or project index may fix the issue more directly than changing the navigation again.