A Shopify store owner we spoke with spent four months on a rebrand. New logo, new color palette, completely new theme. The site launched to positive reviews from customers and a glowing Slack message from the design agency.

Six weeks later, a customer filed a GDPR data access request. When someone from the team went to look up the privacy@ email address to respond, they realized it was in the policy as [email protected]. That inbox hadn't existed since the rebrand.

The redesign was a success. The trust infrastructure had quietly collapsed.

This is one of the most predictable—and consistently overlooked—risks of any website redesign. You're focused on what's visible: layout, typography, images, navigation. But trust signals live in the seams of a site, and seams are exactly what redesigns tear apart.

Here are the five that break most often.

1. Privacy Policy Links Return a 404

This is the most common problem we find on recently redesigned sites. It ranks first not because it's the sneakiest, but because it affects almost everyone who changes their URL structure.

Redesigns frequently consolidate URLs. A footer link that used to point to /privacy-policy now needs to go to /legal/privacy. Or the old WordPress site used /privacy-policy/ (with trailing slash) and the new one uses /privacy. Or the Webflow migration dropped the policy under a new collection entirely.

The link in your footer still says what it said before. Nobody thought to update it because "the privacy policy is still there, we just moved it." The footer link becomes a 404.

Why it matters:

Under GDPR, your privacy policy must be "easily accessible." A 404 page fails that test immediately. Under CCPA, you must provide "notice at collection"—which requires a working link from every form that collects data. A broken link doesn't just lose you compliance points; it's direct evidence of non-compliance if someone files a complaint.

The fix is simple once you know about it: redirect old URLs, update all footer and in-page links, and verify each one works. The problem is nobody puts "check privacy policy link" on the redesign launch checklist.

2. The Cookie Consent Banner Disappears

Cookie banners are almost always implemented as a snippet of code injected somewhere in the theme—usually the <head> or just before the closing <body> tag. When the theme gets replaced, that snippet goes with it.

This happens on every platform:

  • On Shopify, custom code lives in theme.liquid. A new theme ships a clean theme.liquid. Your consent script isn't in it.
  • On WordPress, code injections often go in header.php or a plugin that was deactivated during the redesign. New child theme, clean slate.
  • On Webflow, the "Custom Code" fields in site settings or page settings get overwritten when a new template is published.

The insidious part: your analytics and tracking scripts continue to run perfectly. Google Analytics didn't live in the theme—it lives in Google Tag Manager. The tracking fires on every pageview. The consent mechanism that was supposed to gate that tracking is gone.

"We assumed the cookie banner was still there because we'd never removed it. It hadn't occurred to us that launching a new theme counted as removing it."

GDPR requires consent before non-essential tracking scripts fire. If your banner disappears and your analytics keeps running, every visit after the theme update is a data collection event without consent. That's not a hypothetical risk—it's the exact violation type that generates enforcement complaints.

This problem is common enough that we wrote a dedicated piece on it: Why Your Cookie Banner Disappears After Theme Updates.

3. The Legal Footer Section Gets Deleted

Minimalism is a strong design trend. Clean footers with just a logo, a few social icons, and a copyright line look professional. Design agencies often propose them.

The previous footer had a "Legal" column: Privacy Policy, Terms of Service, Cookie Policy. The new footer doesn't have columns at all. Those links just don't exist anymore.

This isn't a broken link. It's an absent link. There's no 404 to catch. The pages still exist—they're just unreachable from any normal navigation path on the site.

For users trying to understand how their data is used, or trying to make a data request, or trying to find your refund terms before buying—the only path is direct URL entry or a search engine. Neither is "easily accessible."

For EU users, the right to access privacy information isn't optional. Your site architecture needs to support it, not just technically allow it. If finding your privacy policy requires knowing to type /privacy in the address bar, it's functionally inaccessible.

A minimal footer can still have legal links. They don't need to be prominent—a small, discrete row of links at the very bottom is fine. But they need to exist.

4. Your Data Contact Email Is Now a Dead Address

Your privacy policy contains an email address for data requests, privacy questions, and legal notices. It was accurate when you wrote it. Then you rebranded.

New domain, new company name, new brand email structure. The person who was at [email protected] is now at [email protected]. Or they left the company. Or that inbox never existed and just forwarded somewhere, and the forward is no longer configured.

The privacy policy still says the old address. Nobody updated it because "updating the privacy policy" is a legal task that lives on a different list than "update email infrastructure."

Why it matters:

Under GDPR, you must have a working mechanism to receive and respond to data subject requests—access, erasure, portability. Under CCPA, you must provide a way to submit opt-out and deletion requests. A dead email address isn't a mechanism; it's the appearance of one. If a regulator tests it and gets a bounce, you've just demonstrated non-compliance in the worst possible way.

Privacy contact email addresses should be on your rebrand checklist next to "update email signatures" and "update billing details." They rarely are.

5. robots.txt Now Blocks Your Compliance Pages

This one surprises people. The instinct is that robots.txt is about hiding sensitive things from search engines. But it also hides public things—including compliance pages that regulators and users need to find.

Here's how it happens: a new SEO plugin gets installed during the redesign. The plugin generates a fresh robots.txt automatically. Its default configuration disallows /legal/ because someone thought "legal pages shouldn't be indexed." Or it disallows everything under /pages/ and your privacy policy is now at /pages/privacy.

Your privacy policy is still live. It just can't be found by search engines, by compliance crawlers, or by any tool that respects robots.txt.

This creates an invisible compliance failure. Your own internal checklist will show a green checkbox—the page exists, the link works. But any external compliance audit will flag it.

Check your robots.txt after any CMS migration, SEO tool install, or sitemap regeneration. Specifically confirm that /privacy, /terms, /cookies, and any equivalent paths are not disallowed.

The Common Thread

None of these failures are deliberate. Every one of them happens because redesigns are treated as a visual project, not an infrastructure project. The checklist covers navigation, content, responsive behavior, load speed, analytics tracking. Trust signals are invisible until they're broken—which is exactly why they fall off the list.

There's also a timing problem. The day you launch a redesign is not the day these failures become apparent. They surface weeks later, when a user tries to find the privacy policy, when a lawyer requests a compliance audit, or when a data protection authority follows a complaint. By that point, the design team is on to the next project and nobody clearly owns the original mistake.

A Post-Redesign Trust Signal Checklist

Before and after any redesign, run through this:

  • Visit /privacy-policy, /privacy, and /legal/privacy directly—do they all resolve or redirect correctly?
  • Check every footer link for legal pages: do they all return 200?
  • Load the homepage and check whether a cookie consent banner appears before accepting cookies
  • View the privacy policy and confirm the contact email is current and monitored
  • Review robots.txt: are any legal page paths disallowed?
  • Submit a test message to the data contact email and confirm you receive it

This takes about 15 minutes. Compared to the 3-4 months a redesign typically takes, it's a rounding error.

When Manual Checking Isn't Enough

The checklist above covers launch day. It doesn't cover the week after launch, when a developer pushes a hotfix that breaks a redirect. Or three months later, when a plugin update changes the footer template. Or when someone on the marketing team updates the theme again without telling anyone.

Trust signals fail continuously, not just at launch. The only way to catch post-launch failures while they're still cheap is automated monitoring—something that checks these things regularly and tells you when they break.

If you've recently redesigned your site, running a compliance scan is a fast way to see which of these you've already broken without knowing it.