How to Document a Website Redesign Case Study

Most redesign case studies are just a before screenshot and a vague claim about “increased engagement.” That’s not a case study. It’s a brochure. Here’s how to actually document a redesign in a way that means something.

What a Website Redesign Case Study Actually Needs

A real website redesign case study starts before the redesign does. You need a baseline. That means pulling your Google Search Console data, your Core Web Vitals report, your bounce rate, your average session duration, and if you’re tracking leads, your form submission count for the past 30 to 90 days. Write it all down somewhere before anyone touches the site. Screenshots count. A simple spreadsheet counts. The point is that you can’t measure improvement if you didn’t measure the starting point.

Beyond numbers, document the qualitative baseline too. What did the old site make visitors do? What was broken, confusing, or missing? The best way to get at this is to have someone who’s never seen your site try to find your contact form or your pricing page while you watch. You’ll learn things in five minutes that your analytics couldn’t tell you in six months.

The Four Baseline Problems Worth Documenting

Not every problem is worth documenting, and not every problem is worth fixing in the same redesign cycle. The four categories that actually matter for a case study are: page speed (measurable with PageSpeed Insights or Lighthouse), mobile usability (check Google Search Console’s mobile usability report), crawlability issues (broken links, missing metadata, pages that aren’t indexed), and conversion path clarity (can a visitor actually figure out what to do next).

For each problem, write one or two sentences describing what it is, then note how you confirmed it was a problem. “The homepage took 11.3 seconds to load on mobile” is useful. “The site felt slow” is not. If your old site had images that weren’t compressed, say so. If your contact page was buried three levels deep in the navigation, document that too. Specificity is the whole point.

Decision Log: Why You Did What You Did

This is the section most case studies skip entirely, and it’s the most useful part for anyone reading. For every significant decision in the redesign, write down the problem it was solving and the alternative you considered but rejected. This doesn’t have to be a novel. A single paragraph per decision is plenty.

For example: the old navigation had eight items, including a “Resources” dropdown that led to a single blog post from 2019. The decision was to collapse the navigation to four items and remove the dropdown entirely. The alternative was to populate the Resources section with more content, but that would have delayed the launch by weeks and the analytics showed almost no traffic going to Resources anyway. That’s a decision log entry. It tells the reader that the choice was deliberate, not arbitrary, and that you weighed the tradeoffs.

When Web Lift Up documents client work internally, this kind of log is what makes it possible to explain choices to clients during the revision phase. It also makes it easier to write honest case studies later, because you’re not reconstructing decisions from memory months after the fact.

A Real Example: Indiana Photo Booth

Indiana Photo Booth is a photo booth rental company based in Indianapolis. Their old site had a homepage that loaded slowly on mobile, a contact form that was hard to find, and no structured data helping search engines understand their service area or what they offered. The booking inquiry process was unclear, and the site had no metadata on most pages.

The redesign focused on four things: cutting page weight to hit a Lighthouse mobile performance score above 85, restructuring the navigation so the booking inquiry was one click from anywhere on the site, adding proper metadata and structured data to support local SEO, and rewriting the homepage headline so it actually described the service instead of being a generic tagline. After launch, the Lighthouse mobile performance score came in at 91. The contact form became the second most visited page on the site within the first two weeks. These are the kinds of before-and-after numbers that belong in a website redesign case study, because they’re specific and they’re tied to specific decisions.

What the case study should also note: the organic search improvements take months to show up fully. A redesign that ships in seven days doesn’t produce six months of SEO data in the first week. Documenting that limitation honestly is part of what makes the case study credible.

How to Measure Results Without Waiting Forever

You don’t need six months of data to write a meaningful case study. There are things you can measure immediately and things that take time, and a good case study labels them clearly.

Immediate measurements (within 48 hours of launch): Lighthouse scores for mobile and desktop performance, PageSpeed Insights results, Google’s mobile usability test, a crawl with a tool like Screaming Frog to confirm no broken links or missing metadata. These are your “the technical work is done” checkpoints. Thirty-day measurements: form submissions, phone call tracking if you have it set up, page views on key pages, and bounce rate changes. Ninety-day measurements: organic search impressions and clicks from Search Console, keyword ranking movement, and any lead volume trends you can attribute to the new site versus other marketing activity.

The reason to separate these is honesty. If you say “traffic increased 40%” three days after launch, that’s almost certainly noise. If you say it 90 days after launch with Search Console data attached, that’s a finding worth reporting.

What to Include in the Limitations Section

Every honest website redesign case study has a limitations section. Most people skip it because it feels like admitting failure. It’s actually the opposite. A case study that says “we can’t fully separate the SEO impact of the redesign from the Google Ads campaign the client ran simultaneously” is more trustworthy than one that takes credit for everything.

Common limitations worth documenting: seasonal traffic patterns that make month-over-month comparison unreliable, other marketing activity running at the same time, the fact that the client changed their service offering around the same time as the launch, or the reality that the baseline data only goes back 30 days instead of 90. None of these invalidate the case study. They just make it accurate. Accuracy is what makes someone reading the case study trust you enough to become a client.

The other thing worth noting: some improvements are real but hard to quantify. A site that’s easier to navigate is a better site even if the analytics don’t show a clean spike. Saying “the client reported faster responses to customer inquiries after we simplified the contact flow” is honest. Turning that into a made-up percentage is not.

Putting the Case Study Together

The structure that works is straightforward: the business and what they do, the problems with the old site (documented with specifics), the decisions made during the redesign and why, the before-and-after screenshots, the measurable results separated by timeframe, and the limitations. That’s it. You don’t need a narrative arc or a hero’s journey. You need specificity and honesty.

If you’re a business owner who just went through a redesign, this framework helps you know what questions to ask your agency or developer. If you’re an agency, it’s a template for producing case studies that actually demonstrate competence instead of just asserting it.

At Web Lift Up, every project follows a documented process: audit on day one, demo built by day four, revisions through day six, launch on day seven, all for a flat $499 with no retainer and no lock-in. That process generates the kind of timeline and decision data that makes a real case study possible. If your current site needs a before-and-after worth documenting, reach out at info@webliftup.com.