# Headless Web

> We rebuild slow, fragmented websites into one fast platform for multi-location groups and professional services firms across the UK and Middle East.

Source: https://www.headless-web.com/. Every URL in this file is canonical English.

## Services

### Multi-location and group platforms
URL: https://www.headless-web.com/en/services/multi-location-and-group-platforms

For groups that have grown by acquisition and inherited a different website with every site. One governed platform, local control where it's needed, head office control everywhere else.

**Who it is for**
Groups that have grown by acquisition and now run a separate website for each site they own — dental, veterinary, physiotherapy, aesthetics, childcare and similar multi-site operators. Written for whoever owns the integration of what the group has bought: marketing, operations or the board, rather than an in-house development team.

**Outcomes**
- One platform for the group and every site it owns
- Head office control of brand, templates and compliance-sensitive claims
- Local teams able to edit hours, staff and services within limits you set
- A newly acquired site added from a template instead of as a fresh website project
- Enquiries and bookings routed to the site that has to answer them
- One contract, one hosting arrangement and one support route instead of one per agency

**Deliverables**
- Audit of every inherited website, CMS, domain, plugin and integration
- Group and site architecture with a reusable site template
- Editorial roles and permissions for head office and local teams
- Content, image and document migration from each legacy platform
- Redirect map and technical SEO plan for every domain
- Practice management, booking and CRM integrations
- Enquiry routing and group-level reporting
- Staged cutover, one site at a time
- Editor training and written handover documentation

### Professional services websites
URL: https://www.headless-web.com/en/services/professional-services-websites

For firms whose new business depends on being found. Fast, maintainable sites your marketing team can update without raising a ticket.

**Who it is for**
Partners, marketing leads and practice managers at law firms, accountancy practices and specialist consultancies, where new business depends on being found and on the credibility of what the visitor then reads. It suits firms on an ageing WordPress build held together by plugins, where every change goes back to an external supplier.

**Outcomes**
- A site structured around the services, sectors and jurisdictions you actually sell
- Pages your marketing team can publish without a developer or a support ticket
- Fewer plugins to patch and a smaller surface for something to break
- Faster loading on the pages prospective clients arrive on
- Clear routes from a service page to the right person and the right enquiry form
- Enquiries recorded against a source and an owner rather than emailed into a shared inbox

**Deliverables**
- Content, URL and plugin audit of the existing site
- Information architecture for services, sectors, offices and people
- Design system and templates for service, insight and profile pages
- Editorial content model your marketing team controls
- Content, insight and document migration from the legacy platform
- Redirect map, metadata, structured data and internal linking
- Enquiry forms with routing, spam control and consent handling
- Accessibility and performance testing before launch
- Editor training and written handover documentation

### Hotel and hospitality websites
URL: https://www.headless-web.com/en/services/hospitality-and-hotel-groups

For operators who want more reservations to come direct. Group and property sites built around the booking path.

**Who it is for**
Hotel groups, boutique collections and hospitality operators running several properties, where each property arrived with its own website and its own supplier. Written for the owner, commercial director or marketing lead answerable for how many reservations come direct rather than through a third party.

**Outcomes**
- One platform for the group site and every property site
- A booking path that sends guests to your own booking engine rather than a third party
- Rooms, rates and offers updated once and shown wherever they appear
- Brand standards held centrally, with local character kept per property
- A new or acquired property launched from the group template
- Language versions built into the content model rather than bolted on afterwards

**Deliverables**
- Audit of every property website, CMS, domain and booking integration
- Group and property architecture on one platform
- Reusable property template with room, offer and package content models
- Booking engine and channel manager integration with live rate and availability display
- Multilingual content structure with per-property overrides
- Enquiry and group-booking forms routed to the right property
- Redirect map and technical SEO plan for every property domain
- Property-by-property migration and cutover
- Editor training for group and property teams

### Platform migrations
URL: https://www.headless-web.com/en/services/platform-migrations

Modernise the presentation layer and core functionalities without ripping out commerce, CRM, or content systems that still work.

**Who it is for**
Operators with entrenched back-ends who need a faster, more controllable front-end and a safe path to cutover.

**Outcomes**
- Modern front-end without disrupting core infrastructure
- SEO-safe migration with URL preservation
- Improved performance and user experience
- Reduced maintenance burden

**Deliverables**
- Decoupled front-end architecture
- SEO migration plan and execution
- Staging-led delivery and QA
- Controlled cutover

**FAQs**

- **What is a website or platform migration?** A platform migration replaces or modernises an existing website, CMS or digital platform. It can include new architecture, content migration, integration work, redirects and a controlled launch.

- **How do you protect SEO during a migration?** We audit existing URLs, content, metadata and internal links before development begins. Redirects, crawlability and technical SEO are tested before launch, then monitored after release. Rankings cannot be guaranteed, but avoidable migration risks can be reduced.

- **Can you migrate WordPress to Next.js?** Yes. WordPress to Next.js is a common migration path, particularly when teams want better front-end performance and flexibility while retaining familiar editorial workflows. We recommend the architecture only when it suits the organisation's requirements.

- **How do you reduce migration risk and downtime?** We define the migration scope, inventory content and integrations, test the new platform in stages and prepare redirects and rollback plans before launch. The release is then managed and checked against agreed acceptance criteria.

## Guides

### WordPress to Next.js migration
URL: https://www.headless-web.com/en/guides/wordpress-to-nextjs-migration

Move off a slow, plugin-heavy WordPress site without losing the content, rankings and integrations you already paid for.

**The site still works. You have stopped trusting it.**
Pages take too long to load. Plugin updates feel like a risk. The agency that built it is gone, or every change now needs a ticket. You are not looking for a redesign. You are looking for a way off the platform without throwing away the years of content and search equity sitting on it.

**What is usually behind it**
- **The theme and the plugins are the product** — Performance, SEO and editorial workflow all depend on a stack nobody fully owns. When one plugin stalls, the whole site slows down or breaks.
- **The CMS and the front end are the same system** — WordPress is serving pages, running forms, handling cache and exposing you to every plugin's security surface. There is no clean place to improve the public site without touching the rest.
- **Content is trapped in the presentation** — Pages, URLs and modules were built as a theme, not as a content model. Moving them later is harder than it needed to be — which is why people stay.
- **Publishing has become a bottleneck** — A page builder made the first few pages quick and every page since slow. Layouts drift, components get duplicated, and marketing ends up raising a ticket for changes the CMS was supposed to handle.
- **Hosting is masking the render cost** — Caching plugins, an object cache and a CDN are layered on to hide how long a page takes to build. Each layer adds a way for stale or broken pages to reach a visitor, and none of them fix the underlying cost.

**What a migration involves**
A migration is a controlled cutover, not a rebuild that starts from a blank page. The current site stays live until the replacement is signed off on staging, and the work is sequenced so that the reversible steps happen first.
- Content model and URL map taken from what you already have, not invented afterwards
- Redirects written and tested before launch
- Integrations that still work — CRM, forms, booking, commerce — kept where they belong
- Tracking and analytics verified on staging so reporting does not reset on day one
- A content model your editors can use directly, without rebuilding layouts page by page
- Performance budgets agreed before build and measured on staging rather than asserted after launch
- The repository, hosting account and documentation handed over, so the platform is yours to move again
- A cutover you can reverse if something is missed

**What it costs to find out**
Most of this work starts with a Headless Assessment. £1,500, fixed. You get the architecture, the risks, and a costed route off WordPress. No obligation to build with us.

**FAQs**

- **Do we have to leave WordPress as a CMS?** Not necessarily. Many migrations keep WordPress as the editor and put Next.js in front of it. The assessment confirms whether that is the right split for your stack, or whether the CMS should move as well.

- **Will we lose our search rankings?** Nobody can promise rankings. What we can do is map every URL, write redirects, carry metadata and structured data across, and test that work on staging before anything public moves.

- **How long does a typical migration take?** The assessment usually takes two to three weeks. A migration commonly runs eight to sixteen weeks depending on content volume, integrations and how many domains are involved. The assessment sets the timeline for your site, not a generic one.

- **What happens to all our plugins?** Each one gets a decision rather than a default. Caching, security and SEO plugins are usually replaced by things the platform does natively. Forms, analytics and CRM connections become integrations. A few turn out to be unused, and a small number are genuinely load-bearing and need rebuilding as code. The assessment lists which is which before you commit.

- **Can our marketing team still edit the site themselves?** Yes. Editing stays in a CMS, and publishing updates the live site without a developer. What changes is that editors work with structured content — a case study, a location, a service — rather than assembling a page out of layout blocks each time.

- **Do we have to redesign at the same time?** No, and it is usually better not to. A migration you can verify is one where the pages look the same and only the platform underneath has changed, because anything that breaks is obvious. Redesigning afterwards is cheaper and lower risk once the content model is in place.

- **What will it cost to run afterwards?** The shape of the bill changes: hosting is usually lower, per-plugin licences mostly disappear, and the CMS may become a subscription. Whether the total is lower depends on your current stack and traffic, so the assessment gives you the figures for your site rather than an average.

### Consolidating websites after an acquisition
URL: https://www.headless-web.com/en/guides/consolidating-websites-after-an-acquisition

You bought the practices. You inherited the websites. One platform for the group, local control where it is needed, without losing the search presence of the sites you acquired.

**Every acquisition arrived with another website.**
The group now runs eight sites on eight platforms, built by eight local agencies. Head office cannot change a template once and see it everywhere. Local managers cannot update hours without raising a ticket. Nobody has a complete list of logins. Consolidating this is not a nice-to-have rebuild — it is an integration task with budget already allocated.

**What is usually behind it**
- **No shared architecture** — Each site was commissioned as a one-off. None of them were built to be part of a group, so brand, permissions and enquiry routing were never designed to scale.
- **Access sits with former suppliers** — Domains, CMS accounts and analytics still belong to previous owners or agencies. A simple change turns into an email hunt.
- **Local SEO was never treated as an asset** — Each site has its own URLs, Google Business presence and enquiry forms. Folding them badly is how groups lose the visibility they paid for when they bought the practice.
- **Enquiries route wherever the original builder pointed them** — Forms land in personal inboxes, a former owner's address or a CRM nobody at group level can see. Demand by location becomes impossible to measure, which makes it impossible to manage.
- **Inherited pages carry claims nobody has reviewed** — Pricing, credentials, policies and regulated wording were written by the previous owner. Once the group owns the site, it owns the claim on it — and in most cases nobody has audited what is actually published.

**What a consolidation involves**
One platform, many locations. Head office sets brand, templates and permissions. Each site keeps local pages, local search presence and its own enquiry routing. Sites move one at a time, so a problem on one never becomes a problem for the group.
- Inventory of every inherited domain, CMS, plugin and integration
- A site template with roles for head office and local editors
- Content and URL migration per site, with redirects tested before that site goes live
- Booking, CRM and practice systems left in place where they still work
- One source of location data — addresses, opening hours, contact details — so a change is made once
- Enquiry routing and reporting at group level, split by location
- A migration order agreed in advance, so the largest or most exposed site is not the first to move
- The next site starts only once the last one is stable

**What it costs to find out**
The Headless Assessment maps every inherited site and sets the order they should move in. £1,500, fixed. You keep the document even if you do not proceed to a build.

**FAQs**

- **Can each site keep its own name?** Yes. Some groups keep the local name because it carries the reputation; others move to the group brand over time. The platform supports either, including a phased rename site by site.

- **We are still acquiring. Will this cope with sites we have not bought yet?** That is the reason to build from a template. Once it exists, adding an acquisition becomes a migration and content exercise rather than a new website project.

- **Do local managers still edit their own pages?** Yes, within limits you set. Hours, team and local copy can sit with the site. Templates, brand assets and anything carrying a clinical, legal or pricing claim can stay under head office approval.

- **What happens to each location's Google Business Profile?** They stay per location — they are one of the assets you bought. The work is keeping the name, address and phone number consistent between the profile and the new site, and updating the linked URL as each site moves so the profile never points at a redirect for longer than it has to.

- **Do all the sites have to move at once?** No, and we would advise against it. Sites move one at a time so each cutover can be checked properly, and so the template improves with each one. A group of eight typically moves over several months rather than in a single launch.

- **Who ends up owning the domains?** The group should. Inherited domains are often still registered to a previous owner or their agency, which is a real risk at renewal. Consolidating registrar access is usually one of the first things worth doing, and it can happen before any migration work starts.

- **One of our sites is tiny. Is it worth moving?** Sometimes the answer is to fold it into a location page on the group site and redirect the old URLs, rather than rebuild it. That keeps whatever search presence it had without carrying a whole site for one location. The assessment says which sites are worth moving and which are worth absorbing.

### Slow WordPress site — what is actually causing it
URL: https://www.headless-web.com/en/guides/slow-wordpress-site

A slow WordPress site is rarely one plugin. It is usually the theme, the page builder, uncached database work and a front end that cannot get out of its own way.

**The homepage is slow. The rest is worse.**
You have tried a cache plugin. You have tried a CDN. Pages still take seconds to become usable, especially on mobile. Paid traffic lands on a page that is still loading. Editors wait on the admin. The site feels older than it is.

**What is usually behind it**
- **The page is assembled on every request** — Page builders, heavy themes and unbounded queries mean WordPress is doing too much work before a visitor sees anything. Caching hides it until someone logs in or a form is submitted.
- **Images, scripts and third parties pile up** — Each plugin adds CSS, JavaScript and tracking. None of them were chosen as a set. The result is a page that is heavy before your content even starts.
- **The host is not the real problem** — Moving to a more expensive host can shave time off a badly built page. It does not fix a front end that has to bootstrap a page builder to render a heading.

**What a fix involves**
Sometimes the right work is a diagnosis and a short list of fixes on the current stack. Sometimes the platform itself is the constraint, and a migration is cheaper than another year of plugin theatre.
- Measure the live pages that matter — not a lab score on a blank template
- Separate what is theme, what is plugin, and what is hosting
- Fix what is cheap and durable: images, unused scripts, cache, database work
- Be honest when the remaining gap only closes by changing the front end

**What it costs to find out**
The Headless Assessment includes a performance diagnosis of the current platform and a costed route — stay, fix, or migrate. £1,500, no obligation to build with us.

**FAQs**

- **Can you just make this WordPress site faster?** Often, yes, for a first stretch. If the remaining problem is the architecture, we will say so rather than sell another round of plugin work that will not hold.

- **Is this a Core Web Vitals problem?** Core Web Vitals are how Google describes the same issue visitors already feel. The assessment looks at LCP, interactivity and layout shift on the pages that actually receive traffic — not a generic scan.

- **Will a new theme fix it?** A cleaner theme can help. If content, plugins and integrations still have to travel through WordPress on every request, you will meet the same ceiling again.

### Migrating a website without losing SEO rankings
URL: https://www.headless-web.com/en/guides/migrating-without-losing-seo

Search equity is revenue infrastructure. A migration that treats URLs, redirects and metadata as an afterthought is how firms lose the traffic they already earned.

**The rebuild is approved. The rankings are not optional.**
New business depends on being found. The current site is slow or unmaintainable, but it has years of indexed pages, inbound links and published insight. You will not sign off a migration that treats that as collateral.

**What usually goes wrong**
- **URLs change and nobody mapped them** — A new information architecture is designed as if the old URLs did not exist. Redirects are written after launch, once traffic has already dropped.
- **Metadata and structured data are left behind** — Titles, descriptions, canonicals and schema lived in the old theme. The new site ships without them, or with placeholders.
- **Tracking resets on the day you go live** — Analytics, ads conversion and call tracking were never verified on staging. The first week of the new site is a reporting blackout.

**What a careful migration involves**
SEO work happens before cutover, on staging, against a written URL map. Rankings cannot be guaranteed. The avoidable causes of loss can be controlled.
- Full URL inventory from the live site, including parameters you actually use
- Redirect map written and tested before launch, not patched afterwards
- Metadata, canonicals, hreflang and structured data carried across and checked
- Internal links rebuilt to the new structure
- Analytics and conversion events verified on staging

**What it costs to find out**
The Headless Assessment produces the URL map, the SEO risks and the cutover plan. £1,500, fixed. That document is what a responsible rebuild starts from.

**FAQs**

- **Can you guarantee we will keep our rankings?** No. Anyone who does is selling something they cannot control. We control redirects, metadata, internal links, structured data and tracking — the parts of a migration that most often cause avoidable loss.

- **What about Google Business Profiles and local pages?** Local URLs and location pages are treated as first-class. They are mapped, redirected and checked like the rest of the site, not folded into a generic service page.

- **When do redirects go live?** At cutover, as part of a sequenced release, after they have been tested on staging. Not as a spreadsheet emailed to whoever has DNS access on the day.

### Website rebuild after a rebrand
URL: https://www.headless-web.com/en/guides/website-rebuild-after-rebrand

A rebrand is the moment the current site becomes indefensible. The mistake is treating the new site as a design job and leaving the platform, URLs and integrations as an afterthought.

**The brand has moved. The website has not.**
New name, new positioning, new materials — and a site that still looks and behaves like the previous firm. Leadership wants the public site to match. Marketing wants to publish without a developer. Nobody wants to throw away the URLs that already rank.

**What is usually behind it**
- **The old site was a brochure for a different company** — Information architecture, services and tone were built around a previous offer. A skin change will not fix a structure that no longer matches how you sell.
- **The CMS cannot support the new system** — New templates, components and brand rules need a content model. A page builder held together by plugins will not hold them.
- **The rebrand budget did not include the platform** — Design and naming were scoped. Migration, redirects and integrations were assumed. That is how rebrands launch late, or launch on a site nobody can maintain.

**What a rebuild involves**
Keep the content, rankings and systems that still work. Replace the front end and the content model so the new brand can actually be run by your team.
- IA and content model mapped to the new offer, not the old sitemap copied forward
- Design system as templates your editors can use, not a set of mockups
- URL strategy for renamed services and retired pages, with redirects tested before launch
- Integrations and tracking carried through so the new site is measurable on day one

**What it costs to find out**
The Headless Assessment separates brand work from platform work and prices the rebuild against the current stack. £1,500, no obligation to build with us.

**FAQs**

- **Can we keep the current CMS?** Sometimes. If the editors already work in WordPress and it is not the thing that is failing, we can put a new front end in front of it. If the CMS cannot support the new templates, the assessment will say so.

- **What happens to old service names in the URLs?** They are mapped. If a service was renamed, the old URL redirects to the new one. If it was retired, it redirects to the closest living page — not to the homepage by default.

- **Does the assessment include design?** It includes whether the current platform can carry the new brand, and what a rebuild would involve. Visual design for the new site sits in the build that follows, scoped from that document.

### Core Web Vitals dropped — diagnosis and fixes
URL: https://www.headless-web.com/en/guides/core-web-vitals-dropped

A Core Web Vitals drop is a symptom. The cause is usually a release, a plugin, a tag or a template that made the important pages slower for real visitors.

**Search Console went red. Traffic did not wait.**
Largest Contentful Paint slipped. Interaction to Next Paint followed. The pages that receive paid and organic traffic are the ones that got worse. A generic “speed plugin” will not tell you which release caused it, or whether the platform can recover.

**What is usually behind it**
- **A release made the hero more expensive** — A new banner, slider, font or tag manager container is now the LCP element. Lab tests on an empty page will not show it. Field data on the landing pages will.
- **Third-party scripts woke up** — Chat widgets, A/B tools, ads pixels and consent managers compete with your content. One extra tag is enough to push interactivity past the threshold.
- **The template cannot meet the threshold** — If the page builder has to boot before the heading paints, you will keep missing LCP on mobile no matter how much you compress images.

**What a diagnosis involves**
Measure the pages that matter, in the field, then separate what you can fix on this stack from what the stack cannot do.
- Identify the actual LCP element and the scripts that delay it on the pages that receive traffic
- Remove or defer what does not need to run before the page is usable
- Fix images, fonts and server timing where they are the constraint
- Say clearly when the remaining gap only closes with a new front end

**What it costs to find out**
The Headless Assessment includes a performance diagnosis and a costed route forward. £1,500, fixed. If the right work is a short fix list, that is what you get. If the platform is the limit, you will see that in writing.

**FAQs**

- **Will fixing Core Web Vitals recover our rankings?** It can remove a drag. It is not a ranking package. We treat the vitals as a user-experience and paid-traffic problem first, and we do not promise search movement.

- **Can you do this without a full migration?** Yes, when the architecture still has headroom. The assessment exists to answer that before anyone commits to a rebuild.

- **How quickly can this be diagnosed?** A focused diagnosis of the live pages is part of the two-to-three-week assessment. Emergency patches on a single landing page can sit outside that if the traffic loss is acute — we will say so on the first call.

### Replacing an agency mid-project
URL: https://www.headless-web.com/en/guides/replacing-an-agency-mid-project

The current supplier has stalled, gone quiet, or cannot finish. You still need the site. The next step is an honest picture of what you actually have — code, access, content and contracts — before anyone starts again.

**The project is not going to land like this.**
Deadlines have slipped. Staging is incomplete. Nobody can explain what is left. You may not even have the repository, the hosting account or the CMS in your own name. Replacing the agency without a diagnosis is how you pay twice for the same work.

**What is usually behind it**
- **Access was never yours** — The agency holds Git, hosting, CMS and DNS. Without a written handover you cannot continue the work, let alone finish it.
- **Scope was never written down** — What “done” means lived in Slack. There is no inventory of pages, integrations or redirects, so a new team cannot price the remainder.
- **The build cannot be maintained** — The stack is proprietary, undocumented, or depends on people who are no longer on the account. Finishing it as-is would leave you locked in again.

**What a takeover involves**
First, recover what is yours. Then decide what is worth keeping. Then price the remainder as a migration or a finish-out, not as a vague rescue.
- Inventory of repositories, hosting, CMS, domains and third-party accounts
- A written picture of what is built, what is missing, and what is unsafe to keep
- A decision: finish on the current stack, or migrate what is worth saving
- A costed route that does not depend on the outgoing supplier staying involved

**What it costs to find out**
The Headless Assessment is the takeover document: architecture, risks, access gaps and a costed route to finish. £1,500, fixed. No obligation to build with us — and no need to keep the previous agency in the loop once access is recovered.

**FAQs**

- **Do we need the previous agency’s permission?** You need the assets you paid for: code, content, credentials and domains. Contracts vary. The assessment lists what is missing so you can request it in writing rather than negotiating in the dark.

- **Can you finish their build as-is?** Sometimes, if the stack is standard and the work is actually close. If it is proprietary or undocumented, finishing it would recreate the lock-in. We will say which case you are in.

- **How fast can this start?** As soon as you can grant read access to what you have — even if that is only the live site and a staging URL. The assessment does not wait for a perfect handover that may never arrive.

## Engagements

### Find out what you're actually dealing with
URL: https://www.headless-web.com/en/engagements/assessment

A fixed-price technical assessment of your current platform — architecture, performance, risks and a costed route forward. You get a written report and a stakeholder presentation you can act on with or without us.

**Pricing** £1,500 — Fixed price. No obligation to build with us. — One-off · standalone deliverable

**Who it is for**
- **Groups that have grown by acquisition** — You have inherited a different website with every practice, clinic or site you bought, and nobody can tell you what it would take to bring them onto one platform.
- **Firms whose new business depends on being found** — Your site is slow, plugin-heavy or hard to edit, and you need to know what a rebuild would risk before you sign anything off.
- **Teams part-way through a decision** — You have quotes, opinions or a half-finished project, and you want an independent read on the platform before committing further budget.

**Deliverables**
- **Architecture review** — How the current platform is put together, what it depends on, where the fragile joins are, and which parts are worth keeping.
- **Performance and Core Web Vitals** — Measured field and lab data for your key templates, and what is actually causing the numbers you are seeing.
- **Search and content risk** — URL structure, indexation, internal linking and tracking — what a migration would put at risk and how each risk is handled.
- **Integration inventory** — Every commerce, CRM, booking and marketing system the site touches, and whether it moves, stays or gets replaced.
- **Costed route forward** — A recommended approach with scope, sequencing and a price. If a rebuild is not the right answer, the report says so.
- **Written report and presentation** — A document your stakeholders can read without us in the room, plus a session to walk through it and answer questions.

**Timeline**
- **Kickoff** — Week 1
- **Analysis** — Weeks 1–2
- **Report and presentation** — Weeks 2–3

**FAQs**

- **Do I have to build with you afterwards?** No. The assessment is a standalone deliverable. The report is written so that another supplier could act on it, and plenty of clients use it exactly that way.

- **We have several websites. Does one assessment cover them all?** For groups, the assessment looks at the estate rather than a single site — what each platform is, what it would take to consolidate them, and which sites should move first. Tell us how many sites are involved at the kickoff call so we scope it properly.

- **Will a migration cost us our search rankings?** That is one of the main things the assessment exists to answer. We map URL structure, indexation and internal linking before anything is committed to, so redirects are planned and tested rather than patched after launch.

- **Do we have to leave WordPress?** Not necessarily. WordPress can stay as the editing environment behind a modern front-end. The assessment covers whether that is the right call for you or whether a different CMS serves you better.

- **What if we cannot give you access to the code?** We work with whatever access you can give us and say plainly in the report where a lack of access limited what we could conclude.

- **Why is there a fee at all?** A free audit is a sales document. A paid assessment lets us spend the time to reach conclusions we are willing to put our name to, including the conclusion that you should not rebuild.

## Case studies

### Lead generation landing page for UAE property manager
URL: https://www.headless-web.com/en/work/lead-generation-website

A conversion-focused Italian-language lead generation page that turns investor interest in Dubai property into qualified sales enquiries.

### Multilingual investor platform for an international mining and commodities trading company
URL: https://www.headless-web.com/en/work/multilingual-investor-platform

A headless investor website built from the ground up for an international mining and commodities trading company, with five-language content and live market data.

### Arona St James Solicitors: content-led headless website for a regulated UK law firm
URL: https://www.headless-web.com/en/work/arona-st-james-solicitors

A modern, content-led website for a regulated UK law firm, built on Next.js and Sanity.

### Eldwick Law: Headless WordPress Migration for a Specialist Law Firm
URL: https://www.headless-web.com/en/work/eldwick-law

A high-performance headless website for a specialist law firm, built on Next.js and WordPress.

### One platform, many operators: multi-tenant booking infrastructure
URL: https://www.headless-web.com/en/work/yoga-studio-saas

A single platform serving independent studios, each managing their own location, schedule and customers under shared infrastructure and shared standards.
