Separate Mobile Site, Responsive or Adaptive Design: What Fits?

Responsive design adapts a shared website layout to the available space. Adaptive behaviour changes the composition or interaction at meaningful sizes or conditions. A separate mobile site serves another website version, often on another URL. For most teams, one responsive site is the maintainable starting point; choose more specialised behaviour when the actual task or a real legacy constraint requires it.

If your mobile visitors cannot compare the offer or finish the form, a responsive label will not save the sale. You keep buying traffic while support explains a journey that should explain itself. ANODA designs the task across narrow and wide screens, preserves the information behind the decision and connects the new interface to a migration plan. That gives you a website that serves customers and one content model your team can maintain.

Mobile-first is a design approach, not a fourth architecture. It means deciding the narrow-screen priorities first, then adding space and detail where larger windows allow it. A responsive website can be designed mobile-first or desktop-first. A separate mobile site can itself use responsive layouts.

Choose by the content and task people need, the system you can maintain and the migration you must perform. “It looks good on a phone” is a necessary observation, but it does not settle content parity, form completion, indexing, analytics or operational ownership.

Compare the three choices on the same requirements

These choices can coexist. A shared responsive site may replace a wide data table with labelled expandable rows at a narrow width. That is adaptive composition inside one website, not a reason to create an m. domain.

Start with content and feature parity

List the main tasks and the information needed to finish them. A visitor on a phone may still need pricing conditions, product limits, a document or the status of an application. Removing that information to make the screen cleaner can block the decision rather than improve it.

Parity does not mean identical presentation. Keep the meaning and access to the necessary content, then choose a layout suited to the space. If a function is genuinely unsuitable on the device, explain why and offer a practical continuation path rather than silently omitting it.

Include editorial ownership in the decision. Who updates a price, case, help page or disclosure? If two teams must copy every update into two sites, the maintenance risk is part of the architecture, not an afterthought.

A real example: product comparison in Sail

In Sail’s mortgage CRM redesign, desktop product results use a wide table with loan stages beside it. On the phone, each product becomes a full-width row that opens to its reasons. Eligibility and the reasons a product is ruled out remain part of the task.

The decision is to change the composition while preserving what the loan officer must understand. The phone is a responsive/adaptive version of the web product, not a new native app. ANODA’s work was the structure and interface redesign; Ark Mortgage’s team owned the implementation.

A similar decision can help a website feature comparison. Stack plans into labelled groups while keeping comparable terms accessible. Do not copy the pattern if the visitor needs simultaneous comparison that expandable rows would make difficult.

Navigation, forms and tables need their own design

A smaller menu should preserve the names people know, the current location and a route back. Test opening, closing, focus and returning to the page. Hiding a desktop menu behind an icon does not automatically make it understandable.

Forms need visible labels, appropriate input behaviour, clear errors and retained values after a failed submission. Check what happens when the keyboard occupies part of the screen. A sticky CTA that covers the current field can make a nominally responsive form unusable.

For wide tables, choose between wrapping, labelled cards, column prioritisation, an expandable detail or purposeful scrolling according to the task. Preserve headers and relationships. Hiding columns is a product decision when those columns affect the user’s judgement.

UI/UX design establishes these interaction decisions. Frontend development implements and verifies them in the actual component and layout system.

Performance depends on what you load

Design performance around what the customer needs first, then inspect what the page actually loads. Both separate and responsive sites need this work.

Inspect the assets and scripts delivered to a representative mobile device. A small displayed image may still download the original huge asset. A hidden desktop animation may still run. A layout can adapt perfectly while waiting for unnecessary JavaScript.

Set budgets around meaningful experience: when the main content becomes usable, whether interaction responds and whether content shifts while someone is acting. Use appropriately sized media, reserve its space and defer work that is not needed for the first task. Repeat comparable checks after a repair rather than assuming the CSS breakpoint solved the delay.

Accessibility, zoom and input methods cross every layout

Check enlarged text, reflow, reading order and keyboard operation. Controls must remain named, visible and operable when the layout changes. Important instructions should not disappear because a design assumes a smaller window means a different user.

A narrow browser window can belong to a desktop user. A touch device may have a large display. Make layout decisions from available space and task constraints, and verify input behaviour separately. The accessibility workflow guide explains how to carry those requirements from design to implementation and testing.

Keep analytics and task continuity understandable

Define the task event once across layouts. If “enquiry received” has one meaning on desktop and another on mobile, the report cannot explain the difference in completion.

Check whether a person can continue where the task requires it: return to a saved form, reopen a shared link or access the same record. A layout change should not reset useful state. If a separate site uses a different authentication or storage setup, include that behaviour in the architecture review.

Test measurement at the receiving provider when access is authorised. A script being present is separate from an event arriving, and a frontend success state is separate from a form destination receiving the message.

Preserve your search destinations when layouts change

A shared route model avoids maintaining a second set of corresponding page URLs. It still needs correct titles, canonical references, content, links, status codes and crawl access.

For a separate mobile site, inventory each mobile/desktop page pair and how redirects and canonical signals work. Never redirect every old mobile URL to the new home page merely because that is easy. A visitor following a product or article link needs the corresponding content.

Treat the change as a migration with a URL map and verification. Website migration covers this coordination when platform, content and routes change together. Keep the valuable content and its destination intact while the layout improves.

When a separate mobile site may be justified

A distinct site can be reasonable when a legacy stack cannot support the required task within the accepted constraints, or when mobile serves a genuinely different product with separate content and ownership. Name that constraint precisely.

Compare the cost of maintaining the split with the cost and risk of consolidating. Include content updates, templates, form integrations, authentication, analytics, route behaviour and support. Estimate from the current system and the migration scope.

If the split exists only because an old desktop site was never made usable on a phone, consolidation may remove duplicated maintenance. First establish the full inventory and the journeys that cannot break.

Migrate without losing pages or tasks

1. Inventory existing URLs, content, forms, integrations and representative traffic destinations.
2. Match each old page to its intended new destination; resolve duplicates and missing content explicitly.
3. Design the shared task and the narrow/wide variations with actual content.
4. Implement redirects and canonical behaviour against the approved route map.
5. Test links, direct entry, saved state, forms, accessibility and measurement across the relevant windows and inputs.
6. Verify the published destination and monitor errors and search observations after the change.

When the task is an application rather than a marketing site, web app development also needs to account for permissions, data and system responses. Keep those concerns in the plan rather than treating every small-screen problem as a CSS adjustment.

If the responsive product combines public pages with signed-in workflows, rendering and data access need their own plan. Our Next.js development service connects route-level rendering, content and APIs to the approved responsive behaviour, so the public offer and the working application support the same customer journey.

If designers publish the marketing site themselves, the responsive decision belongs in shared components and page templates. Our Framer development service builds those components, CMS pages and forms around the approved phone and desktop journeys, so editors change content without rebuilding every breakpoint.

A decision checklist

Choose one shared responsive site unless you can explain the need for something else. Add adaptive composition where it improves a specific task. Keep a separate mobile site only with explicit product or technical justification and clear maintenance ownership.

Before committing, answer: Which tasks must work? Which information must stay available? What changes at a narrow window? What does the implementation actually load? Who maintains the content? What happens to old links? How will you verify the destination and the task?

ANODA makes these choices concrete before implementation. In Sail, we redesigned the mortgage product comparison so eligibility reasons stay accessible on both desktop and mobile web; your website needs the same care for its own buying decision. Discuss your responsive website with ANODA before another layout change leaves the conversion problem underneath.

Then test the important journeys. Usability testing shows whether people understand and complete them; code and device checks show whether the implementation supports the designed behaviour. Both matter more than a single mobile-friendly label.