Website Redesign Ireland: Costs, Process And Protecting Your SEO

A website redesign should improve the business without discarding the value the current site has already earned. For an Irish SME, that normally means treating the project as a content, conversion and technical migration—not a visual reskin.

A light refresh may cost about €2,000–€5,000 before VAT. A substantial SME redesign involving architecture, copy, custom templates, migration, redirects and measurement may need roughly €5,000–€12,000. Complex replatforming, ecommerce or integration-heavy work can cost €12,000–€30,000 or more. The price depends on what must be preserved, changed and proven.

No process can guarantee unchanged rankings. Google’s site-move guidance says significant changes can produce temporary ranking fluctuation while pages are recrawled and reindexed. A disciplined process reduces preventable losses and makes genuine problems visible quickly.

Decide whether you need a redesign

An old-looking website is not automatically a bad website. A fashionable new design is not automatically a useful investment.

Start with the problem:

• The offer or audience has changed and the current structure cannot explain it.
• Important services are hidden, combined incorrectly or competing with one another.
• Customers cannot complete key tasks on mobile or with assistive technology.
• The team cannot update content safely or consistently.
• The platform is unsupported, insecure or expensive to maintain.
• Forms, booking, analytics or integrations are unreliable.
• Search visibility and useful content exist, but the site converts poorly.
• The business needs capabilities the current architecture cannot support.

If the real issue is weak copy on three pages, slow image files or an unmonitored enquiry mailbox, fix those first. Replatforming the entire site introduces risk without necessarily solving the problem.

Use a simple redesign score

Score each area from 0 to 2. This is a discussion tool, not a technical standard.

A total of 0–3 usually favours targeted improvement. At 4–7, compare an improvement plan with a redesign scope. At 8–12, a controlled rebuild becomes more plausible. Override the score when one issue is critical—for example, a compromised platform or inaccessible core service.

Set the redesign budget and scope

Redesign cost is not just the price of new layouts. It includes understanding and safely moving what already exists.

These are buyer-side planning estimates, not a Hatch tariff or official Irish average. Read the broader website cost guide for Ireland for assumptions, VAT and five-year ownership.

Work unique to a redesign

Compared with a new site for a new business, budget explicitly for:

• crawling and inventorying current URLs, media and downloads;
• exporting search, analytics, lead and backlink baselines;
• deciding what to retain, improve, consolidate or remove;
• migrating content and structured data;
• mapping and implementing redirects;
• maintaining analytics, consent, CRM and advertising continuity;
• comparing old and new templates for performance/accessibility;
• crawling and monitoring after launch; and
• repairing unexpected legacy URLs or third-party links.

If a proposal mentions none of these, it is a design quote with migration risk left outside the scope.

Define success before design begins

Use business outcomes and guardrails together.

Improvement outcomes might include more qualified enquiries, a higher booking completion rate, fewer support calls, better editing speed or clearer visibility for a priority service.

Protection guardrails might include preserving valuable page topics, maintaining form delivery, retaining approved content, keeping redirect errors below an agreed threshold and avoiding material performance/accessibility regression.

Do not make “same rankings on launch day” an acceptance criterion. Search results fluctuate and Google must process changed pages. Use trends and equivalent periods, while fixing concrete technical errors immediately.

Record the baseline before you change the site

Without a baseline, every post-launch discussion becomes opinion. Export data while the current site still works.

Commercial baseline

Record at least three to twelve months, and longer where seasonality matters:

• qualified enquiries by service and source;
• calls, forms, bookings or sales from important landing pages;
• lead-to-appointment and lead-to-sale rates where available;
• average response time and common unsuitable enquiries;
• paid campaign destinations and conversion actions; and
• phone numbers, email routes and offline attribution currently in use.

Search baseline

Export from Search Console:

• clicks, impressions, click-through rate and average position;
• priority queries grouped by topic, not only a short rank list;
• landing pages receiving organic clicks;
• brand and non-brand trends where the report supports them;
• countries and devices where relevant;
• indexing/canonical status and submitted sitemaps; and
• external links to pages likely to change.

Google’s Search Console guidance recommends focusing on trends in clicks and impressions rather than position alone and cautions that demand, seasonality and competitors can influence performance after a change. When comparing periods, weekly or monthly aggregation can reduce day-of-week noise.

Technical and experience baseline

• crawl every discoverable internal URL and record status, title, description, canonical, headings and internal links;
• collect existing XML sitemaps and robots rules;
• list redirects already in place;
• identify indexed pages absent from the current navigation;
• record 404s and server errors from logs or available tools;
• test current forms, consent and analytics;
• capture Core Web Vitals field data where available; and
• document accessibility issues using automated and human checks.

Save exports outside the live CMS. A platform migration can remove the very data needed to diagnose it.

Inventory content before drawing the new sitemap

Every existing page needs a decision. Use four options: retain, improve, consolidate or remove.

Evaluate traffic and links, but do not keep a harmful or inaccurate page only because it once received visits. Preserve the useful intent and evidence in a better destination when possible.

Include more than HTML pages

Inventory PDFs, downloadable guides, images with external links, campaign pages, subdomains and system-generated URLs. Google’s site-move documentation specifically advises including embedded content such as images and video in move planning.

Keep URLs stable when they remain useful

Changing /services/accounting/ to /what-we-do/financial-solutions/ has a cost. If the old path is clear, accurate and established, visual redesign alone is not a reason to replace it.

Change a URL when the architecture, terminology, consolidation or domain genuinely improves. Then map it deliberately.

Design the new architecture around customer decisions

The redesign is an opportunity to remove historical clutter, but simplification should not erase useful depth.

Start with the commercial structure from the Irish small-business website playbook: priority audience, services, proof, locations, actions and measurement. Compare the proposed sitemap with the current URL inventory before approving it.

For every new page, record:

• page purpose and primary audience;
• source pages/content being migrated;
• questions the page must answer;
• evidence and media required;
• target action;
• internal links in and out;
• proposed URL and canonical; and
• content owner and approval status.

This page matrix prevents design from advancing with placeholder copy while migration decisions remain unresolved.

Preserve what already works

Do not rewrite successful pages merely to make every sentence sound new. Identify the sections, language, links and proof that contribute to the page’s usefulness. Improve accuracy and conversion without changing the core intent accidentally.

Search visibility is not a reason to freeze poor content forever. It is a reason to edit with evidence and compare the result.

Build and test in a protected environment

A staging site needs to be inaccessible to search engines and ordinary visitors while remaining testable by the project team. Common protection methods include authentication and controlled network access. If noindex or robots restrictions are used during development, record every one and remove the public-site blocks at launch.

Google lists forgotten noindex and robots restrictions among common site-move failures.

Test with production-like content

Templates behave differently with long service names, missing images, many categories, embedded tools and real legal text. Populate realistic content early and test:

• long and short titles;
• image aspect ratios and missing media;
• forms in success, validation and delivery-failure states;
• menus with real labels;
• tables and downloads on small screens;
• cookie choices and tag behaviour;
• 404 and search-empty states; and
• editor permissions and common publishing tasks.

Separate launch blockers from improvements

Launch blockers include broken purchases/forms, public noindex, incorrect canonicals, missing redirects, inaccessible navigation, exposed data, serious security issues and missing required content.

Minor animation, spacing preferences and future content ideas belong in a prioritised backlog. Mixing both lists creates rushed decisions at the most sensitive point.

Create a redirect map that can be reviewed

A redirect map is not “send the old site to the new homepage”. It is a decision record connecting each changed old URL to the closest useful destination.

This is illustrative, not Hatch client evidence.

Use the right redirect

Google’s redirect documentation recommends permanent server-side redirects when a page has moved permanently. HTTP 301 and 308 are standard choices. Temporary redirects are for temporary situations.

Avoid chains such as old A → temporary B → current C. Redirect A directly to C. Google’s migration guidance says it can follow multiple hops but advises keeping chains low; direct is better for users, crawlers and maintenance.

Do not redirect every removed URL to the homepage. Google warns irrelevant redirects may be treated as soft 404s. If there is no useful equivalent, a proper 404 or 410 is honest.

Keep redirects long enough

Google recommends retaining site-move redirects generally for at least one year, allowing signals and links to be processed. For users with bookmarks and third-party links, valuable redirects can remain indefinitely.

Update your own internal links immediately so visitors are not sent through redirects. Update high-value profile, campaign and external links where you control them.

Align canonicals, internal links and sitemaps

Redirects are only one signal. The new site should consistently identify the new preferred URLs.

Canonical tags

Each indexable new page should normally reference its preferred production URL. Google’s canonical guidance explains that canonicalisation helps consolidate signals across duplicate or very similar URLs.

After launch, check that:

• canonicals use the production domain and protocol;
• they do not point back to staging, old domains or redirected URLs;
• parameter and duplicate variants are handled deliberately; and
• redirects, internal links, canonicals and sitemap entries agree.

Internal links

Replace links to old URLs in navigation, page copy, templates, images, hreflang annotations where relevant and structured data. Redirects are a safety net, not a substitute for updating the site itself.

Keep contextual links that made important pages discoverable. A redesign that removes useful internal links while preserving the URL can still weaken the page’s role in the site.

XML sitemap

Google’s sitemap documentation says to include fully qualified preferred canonical URLs. Generate and test the new sitemap, remove non-indexable/redirecting/error URLs, then submit it in Search Console.

A sitemap helps discovery. It does not guarantee indexing.

Preserve measurement and consent continuity

Do not create a new analytics property simply because the website looks new unless there is a deliberate data-governance reason. Continuity makes comparison easier.

Before launch, document:

• analytics account, property, stream and tag ownership;
• consent categories and which tags depend on them;
• event names, parameters and key events;
• CRM, call tracking and booking integrations;
• internal traffic and cross-domain settings;
• campaign tags and paid conversion destinations; and
• dashboards or reports that depend on old URLs.

Test actual events, not only whether a tag appears. Submit forms, make test bookings or purchases, reject consent, accept selected categories and confirm that data behaves as designed.

Ireland’s Data Protection Commission says non-exempt technologies such as targeted advertising and conversion tracking generally need consent and that withdrawal must be as easy as giving it. A redesign is not permission to reactivate tags before a choice.

Use a controlled launch checklist

• A final crawl of staging has no unintended broken internal links or redirect targets.
• Production robots rules and meta directives allow intended public pages to be indexed.
• Canonical tags use final production URLs.
• Every mapped redirect is implemented directly and tested for status and destination.
• The XML sitemap contains only preferred indexable production URLs.
• Priority pages retain approved content, metadata, headings and internal links.
• Forms, bookings, payments, email delivery and CRM routing pass real tests.
• Consent choices correctly control analytics and marketing technology.
• Search Console ownership and analytics access remain available.
• Performance and accessibility checks pass the agreed release threshold.
• DNS, SSL, backups, rollback responsibilities and support contacts are confirmed.
• Paid ads, profiles, email templates and high-value external destinations are updated.

Choose the launch window

Google recommends timing a move for a lower-traffic period where practical. Choose a time when developers, the business owner and whoever receives enquiries can test and respond. Avoid a Friday evening launch if nobody can fix a form until Monday.

For a domain move, follow the current Change of Address instructions in Search Console. For an ordinary redesign on the same domain, that tool is not required.

Monitor the redesign after launch

The launch is a controlled observation period, not the finish line.

What fluctuation is normal?

Google says a small or medium-sized site move can take a few weeks for most pages to move in its index, with larger sites taking longer. There is no fixed crawl frequency.

Some movement is expected. It is not a reason to ignore specific failures. Investigate immediately when you see:

• priority URLs returning errors or redirecting incorrectly;
• public pages retaining noindex or staging canonicals;
• a sitemap dominated by redirects or errors;
• forms or ecommerce events disappearing;
• whole page groups losing internal links;
• server capacity or 5xx problems; or
• content materially weaker or mismatched to the old page’s purpose.

Compare the right data

Compare like with like: equivalent weekdays or weeks, the same season where possible, brand and non-brand topics, and page groups with similar intent. Record promotions, outages, ad changes and demand shifts.

Position is a diagnostic measure. Clicks, impressions, qualified enquiries and revenue contribution tell a more complete story.

Common redesign failures and how to prevent them

Rewriting everything without an inventory

The team loses useful answers, proof and search relevance because “fresh copy” became the only requirement. Prevent it with retain/improve/consolidate/remove decisions and page-level content briefs.

Changing every URL for neatness

Shorter URLs can be useful, but stability has value. Keep accurate URLs and change only where the future architecture justifies it.

Mapping everything to the homepage

Customers following an old service link land somewhere irrelevant. Search engines may treat the redirect as a soft 404. Map to the closest equivalent or return a proper not-found response.

Launching with staging restrictions

A forgotten site-wide noindex, password, robots rule or staging canonical can suppress discovery. Maintain a release-specific list of protections and assign one person to verify removal.

Measuring traffic but not leads

A redesign can keep traffic stable while damaging form delivery, phone prominence or lead quality. Test and monitor the complete commercial path.

Combining too many changes

Google advises changing one major thing at a time where practical. A new domain, CMS, architecture, brand, copy and analytics model launched simultaneously can be necessary, but it makes diagnosis harder. Separate changes when the business can.

Removing redirects too early

Keep them at least one year per Google’s general site-move recommendation, and longer where old links continue to serve users.

A practical redesign process

1. Diagnose. Define the business problem, decide whether targeted improvement can solve it and set success measures.
2. Baseline. Export commercial, search, technical, performance and accessibility evidence.
3. Inventory. Find every useful page and asset; choose retain, improve, consolidate or remove.
4. Architect. Design the new sitemap and page matrix around customer decisions while preserving valuable topics.
5. Create. Write real content, design reusable responsive components and build against production-like states.
6. Map. Approve old-to-new URLs, permanent redirects, canonicals, internal links and sitemap entries.
7. Verify. Crawl staging; test forms, consent, analytics, accessibility, performance and migration details.
8. Launch. Release during a supported window, implement redirects and confirm indexability and commercial journeys.
9. Stabilise. Monitor errors, indexing, search trends and qualified leads from hours through months.
10. Improve. Use evidence to prioritise content and conversion work after the migration settles.

The planned focused article on redesigning a website without losing Google rankings will provide a shorter technical checklist. This guide remains the wider cost, process and decision resource.

Your next step

Before requesting redesign proposals, create three documents:

1. a one-page commercial brief with the problem and outcome;
2. a current URL/content inventory with performance evidence; and
3. a list of systems, owners and launch constraints.

The planned Website Redesign Brief Builder will structure those inputs. Until it is live, use the checklist and redirect-map fields in this guide.

Review Hatch’s web design and development service or the planned Website Redesign Ireland service when you are ready to compare the work, not just the visuals. You can also book an SEO-safe redesign review to identify what should be preserved before a quote is finalised.

Editorial review policy: Google’s migration, redirect, canonical, sitemap and Search Console guidance should be rechecked before publication and at least every six to twelve months. Last researched 12 August 2026.