NODOMIC

Software / Website Design & Redesign

Website Design & Redesign

New sites built properly from the start, and technical rebuilds for sites whose structure, performance, or architecture no longer matches the business behind them — done so that whatever traffic you already have survives the move.

Most redesigns look better and perform worse.

A redesign is usually sold as a visual project, so it gets judged on how the homepage looks on launch day. The damage shows up six weeks later in the analytics: URLs changed without redirects, page titles rewritten by someone who did not know they were earning clicks, content consolidated onto pages that no longer answer the query that used to rank, and a heavier front end that pushed the site below the performance thresholds it used to clear.

None of that is a design problem. It is an engineering problem, and it is invisible until the rankings are already gone. What a site earns in search is an asset, accumulated slowly, and a migration is the single easiest way to lose it. Protecting it is not glamorous work, but it is the difference between a redesign that pays for itself and one that quietly costs more than it cost.

Typical redesign

/services/old-page

ranks, earns clicks

NEW SITE, NEW URLS

titles and structure rewritten

404 · RANKING GONE

noticed six weeks later, in the analytics

Migration done properly

/services/old-page

the same page, still earning

REDIRECT MAP, 301

every path, canonical and hreflang

/services/new-page

ranking kept, checked after launch

A redesign changes the pages. A migration keeps what those pages had earned — every old path mapped to its replacement, canonicals and hreflang carried across, and the result checked in Search Console rather than assumed.

Live and running — technically demanding in different ways.

This site is the fifth. Bilingual, static, hand-built, with reciprocal hreflang across every page and structured data on all of them — the same approach described above, applied to ourselves.

Sometimes it is not — and saying so is cheaper for both of us than finding out afterwards. A rebuild is usually justified when one of these is true:

Structure and content architecture

What pages should exist, what each one is for, and which search intent it answers. Decided before anything is designed, because it determines everything after it.

Build

Static-first where possible — fast by construction rather than fast after optimization. No plugin stack to maintain, and nothing that breaks when a dependency updates itself.

Migration that preserves rankings

Full URL inventory, redirect map for every existing path, canonical and hreflang handled deliberately, structured data, sitemap and robots. Verified after launch, not assumed.

Multilingual

Localized slugs, reciprocal hreflang pairs, and a language switcher that goes to the equivalent page rather than dumping everyone on the homepage.

Performance and accessibility

Images sized and converted at build time, fonts and scripts kept honest, semantic markup, and contrast that works in both light and dark.

Analytics and integrations

Measurement that answers a business question, forms that reach a human, and whatever the site genuinely needs to talk to.

A site that looks better and is found less is a failed redesign.

Search still decides who arrives. What a page is about, which query it answers, how pages link to each other, how fast it loads on a phone — those are build decisions, made while the structure is being drawn, not tasks bolted on afterwards by someone else. A new site that ignores them starts from zero against competitors who have been accumulating for years.

What has changed is the second audience. A large share of questions are now answered above the results, by an assistant summarising a handful of sources. That summary is assembled from pages a machine can read cleanly, and it links back to a few of them. Being one of those few is not luck; it is structure, plain facts, and giving the reader something the summary cannot reproduce.

Built to be understood

Clean URL structure, real page titles, headings that describe the content, and structured data that states what the page is — an organisation, a service, a product, a question with an answer.

Answer-shaped pages

The question answered in the first lines rather than the fifth paragraph, numbers in a table instead of buried in prose, and sources named. That is what an assistant can quote, and it reads better for people too.

A reason to click

A calculator, a configurator, a checker — something the visitor came to use. A summary can restate an article; it cannot run your tool. On our own property, nearly half of all visitors use the one on the page.

We measure this on a property of our own: 1.65 million impressions at an average position of 6.8, and a click-through rate of 1.5% — well below what that position used to earn, because the answers were served above the results. The conclusion is not to give up on search. It is to build the page that is still worth opening.

Read the search case study →

  1. 01

    Inventory first

    Every existing URL, what it ranks for, what it earns, and what links to it. You cannot preserve what you have not written down.

  2. 02

    Structure agreed before design

    Page map, purpose per page, and the redirect plan — signed off while it is still cheap to change.

  3. 03

    Build and review

    Real content in the build, not lorem ipsum, so you are approving the actual thing rather than a mood board.

  4. 04

    Launch and verify

    Redirects tested path by path, search console watched through the transition, and issues fixed in the first weeks rather than discovered in the next quarter.

Thinking about a rebuild?

Send the current URL. You get an honest read on whether a redesign is the right answer, what would be at risk in a migration, and what it would take.

Discuss a project →