Website rebuild

Free consultation Projects

A rebuild does not start from a blank page, it starts from the list of URLs that bring traffic today. We design the new site so that after the domain cutover every one of those URLs still has somewhere to lead - and so that the copy which actually sells moves across instead of disappearing with the old template.

We have worked with leading companies and startups

Challenges

Three situations where a rebuild costs less than a second site next to the old one

Not every site has to be replaced whole - sometimes fixing a few templates and the path to the form is enough. Book a consultation - we will say plainly whether your case is a rebuild or a targeted repair.

  • „The site still attracts traffic that cannot be recreated”

    Several hundred pages, a blog archive, links from trade articles and directories, history in analytics. Putting a new site up alongside means starting from zero on all of those fronts at once. A rebuild takes that accumulated value as its starting point rather than as something to recover later.

  • „The previous site change cut traffic and nobody won it back”

    The site looks modern, and search entries never returned to their level from before the migration. What we usually find is URLs redirected to the homepage instead of to the matching content, chains of hops, and pages that simply vanished. That can be repaired during the next rebuild.

  • „The offer changed faster than the structure of the site”

    New services arrived, old ones fell away, the customer segment shifted - and the navigation still describes the company as it was four years ago. New copy was added wherever there happened to be room, so today the same subject is told in three places and in three different versions.

Who it is for

Who we run rebuilds for

  • Companies on a website engine that is out of support

    The platform no longer receives updates, plugins drop away one by one, and every change needs the person who remembers why it was done that way. The replacement date is then set by security rather than marketing - which means the migration has to be planned in advance, not improvised in the launch week.

  • Companies merging onto a single domain

    Two sites, two offers and two sets of URLs have to fit under one brand, usually without permission for any existing customer to go missing. We establish which domain becomes the main one and build the redirect map between them together with the new structure of the offer.

  • Manufacturers and distributors with a large catalogue

    Several hundred product and category pages, some of which exist only because somebody once named a product group that way. Here the rebuild is above all a mapping job - deciding what to merge, what to split, and how to route URLs so that cards still appearing in search results are not abandoned.

  • Companies that sell through requests for proposal

    The site is not a business card but the first stage of the sales process, and a break in its operation is a break in incoming enquiries. We plan the cutover like a system rollout - with a window, a checklist and a way back - and we verify the forms and the CRM entry with a test submission before launch.

Four printed interface layouts on a desk: a dashboard, a phone screen, a form and a table, with one block circled in marker

Our difference

What makes our rebuild different

  • We start from the list of URLs, not from a moodboard

    The first document in the project is a sheet with every URL of the current site and the data beside it. Before anyone draws a first screen it is clear which pages carry traffic, which have not been opened in years, and which exist only because nobody dared to delete them.

  • Pages that work today are designed against constraints

    A page bringing search entries does not enter the project as a clean sheet. We write down what has to survive from it - the scope of the topic, the intent of the heading, the internal links - and only within those limits do we change the layout and the way it leads to contact. A refresh then stops being an opportunity to lose rankings by accident.

  • A cutover with a way back, not with hope

    The redirect map goes through a rehearsal on the staging environment, and after launch the old site stays running under a working address. If anything behaves differently than in the rehearsal, going back is a decision that takes minutes rather than a rescue night spent restoring a backup.

  • The project does not end on launch day

    After the cutover we come back three times - after a week, after a month and after a quarter - with the 404 log, a review of redirect chains and a comparison of the URL set in Search Console. Fixes from those reviews are part of the implementation, so nobody has to order or justify them separately.

Process

6–10 weeks from inventory to the domain cutover

  1. Week 1–2

    Site and data inventory

    We collect the full list of URLs from the sitemap, Search Console and server logs, and add the data to each one: traffic, search entries, external links, the date of the last edit. Plus interviews with the people who run the site day to day - because part of the content lives only in sales and never made it onto the website.

  2. Week 2–3

    Content decisions and the new architecture

    Every URL receives one of three decisions - it stays, it merges into another, or it ends with a redirect. Only from that list do we derive the new sitemap, so the structure is not built in isolation from why people come here today.

  3. Week 3–6

    Wireframes, copy and visual design

    Templates are built in order of how many entries they serve. Pages that bring search traffic today are designed against constraints: the intent of the heading, the scope of the topic and the internal linking paths stay, while the layout, the hierarchy and the way to contact change.

  4. Week 5–7

    The redirect map and the migration rehearsal

    The 301 map is built in parallel with implementation and goes to the staging environment together with the site. We walk it URL by URL with a script - every old address has to answer in a single hop, with no chains and no loops. The rehearsal repeats until the exception list is empty.

  5. Week 7–9

    The domain cutover

    Launch inside an agreed maintenance window - the DNS switch, verification of redirects in production, the sitemap, structured data, analytics goals and a test submission from the form. The old site stays running under a working address as the way back.

  6. The first 90 days

    The post-launch observation window

    We read the 404 log, the indexing report and the set of URLs from before the migration compared with the state after it. Fixes coming out of those reviews are part of the implementation, with no separate order and no queue.

Deliverables

Three things. A new site and a complete trace of the old one

  • Site inventory - a decision at every URL

    The full list of the current site's URLs set against the data: search entries, inbound links, the date of the last edit, presence in campaigns. Every URL carries a decision and the reasoning behind it. The sheet stays with you after the project and is the single source of truth about what merged into what.

  • The new site - architecture, templates, copy

    A sitemap derived from the URL decisions, a complete set of templates in desktop and mobile versions, a library of sections for assembling further pages, and rewritten copy wherever the old text did not answer the user's question. Implementation on your platform, or on a new one if the current engine is out of support.

  • Migration package - the 301 map and the cutover plan

    A redirect map tested on the staging environment, a launch scenario broken down by the hour, a checklist to work through after the DNS switch, and a way back in case something behaves differently than in the rehearsal. Plus three post-launch reviews on agreed dates.

Toolkit

What we use

Migration is an area with no room for house conventions - we work on public standards and on data from your own tools, so that every decision can be verified without us in the room.

A workbench from above: two printed interface layouts, a magnifier enlarging one block, a steel ruler and a greyscale step wedge running from white to black, with one line underlined in orange marker
  • 301 redirects in a single hop, no chains
  • Google Search Console - the URL set before and after
  • Core Web Vitals - LCP, INP, CLS
  • WCAG 2.2 AA
  • schema.org structured data carried over from the site
  • A 404 log read through the first 90 days

Next step

Let us talk about your project

Tell us what you have to do. We will come back with scope and a quote.

Free consultation Projects

Selected work

Projects from the kind of sites we rebuild

A selection from the site types that most often reach us as an existing property - corporate, catalogue and shop sites. Some rebuilds run under the client's own brand and those we show during a consultation.

Projects

Outcomes

What you get, by when, and how you can verify it

  • 6–10 weeks

    From the inventory of the current site to the domain cutover - ten weeks is a site with a catalogue and an archive, not a single-page presence

  • 301

    The permanent redirect code set for every URL that changes path - the map is built before implementation and goes to staging together with the site

  • One window

    That is how long the cutover itself takes, and the old site stays under a working address as the way back for the following days

  • 7, 30 and 90 days

    Three post-launch reviews - the 404 log, redirect chains and the URL set in Search Console compared with the state before the migration

The turnaround comes from the schedule described above on this page, and 301 is the standard permanent redirect code in HTTP. We do not promise traffic growth or particular search positions, because they are not the contractor's to decide. We promise a complete set of redirects, reviews on agreed dates, and the fixes those reviews turn up.

Client voices

What our clients say

  • „Working with the Wzór team was a genuinely great experience! They always answered our questions quickly and were flexible about our comments. They have no shortage of creative ideas and are at the same time thoroughly reliable and on time. The end result fully met our expectations; we recommend them to anyone looking for professionals who care.”
    Maja Wieloch-Silecka Operations Director, Bosfor Group
  • „Our clients expect us to act fast and effectively across a very wide scope - from building a brand, through a website with a store, to running an effective sales campaign. Not an easy task, but doable when you have a tight-knit team and partners who take on challenges on the fly. For us, quality, accountability and commitment are key, and working with UX Agency Wzór gives us that 100%.”
    Piotr Alberski Chief Operating Officer, Agencja XO Media
  • „Our cooperation with UX Agency Wzór started with our own website. We really liked the way they work, so we decided to subcontract projects for our clients to them on a White Label basis. We loved their workflow, the way they hand projects over to our team, their documentation and their work on the design system. Now we can take on bigger risks.”
    Mateusz Swół Chief Operating Officer, Sellace

Time and scope

How long a rebuild takes and what drives the quote

6–10 weeks

Six weeks is a corporate site of a dozen or so templates, rebuilt on the platform it already runs on. Ten weeks and beyond is a site with a catalogue, a blog archive or a second language version, and every case where the platform changes along with the site. On a larger scope we split the work into releases, so the most important templates reach production earlier.

  • The number of URLs on the current site and the state of the data about them

  • The number of templates and unique section layouts in the new version

  • The scope of work on the copy - moving it, tidying it up or writing it anew

  • The target platform and whether the site stays on the current one

  • Language versions and the number of domains merging under one address

  • Integrations with CRM, marketing automation and systems on the client's side

FAQ

Questions that come up most often

How much does a website rebuild cost?

We quote every rebuild individually, because two rebuilds with the same number of templates can differ several times over in effort. The range depends on the number of URLs on the current site and the state of the data about them, the number of templates in the new version, the scope of work on the copy (moving it, tidying it up or writing it anew), the target platform, the number of language versions, and whether more than one domain merges under a single address. You get a concrete proposal after a review of your current site - within two working days of the call. The shortest route is a free consultation.

Will the rebuild damage our positions in Google?

We do not promise positions or traffic growth, because they are not the contractor's to decide. We promise what can be controlled - a complete set of 301 redirects for every URL that changes path, keeping the topic and the heading intent on pages that bring entries today, a single hop instead of chains, and three post-launch reviews with the 404 log and a comparison of the URL set in Search Console. A wobble in the first weeks after a migration is normal; our job is to tell it apart from a real fault and fix the latter.

How does a rebuild differ from designing a site from scratch and from implementation?

In the starting point. Website design starts from a blank page - there is no existing structure, copy or URLs, so the first decisions are about positioning and narrative. Website implementation covers putting a finished design onto the chosen platform and making the editorial team self-sufficient. A rebuild concerns a site that is already alive - it has content, history in analytics, external links and a set of indexed URLs, so half the work is deciding what carries forward and how to make the change without breaking continuity.

Can the existing content be kept?

Some of it yes, some of it should not travel. Every URL goes through the inventory and receives one of three decisions - it stays, it merges into another, or it ends with a redirect. Texts that answer a real user question and bring entries are carried over with their topic and scope intact, while the layout and the way they lead to contact improve. Material describing an offer from several years ago, or repeated in three places, is usually merged into one stronger page rather than rewritten three times.

Will the site be down during the rebuild?

No. The new site is built on a separate environment and the current one runs normally throughout the work. Downtime is limited to the agreed window in which we switch the domain - we plan it with you, usually outside peak hours. After launch the old site stays running under a working address as the way back, so reacting to an unforeseen problem is a decision that takes minutes rather than a restore from backup.

Do we have to change the platform the site runs on?

Not always, and it is not the question we start from. If the current system is supported, the team knows how to use it and the problem is structure, content and looks, the rebuild stays where it is and costs less that way. We change the platform when the engine no longer receives updates, when the cost of maintaining plugins outgrows the cost of migrating, or when the editorial team works around the system because asking an outsider is simpler. You get the recommendation with its reasoning, not as an assumption made on day one.

Do you work with our SEO team or instead of it?

With it, and we want it in the project from the first week. Your team or agency knows best which phrases and pages work for results today, so the URL inventory is compiled together and the redirect map goes for review on your side before launch. If there is no such team, we run the migration according to Google's public guidance on site moves and hand over documentation anyone can pick up later.

What if something stops working after launch?

After the cutover we come back three times - after a week, after a month and after a quarter. We read the 404 log, check redirect chains, compare the URL set in Search Console with the state before the migration, and verify analytics goals along with the path from the form to the CRM. Fixes arising from those reviews are part of the implementation, so nobody has to order or justify them separately.

Related services

Related services

Book a free consultation with an expert to discuss your project and get answers to your questions.

- Patryk Korycki, CEO

Schedule a meeting
Book a free consultation