Keep what still works
Website redesign
A redesign starts with an inventory. Before changing the appearance, identify the pages, content, links, and customer paths that your business already depends on.
Build your site01
Does the site need a redesign—or a focused repair?
An outdated service list, a failed form, or a confusing menu may need a targeted fix. A redesign becomes a stronger option when the structure no longer matches the business, routine updates are difficult, or customers cannot complete important tasks on a phone.
Customer friction
Try finding a service, reading the price explanation, and contacting the business on a small screen. Record where the task breaks down.
Content drift
Compare the current offering with the site. Identify obsolete pages, missing answers, and duplicated information.
Operational friction
List the updates your team avoids because the tools, access, or documentation are missing.
02
Start with discovery and an audit
Bring the current URL, a list of known problems, and the tasks the replacement site must support. Read-only access to available search and analytics reports can help identify pages worth preserving; reports are evidence, not a promise about future traffic.
The planning inventory should cover public URLs, content, images, forms, integrations, hosting, DNS, and account owners. Agree which items stay, change, or retire before treating the redesign as a fixed scope.
03
Move the content with a written URL map
Give every existing page a destination. Keep useful URLs when possible. When a URL must change, map it to the closest relevant replacement and use a permanent redirect. Sending every retired page to the homepage usually fails to answer the visitor's original question.
Update internal links, canonical URLs, and the sitemap to point to final destinations. Preserve important text, page titles, image descriptions, and useful downloads unless there is a reason to change them. Check that staging restrictions are removed from the production pages intended for search.
A migration plan reduces avoidable errors, but it cannot guarantee rankings or uninterrupted search traffic. Check Search Console after launch for crawl errors and unexpected canonical choices.
04
Test the design against real tasks
Responsive design needs readable text, usable controls, and a clear order of information at narrow widths. Keyboard navigation, visible focus, labeled forms, useful image descriptions, and reduced-motion behavior belong in the review.
Run through complete tasks: open a service page, follow a contact link, submit a test inquiry in an agreed test environment, and confirm its destination. Screenshots alone cannot establish that a website works.
05
An example of planning for changing content
Battle of the Buildings illustrates a content-lifecycle decision: an event site needs to make sense after its date has passed. Its structure includes results and a recap alongside event information. This is work built by Austin Brower and credited to Battle Bound Branding LLC; it is an example of a design decision, not a claim of a measured redesign result.
06
Define the launch and handoff
Record a backup, rollback approach, launch checks, and who controls each account. Confirm that forms and email delivery still work after DNS or hosting changes. Agree who checks the site after launch and who will maintain it going forward.
Wild Logic keeps build costs, optional ongoing care, third-party expenses, and review-required scope separate. Describe your existing site and what needs to change so migration work can be included in the written scope.
Put the plan to work.
Configure a site without sharing your email, or bring your questions to a conversation.