Your Website Redesign is Bigger than a New Look: A Modern Process For Your Team

Discovery is the cheapest hour you will spend on the project and the highest-leverage one. Before anyone sketches anything, you need a single sentence that explains what changed in the business and why a redesign is the answer this quarter instead of next year. Did revenue stall? Did the brand change? Are you adding a new product line, opening a new region, hiring a CMO who wants to see different metrics? The shape of those answers shapes everything that follows.

There are three discovery inputs, and the redesigns that go well respect all three of them. Stakeholders tell you the goal and the constraint. Users, talked to or quietly watched, tell you what they actually try to do on the site. The data you already have, including analytics, support tickets, and the CMS frustrations your editors have been quietly working around, tells you where the current site is leaking. The output is one written brief that ties every redesign decision back to a known input. Without that brief, the redesign drifts toward the loudest voice in the room.

The framing we like to borrow from product design is jobs-to-be-done. Instead of asking "who is our user," ask "what is the user trying to get done when they show up on this page." The answers tend to be surprisingly specific and immediately useful. They turn vague aesthetic conversations into concrete decisions about hierarchy, copy, and which CMS components your editors will need on day one.

The original site was built by people who were paying attention. Understand their rationale before you tear anything out. Even when the visual layer feels tired, the information architecture, the editorial workflow, and the platform choices often contain decisions that earned their place. A redesign that erases those decisions without naming them tends to recreate the same problems with new typography.

We run three audits in parallel during the first two weeks of an engagement. Each one answers a different question, and together they become the evidence base for the redesign brief.

• UX and analytics audit. Entry and exit patterns, funnel conversion, where users abandon. Heatmaps where they help, qualitative session reviews where they help more. The point is to find friction, not to admire the chart.
• Technical audit. Core Web Vitals (LCP, INP, CLS), accessibility against WCAG AA, security headers, framework age, dependency health, and the editorial limitations your team has been quietly working around. This is the audit most teams skip and most regret skipping.
• Competitive scan. Direct competitors and, just as importantly, products outside your category that solve a similar shape of problem. Staying inside your industry only teaches you the industry's shared blind spots.

The deliverable from this phase is one document that pairs every "problem to solve" with evidence. If a problem cannot be tied to a real user behavior, a real business goal, or a real technical constraint, it is not a problem worth solving in this redesign. That discipline alone trims weeks off the work later.

Once the brief exists, the most important decision is what to keep, what to redesign, and what to reinvent. The framework that holds up well in practice is a simple value-versus-effort matrix. Plot every idea on it and let the picture make the case.

The honest insight, paraphrased from the classic UX redesign playbook: marginal improvements on an already-good design require exponentially more work than fixing a clearly poor one. When the site you have is mediocre, redesigning the visible layer gets you a lot of value cheaply. When the site is already polished, the gains from another visual pass are small, and the right answer is often to reinvent the part of the site that has been holding you back. Usually that is the platform, the editorial experience, or the way the site shows up in AI search.

Technology choices can also move ideas across quadrants. A headless CMS can turn "publish a landing page in a new region" from a multi-week ticket into a Tuesday afternoon task. An AI assistant grounded in your own content can turn "answer the same five sales questions on every call" from a recurring problem into a feature on the site. Things that were high-effort five years ago are sometimes low-effort now, and your prioritization should reflect that.

A redesign is the only time platform decisions are politically easy. The budget is open, the leadership team is paying attention, and "we are rebuilding the site anyway" is the rare sentence that ends most legacy debates without a fight. If you skip the platform conversation now, you will not get another open window for years.

Choose a CMS your marketing team can actually live in

The CMS is the building you ask your marketing team to walk into every day. If it was selected five years ago, it was probably chosen before headless was mainstream, and the editorial workflow likely fights the brand instead of supporting it. A modern headless CMS like Prismic or Strapi lets your team ship pages, campaigns, and content updates without filing a developer ticket. Editorial autonomy is a brand-fidelity issue, not a developer-convenience one. We wrote about the trade-offs in detail in our piece on headless CMS versus WordPress and Squarespace.

Pick a frontend stack you will not regret in three years

The frontend choices that hold up are the ones designed for type safety, performance, and longevity. React 19, TanStack Start, TypeScript, and Tailwind v4 are the stack we ship every site on, including this one. The benefits show up most clearly two years after launch, when the site needs to do something new and the team can still ship without rewriting it. If you are migrating from WordPress and want the longer argument, our piece on building real web applications beyond WordPress goes deeper.

Plan for portability, not vendor lock-in

Hosting, analytics, and the auxiliary services you bolt on should be chosen with an exit in mind. A redesign that locks you into a single platform's proprietary features is a redesign that will need to be redone the next time that platform changes its pricing model. The boring answer (standard runtimes, portable build outputs, swappable analytics) is almost always the right one.

AI in a website redesign should be a planned feature, not a "let us add it later" sticker. The principle we publish on our AI integrated solutions page is the one we hold ourselves to: production features with guardrails, observability, and UX built for your users. Not demos.

There are three places AI realistically belongs on a content site in 2026, and they are not all equally useful for every brand. Walk through them with your team and pick the ones that match how your customers actually decide to buy.

A conversational assistant grounded in your own content

A useful AI assistant on a marketing site is not a generic chatbot. It is a retrieval system that answers questions from your real content, cites the source page, and stays inside the lines of what your team has actually written. The Ask AI tool on this site is our working example. We documented how it is built in Building Ask AI, including how we handle rate limiting, citations, and the off-topic guardrails that keep the assistant from drifting away from the brand.

Semantic search that understands intent

Keyword search has aged poorly. A visitor searching for "how do you build with AI" should land on the right page even if those exact words appear nowhere on it. Semantic search uses embeddings to match meaning rather than tokens, and the implementation is no longer exotic. In a redesign it tends to be the single most-noticed improvement for power users and for your sales team in demos.

Intelligent automation behind the scenes

Most of the AI value on a marketing site is invisible to the visitor. Lead classification, form routing, content tagging, internal summarization, automated competitive monitoring. These are not flashy, but they are where the time savings live, and the redesign is when they are easiest to wire in without a separate budget conversation.

AI Overviews, ChatGPT, Perplexity, and Claude now answer a growing share of the questions your prospects used to type into Google. If your site does not show up in those answers, you do not exist for that part of the funnel. The good news is that AI search rewards the same things good SEO has always rewarded: clear writing, structured content, and pages that answer real questions in a way that can be quoted.

There are a handful of practical things to plan for during a redesign so you are not retrofitting them later.

• Clean, semantic HTML and schema.org markup. AI crawlers parse the same DOM your browser does. Well-structured pages with proper headings, lists, and JSON-LD describe your content to a machine without any extra effort from your team.
• An llms.txt and a clear crawler policy. Decide which AI crawlers you allow and document it. The current best practice is published, and ignoring it is a choice with consequences.
• Passage-level clarity. AI engines cite short, answerable paragraphs. Write the way you would want to be quoted, with the answer at the top and the nuance underneath.
• Agent-callable structure. For the parts of your site that should be machine-readable (pricing, availability, product specs, contact paths) expose them as structured surfaces, not just rendered pages.

We have written separate pieces on both halves of this work. Our "Is Your Website AI Search Ready" piece is the right primer for the discoverability side, and agent-callable APIs as enterprise table stakes covers the structural side for teams that want to go further.