Start a project

AI BUILD / WEBSITE REDESIGN

Rebuild the website. Account for what it carries.

Aevrion provides website redesign services with the SEO migration engineered as part of the same engagement — one project covering the rebuild and the URLs, content, links and search relationships the existing site already carries.

A redesign that ignores the existing system throws away history it did not measure. A redesign that preserves everything changes nothing. The work is deciding—explicitly, page by page—what stays, what changes and what goes.

Start a website project When a redesign is justified

01 / WHEN A REDESIGN BECOMES NECESSARY

Age is not the reason. These are.

An older website that still does its job does not need a rebuild. A redesign is justified when the site actively works against the business—in recognizable, inspectable ways.

  1. 01

    POSITIONING MOVED ON

    The business changed—offers, audience, category—and the website still describes the previous company.

  2. 02

    ARCHITECTURE MISMATCH

    The page structure grew by accretion; the information architecture no longer matches how the company actually works or sells.

  3. 03

    TEMPLATE CEILING

    The theme or builder that got the site launched now dictates what the business can say and show.

  4. 04

    MOBILE COMPROMISE

    The mobile experience is a compressed desktop rather than an intentional composition—and most visitors see it first.

  5. 05

    TECHNICAL DEBT

    Performance, plugins, hosting constraints or accumulated workarounds make every change slower and riskier.

  6. 06

    CONVERSION CONFUSION

    Visitors cannot tell what the company does or what to do next, and the paths that matter are buried.

One of these alone may justify a focused intervention instead. Several together are what a redesign is actually for.

PLANNING A NEW WEBSITE INSTEAD? EXPLORE AI-NATIVE WEBSITE DEVELOPMENT

02 / START WITH THE EXISTING SYSTEM

You cannot replace what you haven't measured.

Before anything is designed, the current site is inventoried as a system. The inventory is a baseline for decisions—not a promise that every element survives the rebuild.

  1. 01

    ROUTES + URLS

    Every current route and URL, because each one may carry links, bookmarks and search history that a rebuild must decide about.

  2. 02

    CONTENT

    What each page actually says, what still serves the business and what exists only because it was never removed.

  3. 03

    METADATA + STRUCTURED DATA

    Current titles, descriptions, canonicals and any structured data—signals the new system either carries forward or deliberately changes.

  4. 04

    INTERNAL LINKS

    How the pages reference each other today, and which relationships the new architecture must preserve or improve.

  5. 05

    SEARCH EVIDENCE

    Available analytics, Search Console and backlink evidence—owner-supplied inputs that turn migration opinions into decisions.

  6. 06

    FORMS + INTEGRATIONS

    Every form, embed and connected system, so nothing operational disappears in the rebuild unnoticed.

  7. 07

    NAVIGATION + CONVERSION PATHS

    How visitors currently move and convert—the journeys the redesign changes on purpose rather than by accident.

  8. 08

    TECHNICAL CRAWLABILITY

    How the current site is crawled and indexed, establishing the baseline the new system will be validated against.

Search Console, analytics and backlink exports are owner-supplied evidence. Where they exist, decisions get sharper; where they do not, the inventory says so.

03 / WHAT CHANGES, WHAT STAYS

Every page gets a verdict.

Redesign is a series of explicit content and route decisions, recorded with their reasons. Five verdicts cover the inventory—and nothing is decided by default.

  1. 01

    KEEP

    The page earns its place: the URL and content carry forward, improved where useful.

  2. 02

    REWORK

    The intent is right but the execution is not: the content is rebuilt around the new architecture.

  3. 03

    MERGE

    Several thin or overlapping pages consolidate into one stronger page with a clear owner.

  4. 04

    REDIRECT

    The URL's job moves elsewhere: a 301 carries visitors and link equity to the closest real destination.

  5. 05

    REMOVE

    The page no longer has a job. It is retired deliberately—with evidence, not by accident.

The decision map is a deliverable. When someone asks later why a page moved or disappeared, the answer is on record.

04 / REDESIGN SYSTEM

Design and migration move as one plan.

Six stages, each ending in something the project can be held against. The migration is not a launch-week task—it is planned from the first stage.

  1. 01

    INVENTORY

    Capture the existing system: routes, content, metadata, links, integrations and available search evidence.

    OUTPUT / DECISIONA factual baseline instead of assumptions about the current site.
  2. 02

    DECIDE

    Take every page through keep, rework, merge, redirect or remove—with the reason recorded.

    OUTPUT / DECISIONAn explicit content and URL decision map.
  3. 03

    ARCHITECT

    Design the new information architecture, routes, content responsibilities and redirect mapping together.

    OUTPUT / DECISIONAn approved architecture that already knows its migration plan.
  4. 04

    REBUILD

    Produce the new system—content, design, development—against the approved architecture.

    OUTPUT / DECISIONA complete candidate ready for structured validation.
  5. 05

    VALIDATE

    Check redirects, canonicals, metadata, internal links, crawlability and rendering before anything goes live.

    OUTPUT / DECISIONEvidence the migration behaves as mapped—before cutover.
  6. 06

    CUTOVER

    Launch deliberately, then verify the live system: status codes, redirects, indexing behavior and the paths that matter.

    OUTPUT / DECISIONA controlled transition with post-launch verification, not a launch-day surprise.

05 / SEARCH + MIGRATION ARCHITECTURE

Reduce avoidable loss. Promise nothing you don't control.

The migration workstream exists to make deliberate, evidence-informed decisions about everything the old site carries into the new one.

  1. 01

    URL MAPPING

    Every changed URL gets an explicit destination decision before launch—not a wildcard to the homepage.

  2. 02

    REDIRECTS

    301 redirects where URLs change, applied per mapped decision and tested at the edge.

  3. 03

    CANONICALS + METADATA

    Canonical intent, titles and descriptions reviewed against the new architecture rather than copied blindly.

  4. 04

    INTERNAL LINKS + STRUCTURED DATA

    Internal references updated to final destinations; structured data reviewed and carried only where it describes visible reality.

  5. 05

    SITEMAP + CRAWLABILITY

    Sitemap behavior, robots intent and technical crawlability planned as part of the build, then verified against the implementation.

  6. 06

    PRE- + POST-LAUNCH VALIDATION

    The mapping is checked before cutover, and the live system is verified after it—status codes, redirects and indexing behavior.

WHAT THIS DOES NOT PROMISE

Search performance cannot be guaranteed during or after a redesign or migration. Rankings, traffic and indexing behavior are decided by external systems responding to many factors, and a migration—however carefully engineered—is a change those systems will evaluate.

Aevrion will not promise “no SEO loss” or “preserved rankings.” It will plan against avoidable loss, validate before cutover, verify after launch and show the work.

WHAT THAT LOOKED LIKE ON AEVRION’S OWN SITE

This website is the worked example. Aevrion rebuilt aevrionops.com and migrated it off its previous WordPress system, and the migration decisions are recorded per URL rather than summarised: forty-two legacy URLs inventoried, twenty-six given a permanent redirect to a live page, four retired to a truthful 404 on the evidence, one rebuilt — and eleven thin tag archives left explicitly undecided, because URL-level evidence for them was unavailable and inventing a decision would have been worse than recording that there wasn’t one.

Every redirect lands on a page that returns 200, with no chains and no loops. Nothing was swept to the homepage to avoid a 404. Those are properties anyone can check from outside the company, which is the reason for publishing them rather than describing them.

READ HOW AEVRION REBUILT AND MIGRATED THIS SITE

Two related routes go further than this page deliberately does. A migrated site is also being re-read by retrieval systems that judge it differently from a ranked result, which is set out in what changes when machines read your site. And where the site belongs to a garage door company, the assets most often discarded in a rebuild are specific to that trade — symptom pages, service-area structure and the commercial section — which garage door website redesign and SEO migration covers in detail.

06 / UX + RESPONSIVE RECOMPOSITION

A redesign is not
a repaint.

New colors on the old structure change nothing that mattered. A real redesign recomposes the system: hierarchy rebuilt around what the business now is, content rewritten for the jobs pages actually have, navigation and conversion paths redrawn around how visitors decide, and interaction designed rather than inherited.

Responsive behavior and accessibility are build requirements, not polish: mobile gets an intentional composition instead of a compressed desktop, and semantic structure, keyboard behavior and readable contrast are verified against the implementation.

If the redesign only changed how the site looks, it did not change what the site does.

07 / PLATFORM + CMS DECISIONS

The platform follows the requirement.

A redesign is a natural moment to re-evaluate the platform—and a bad moment to pick one on preference. Aevrion is tool-independent: the recommendation follows the actual requirement.

WHAT DECIDES THE PLATFORM

Content operations—who edits what, how often, with what workflow. Integrations and data movement the business depends on. Performance and deployment needs. Long-term ownership and maintenance: who runs this system after launch, with what skills and budget. The existing investment, where staying is genuinely cheaper than moving.

Staying on the current platform is a legitimate outcome. So is moving. What Aevrion will not do is make that call before the requirement, the content operation and the migration cost are actually understood.

08 / OWNERSHIP + CUTOVER

Launch is a controlled transition, not a leap.

The old site keeps working until the new one has proven it is ready. Cutover is planned with the same discipline as the build itself.

01

READINESS BEFORE LAUNCH

The candidate is validated first: redirects at the edge, canonicals, metadata, internal links, rendering and crawlability checked against the mapped decisions—while the current site continues operating.

02

DELIBERATE CUTOVER

Domain and DNS changes are planned and sequenced rather than improvised, with the launch window, checks and responsibilities agreed before anything switches.

03

VERIFIED AFTER, OWNED ALWAYS

Post-cutover verification covers status codes, redirects and indexing behavior. Access, documentation and handoff make the rebuilt site a maintainable business asset with clear ownership.

Readiness includes knowing what would happen if something went wrong—verification is designed so problems surface in validation, not in production.

09 / DECISION SUPPORT

Questions to resolve before a redesign.

01Can Aevrion redesign an existing website?

Yes—when the current site, business requirement, content, technology and migration constraints can be assessed. The engagement starts with an inventory of what exists, and the responsible recommendation may be a full rebuild, a phased redesign or a more focused intervention.

02Will we keep the same URLs?

Some, usually. Each URL gets an explicit decision—keep, rework, merge, redirect or remove—based on its job and available evidence. URLs that change receive mapped 301 redirects; nothing is left to a blanket rule.

03Can Aevrion migrate our content?

Yes, deliberately rather than wholesale. Content is inventoried and taken through the same decision framework as URLs; what carries forward is improved to fit the new architecture, and what is retired is retired on record.

04Can Aevrion preserve our existing SEO?

Aevrion can treat migration as an engineering workstream—inventory, redirect mapping, canonical and metadata review, pre-launch validation and post-launch verification—to reduce avoidable loss. Search performance cannot be guaranteed during or after a redesign; anyone promising zero SEO impact is promising something search engines decide.

05Can the redesign move us to another platform?

Potentially. Platform choice follows requirements, content operations, integrations, ownership, maintenance and performance—not a default preference. A platform change adds migration scope, and that scope is planned explicitly rather than discovered.

06Can Aevrion redesign only part of the site?

Sometimes that is the right recommendation: a phased redesign that rebuilds the highest-value sections first while the rest continues operating. The inventory and evidence determine whether partial or complete is responsible.

07Who owns the rebuilt website?

The business does. Repository and platform access, dependencies, licensing, content responsibilities, documentation and handoff are defined before delivery—the same ownership standard as every Aevrion build.

08What affects redesign scope and cost?

Size and condition of the current site, content readiness, how much of the URL inventory must be mapped, platform decisions, integrations, migration risk, accessibility and performance requirements, and the level of validation the launch demands.

10 / START WITH THE CURRENT SITE

Rebuild on purpose.

Share the current website, what the business has become and what is not working. Aevrion will help determine whether the answer is a complete rebuild, a phased redesign or something more focused—and what the migration actually involves.

Start a website project