No.
That’s the short version. Here’s why the long version matters anyway.
Google stopped crawling sites with its desktop bot in July 2024. Every website now gets visited by a smartphone crawler. If your site doesn’t work on mobile, Google doesn’t really see it. Not “sees it poorly.” Sees a broken version of it. Indexes that broken version. Ranks you accordingly.
Not a preference or best practice. It’s the infrastructure of how search works now.
The Numbers Closed This Debate Years Ago
Mobile traffic passed desktop globally in 2016. The gap kept widening. Current data shows around 60% of web traffic worldwide comes from phones. In Africa, it’s over 70%. Parts of Asia push past that.
Even markets where desktop holds stronger, like Germany and parts of the US, mobile still accounts for nearly half of visits. And that’s aggregate data. For specific industries, specific demographics, the mobile percentage climbs higher.
Five point seven billion people use mobile phones. In the US, 91% of adults own a smartphone. For many users, especially younger ones, the phone isn’t a secondary device. It’s the primary computer. Sometimes the only one.
So when someone asks whether a website can succeed without responsive design, they’re really asking: can I ignore most of my potential visitors? Can I build something that doesn’t work for the majority of humans trying to access it?
Obviously no. But people keep asking because they’re hoping for an exception that applies to them.
The Exceptions Are Narrower Than You Think
Internal tools used exclusively on company-issued desktops. Kiosk software running on fixed hardware in physical locations. Specialized industrial applications tied to specific workstations.
That’s roughly the complete list.
And even these are eroding. Enterprise IT increasingly supports bring-your-own-device. Employees expect to check dashboards from their phones. The internal tool that was desktop-only five years ago now faces pressure to work on tablets, then phones, then whatever comes next.
Educational institutions sometimes argue that complex academic content like data tables, intricate diagrams, and lengthy papers resists mobile adaptation. True, these don’t compress gracefully onto small screens. Also true: students access course materials from whatever device is convenient. Making them switch devices to read required content costs engagement.
Patterns emerge across supposed exceptions: what seems desktop-appropriate today faces mobile pressure tomorrow. Building without responsive capability bets against obvious trends.
What Mobile-First Indexing Actually Does
Google’s crawler pretends to be a phone when it visits your site. Whatever it sees in that mobile view becomes the basis for indexing and ranking.
If your mobile version has less content than desktop, Google only knows about the mobile content. If mobile loads slowly, that affects rankings. If mobile breaks entirely, good luck getting indexed properly regardless of how nice the desktop version looks.
Before July 2024, some older sites still got crawled with the desktop bot while Google encouraged migration. That grace period ended. Every site now faces the smartphone crawler.
September 2025’s core update pushed this further. Sites with poor mobile metrics like slow Largest Contentful Paint and major layout shifts saw ranking drops. Mobile optimization isn’t about meeting a minimum bar anymore. It’s ongoing competitive pressure.
Multi-Device Journeys Are Standard Now
Same person, different devices, different moments.
Morning commute: phone. Research a product, save some options. Lunch break: maybe tablet, maybe phone again. Compare prices, read reviews. Evening at home: laptop or desktop. Ready to buy, complete the purchase.
Far from edge-case behavior. It’s normal. Research on consumer purchases shows complex decisions routinely span multiple devices across multiple sessions.
Non-responsive sites face a problem: friction at any point breaks the chain. Someone who struggled with your mobile experience doesn’t come back on desktop to give you another chance. They remember your brand as difficult. They go elsewhere.
Responsive design serves the same content and functionality across screen sizes. Layouts adapt automatically. The alternative, separate mobile and desktop sites, creates sync problems. When mobile falls behind desktop in features or content, the experience degrades silently until someone notices traffic dropping.
Container Queries Change the Game
Traditional responsive design uses viewport-based breakpoints. The whole page responds to screen width.
Container queries let individual components respond to their own container’s size. A card component can adapt whether it’s in a narrow sidebar or a wide main area, regardless of screen width.
This matters because modern sites aren’t monolithic. They’re assembled from components used across different contexts. A product card appears in search results, category pages, recommendation widgets, checkout summaries. Each context has different space constraints.
Viewport breakpoints force awkward compromises. Container queries let components be genuinely portable.
Browser support is now solid enough for production use. This is the direction responsive design is heading: more granular, more component-aware, less dependent on page-level breakpoints.
Foldables and New Form Factors
Samsung’s foldables. Google’s Pixel Fold. Devices that change screen size while you’re using them.
Traditional breakpoint strategies assumed screen size was fixed for a session. You load the page, it detects viewport width, serves appropriate layout. Done.
Foldables break this assumption. User unfolds the device mid-session. Viewport changes dramatically. Does your layout handle that transition? Does it reflow gracefully or does it break?
Current market share for foldables is small. But the category is growing. And the underlying challenge of devices with dynamic, unpredictable screen configurations will only get more varied.
Building responsive systems that handle viewport changes smoothly, not just initial viewport detection, is the forward-looking approach.
Performance Budgets Constrain Breakpoint Complexity
Each breakpoint adds CSS. More breakpoints, more code, larger files, slower loads.
Adding breakpoints for every edge case conflicts with performance reality. At some point, additional breakpoints cost more in load time than they gain in layout precision.
Smart responsive strategy picks meaningful breakpoints for major device categories and notable layout shifts rather than trying to optimize for every pixel variation. Three to five well-chosen breakpoints usually outperform fifteen micro-targeted ones.
This is especially true for mobile users on slower connections. The extra kilobytes for hyper-specific breakpoints hit them hardest. And they’re exactly the users you’re supposedly optimizing for.
Progressive Web Apps Blur the Lines
PWAs (Progressive Web Apps) use web technologies but behave like native apps. Install to home screen. Work offline. Send push notifications. Access device features.
The line between “responsive website” and “mobile app” blurs here. A well-built PWA offers app-like experience without requiring App Store distribution or platform-specific codebases.
For businesses weighing “should we build an app or make our site responsive,” PWA offers a third option. Responsive foundation, progressive enhancement for app-like capabilities where supported.
PWA features aren’t universally necessary. But understanding the option prevents false dichotomies between web and native approaches.
The Cost Argument
Responsive design costs more upfront than desktop-only. More planning, more testing, more complexity in layouts and images and interactions.
Alternatives cost more over time. Maintaining separate codebases means duplicating work. Bug fixes happen twice. Features get implemented twice. Testing happens twice. Documentation drifts apart.
Single responsive codebase means single source of truth. Update once, deploy everywhere. Technical debt stays contained.
Short-term budget pressure pushes toward cutting responsive work. Long-term budget reality punishes that choice.
What This Means Practically
If you’re building something new: responsive from the start, no debate.
If you’re maintaining something old that isn’t responsive: migration isn’t optional, it’s scheduled. The question is when, not whether.
If you’re evaluating whether your specific case is an exception: it probably isn’t. The exceptions are genuinely narrow. Most sites that think they’re exceptions are actually just postponing inevitable work.
Mobile-first isn’t ideology. It’s arithmetic. Most users, most traffic, most search weight comes from mobile. Design for that reality or design for failure.
FAQ
Our analytics show 70% desktop traffic. Why prioritize mobile?
Two possibilities. One: your audience genuinely skews desktop, probably B2B or specialized professional tools. Two: your mobile experience is bad enough that mobile users bounce before registering in analytics. Check bounce rates by device. If mobile bounces much higher, you’re not seeing desktop preference; you’re seeing mobile users leaving before converting.
What about complex data tables that don’t fit on phone screens?
Horizontal scroll within the table. Collapsible columns showing key data with expand option. Card-based layouts that stack rows vertically. Separate simplified mobile view for scanning, with link to full table. None of these are perfect. All are better than “doesn’t work on mobile.”
How many breakpoints do we actually need?
Fewer than you think. Mobile (up to ~480px), tablet (~481-1024px), desktop (~1025px+) covers most cases. Add one or two more if your layout has specific needs at certain widths. More than five usually means over-engineering. Test on real devices, not just resized browser windows.
Should we build a separate mobile app instead?
Right choice varies by requirements. If you require deep device integration, offline-heavy functionality, or App Store presence, native app makes sense. If you need broad accessibility without install friction, responsive web wins. PWA offers middle ground. Most businesses don’t need native apps, they need responsive sites that work properly.
Sources
Statista. Percentage of mobile device website traffic worldwide. statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices
Google Search Central. Mobile-first indexing best practices. developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing
DataReportal. Digital Around the World. datareportal.com/global-digital-overview
Web.dev. Responsive design basics. web.dev/responsive-web-design-basics
MDN Web Docs. CSS Container Queries. developer.mozilla.org/en-US/docs/Web/CSS/CSScontainment/Containerqueries