What should you audit before touching the site?
Before you change layouts, copy, navigation, or templates, audit the pages that already drive traffic, leads, and links. A website update is much easier when you know which pages are worth protecting and which ones can be rebuilt without risk.
At Virdis, we start with the same questions on every redesign or migration: Which landing pages already convert? Which URLs earn impressions? Which pages have backlinks? Which templates carry the brand’s best proof? That gives us a baseline before we change anything visible.
Use this pre-flight checklist:
- Export all indexable URLs from the current site.
- Pull top landing pages, assisted conversions, and engaged sessions from GA4.
- Pull queries, impressions, clicks, and average position from Google Search Console.
- Identify pages with backlinks or strong referral traffic.
- Mark each page as keep, improve, merge, redirect, or remove.
- Save screenshots and copy snapshots of the current pages.
- Record title tags, meta descriptions, canonical URLs, and internal links.
Google Search Central says search engines discover most pages through links and that SEO is about helping search engines understand your content and helping users make a decision about whether to visit it (SEO Starter Guide). In practice, that means the update should preserve the paths already working.
Which pages and URLs must stay stable?
The pages that should stay stable are the ones that already carry demand, proof, or conversions. If a URL is performing, keep it. If it must change, map it directly to the closest replacement and avoid unnecessary renames.
A useful rule: if a page has traffic, backlinks, or a conversion role, it is not “just a page.” It is an asset.
| Page type | Default move | Why |
|---|---|---|
| Homepage | Keep the URL if possible | It anchors brand discovery and navigation |
| Product or service pages | Keep or 1:1 redirect | They usually carry high-intent searches |
| Use-case pages | Keep or 1:1 redirect | They match buyer intent and long-tail queries |
| Comparison pages | Keep or 1:1 redirect | They often rank for bottom-of-funnel searches |
| Case studies | Keep or 1:1 redirect | They support trust and E-E-A-T |
| Blog posts | Keep stable slugs when possible | They accumulate internal links and rankings over time |
| Contact / demo pages | Keep stable URLs | They sit at the end of the conversion path |
Google’s site-move documentation recommends mapping old URLs to new ones, updating internal links, creating a new sitemap, and using permanent server-side redirects when URLs change (Site Moves and Migrations). That advice applies even when the “migration” is only a redesign.
If you are changing a lot at once, slow down. We usually prefer one of these sequences:
- Content refresh only.
- Visual redesign on the same URLs.
- CMS / template cleanup.
- URL changes with redirects.
- Domain or platform move last.
Bundling all five into one launch is where SEO risk climbs fast.
How should redirects, canonicals, metadata, and internal links work?
Redirects, canonicals, metadata, and internal links need to tell the same story. If a user clicks an old URL, the server should send them to the new destination cleanly. If Google crawls the page, it should see the same preferred URL and the same page relationship.
Use this rule set:
- Use server-side 301 or 308 redirects for changed URLs.
- Redirect old URLs to the closest relevant new page, not just the homepage.
- Avoid redirect chains and loops.
- Update internal links to point to the final URL, not the redirect.
- Keep canonical tags aligned with the final destination.
- Regenerate the XML sitemap after the update.
- Preserve or recreate structured data where it still fits the page.
Google’s migration guide also recommends monitoring traffic on both the old and new URLs in Search Console and analytics, then keeping redirects in place for at least a year (Site Moves and Migrations). That is usually the right move for a B2B SaaS site that has earned links over time.
Internal links deserve the same care. Ahrefs notes that website architecture works best when important pages are easy to reach through well-placed, descriptive internal links (Ahrefs website structure guide). When you update a site, internal links should be rewritten at the source instead of relying on redirects to do the work forever.
A practical mapping workflow:
| Old page | New page | Action |
|---|---|---|
| /blog/old-post | /blog/new-post | 301 redirect + update links |
| /services/legacy-offer | /services/new-offer | Rewrite metadata and body copy |
| /case-studies/old-name | /case-studies/new-name | Preserve proof and backlinks |
| /pricing-old | /pricing | Keep the decision path stable |
The main mistake is changing the visible design but forgetting the technical layer underneath. That is how a polished update still loses traffic.
What content and design changes are safe to bundle?
Content and design changes are safe to bundle when the URL map is already locked, the template logic is stable, and the launch plan accounts for redirect behavior. A redesign can change the layout, hierarchy, imagery, and copy as long as the underlying page intent stays clear.
We usually consider these changes safe to bundle:
- Rewrite headlines and section copy.
- Reorder sections to improve clarity.
- Simplify navigation and information architecture.
- Replace stock imagery with original visuals.
- Consolidate duplicate content.
- Add stronger proof, FAQs, and CTAs.
- Tighten CMS fields so pages are easier to maintain later.
What we do not bundle casually:
- Domain changes.
- CMS migration and redesign at the same time.
- URL structure changes without redirect mapping.
- Heavy design systems that bloat page weight.
- Unreviewed template edits on high-value pages.
During one Virdis migration audit for a SaaS marketing site, we improved the priority template’s LCP from 4.2 seconds to 0.9 seconds after image, script, caching, and rendering fixes. That result held because we protected the key URLs and conversion paths before the visual work started. Good SEO during an update is usually a sequence problem, not a magic trick.
Google’s page experience guidance says good Core Web Vitals thresholds are LCP within 2.5 seconds, INP under 200 milliseconds, and CLS below 0.1 (Core Web Vitals). Think with Google’s research also shows how fast performance matters: as mobile load time increases from one second to seven seconds, bounce probability rises 113%, and as page elements increase from 400 to 6,000, conversion probability drops 95% (Think with Google).
So if the update includes a heavier visual system, make sure the performance budget is part of the brief, not a post-launch apology.
What should you test before and after launch?
Testing should happen in two passes: one on staging before launch and one in production after launch. You want to prove that the site still resolves correctly, the analytics still fire, and the crawler can understand the new structure.
Pre-launch checklist:
- Crawl staging for 404s, redirect chains, and broken internal links.
- Verify the final destination of every changed URL.
- Check canonical tags, robots directives, and noindex states.
- Confirm title tags, meta descriptions, and headings on priority pages.
- Test forms, demo requests, and conversion events.
- Validate structured data on pages that need it.
- Generate a fresh sitemap.
- Confirm image compression and lazy-loading behavior.
- Review mobile and desktop rendering.
- Compare page speed before and after the update.
Post-launch checklist:
- Inspect the top 20 URLs in Search Console.
- Watch crawl errors and 404s for the first few days.
- Check that redirects land on the intended final page.
- Watch top landing pages in GA4 for drops in engagement or conversions.
- Compare branded and non-branded query performance in Search Console.
- Re-crawl the live site after the first deploy.
- Track performance for at least a few weeks before judging the update.
Google says some changes show up in a few hours and others take several months, and that site owners should generally wait a few weeks before judging the effect of a change in Search (SEO Starter Guide). That is why we treat launch day as the beginning of QA, not the end of the project.
Why does a full-stack custom website reduce SEO risk?
A full-stack custom website reduces SEO risk because it gives you control over the parts that matter most during an update: URLs, templates, CMS fields, internal links, analytics events, image handling, and deployment. If the site is built as a structured system, the update can be tested and shipped predictably instead of being assembled page by page.
That is where a full-stack setup like Next.js or Astro + headless CMS + hosting like Vercel or Netlify can help, especially when the site needs reusable templates and structured content rather than one-off page edits. The point is not the framework name. The point is control.
At Virdis, we tend to build updates around these guardrails:
- Slugs live in the CMS, not in hand-edited page files.
- Navigation and CTAs are reusable components.
- Tracking events are standardized across templates.
- Images have size and alt-text rules.
- Redirects are part of the release process.
- SEO fields are required, not optional.
That structure makes it easier to keep a site maintainable after launch. It also connects naturally to the broader planning work in website structure for SEO, how to add Google Tag Manager to a website, and B2B SaaS web design.
If you want the short version: custom full-stack sites make SEO safer because the update is governed by a system, not by guesswork.
Frequently asked questions
Can I update my website without losing SEO rankings?
Yes, if you treat the update like a controlled migration. Protect the pages that already rank, keep URL changes minimal, redirect every changed URL, and verify crawlability and analytics after launch. Temporary fluctuations are normal, but a clean technical handoff usually keeps the long-term damage low.
Do I need a 301 redirect for every changed URL?
Yes, when an indexed URL changes and the old page still has value, a 301 or 308 redirect is the right default. Redirect the old page to the closest relevant new page rather than sending everything to the homepage. That preserves context for users and search engines.
Should I keep the same URL structure during a redesign?
Usually, yes. If the current URLs already have traffic or backlinks, keeping them stable is the safest option. Change the structure only when the information architecture truly needs it, then map old URLs to new ones before launch.
How long does SEO recovery take after a website update?
Google says some changes are visible in hours while others take several months, and it recommends waiting a few weeks before judging impact. In practice, small clean updates can settle quickly, while larger migrations may take longer to fully stabilize.
What breaks SEO most often during a redesign?
The most common failures are missing redirects, broken internal links, noindex mistakes, canonical mistakes, and pages that get buried in the new structure. Heavy scripts and slower pages can also hurt performance and conversion rates even if rankings hold.
