How to Check Your Website After a Redesign

A redesign is the most optimistic thing a development team does. New brand, new layouts, new component library. Months of work, finally live. It looks great in Figma. It looks great on the marketing team's MacBooks. And then someone clicks a link in the footer and gets a 404.

Redesigns break things that weren't obviously connected to what you changed. The new navigation structure removed a page that was still linked from three blog posts. The template change renamed heading IDs that were referenced in the table of contents. The image component migration missed a handful of hardcoded paths. None of these were intentional. All of them are now live.

What a redesign typically breaks

Navigation changes

The new nav structure is carefully designed. What it doesn't account for is every other place on the site that linked to pages in the old structure. Pages that were part of the old nav but aren't in the new one often get removed without redirects. Internal links pointing to them turn into 404s.

URL structure changes

New framework, new routing conventions. Switching from /blog/post-name.html to /blog/post-name/. Removing or adding trailing slashes globally. These affect every URL on the site. Redirect maps for URL changes at this scale are easy to get 90% right and hard to get 100% right.

Heading ID changes

New component library, new heading styles, new auto-generated IDs. If the old site generated id="getting-started" and the new one generates id="getting-started-1", every anchor link to that section is now broken.

Asset path changes

Switching from one static asset strategy to another - from /images/ to a CDN, from a CDN to a different CDN, from locally bundled to externally hosted. Images that were hardcoded in content may not follow the new convention.

Template-level link changes

Footer links, sidebar links, related content widgets - these are generated by templates, not by content authors. When a template changes, all links it generates change with it. One incorrect link in a template becomes thousands of broken links across the site.

Pre-launch vs post-launch scanning

The best time to scan is before you go live - against your staging or pre-production environment. This requires the staging environment to be accessible to a crawler, either publicly or via a private endpoint with auth.

If staging isn't crawlable, scan immediately after launch, before any announcement or promotion of the redesign. The gap between "live" and "widely known to be live" is your window to fix silent failures.

The CI/CD approach

For teams that deploy continuously, integrating link checking into the pipeline catches regressions at the point they're introduced rather than after launch. The 4F CLI makes this straightforward:

Running with --skip-external focuses on internal issues only, making it a reliable gate rather than one that breaks on third-party downtime you can't control.

What to prioritize in the results

• -Critical 404s on high-traffic pages - check your analytics for the most-visited pages from the old site and verify each one resolves correctly on the new one.
• -Template-generated links - one broken template link appears once in the report but affects every page using that template. Fix the template, not the individual instances.
• -Broken anchors in documentation - these tend to be referenced by external sites and can't be fixed by others if they break.
• -Missing assets on the homepage - the first impression matters. A missing hero image on launch day is not a great look.