Everyone is asking the same thing right now. Do we ship a separate mobile site or go all in on responsive? That question is not just for the design crew. It hits the newsroom and the business side every single day.
Why this debate is loud right now
Search is pushing hard on phones after the mobile friendly shakeup in spring. Facebook rolled out Instant Articles to a small group and it is changing how stories travel. Apple showed its News app at WWDC and every editor is trying to guess what that means for distribution in the fall. Screens got bigger, data plans did not get cheaper, and readers expect fast pages that do not fry their battery. In that mix, the choice between a separate mobile site and a responsive site is more than a tech preference. It changes how you plan headlines, choose photos, lay out a feature, and measure success. It changes who in the building owns the pain when something feels slow or a chart is unreadable on a five year old device.
So the choice is editorial as much as it is technical.
What a separate mobile site gets you
A separate mobile site lets you make deliberate cuts. You can create lean templates that carry the story with minimal widgets, fewer third party scripts, tighter ad positions, and a stripped header. Navigation can be focused on today and right now instead of a full taxonomy tour. You can show shorter decks, swap the main photo for a tighter crop, and hide that auto playing sidebar video that is great for desktop and terrible on a bus. On a separate site you can set specific mobile rules for galleries, live blogs, and scoreboards without worrying about breaking your flagship layout. Ad ops can run a different stack and avoid units that choke phones. Product can test a sticky sign up box or a short related links rail and actually get a result without desktop noise.
Control is the big draw.
The cost of a separate mobile site
That control has a price and you will feel it fast. A separate mobile site creates parallel everything. Two sets of templates. Two sets of bugs. Two sets of analytics views. Two places where share counts fragment. Your social team grabs a link from their phone and it points to the mobile URL. Your desktop readers click and land on the mobile template unless you manage redirects perfectly. Editors write a headline that sings on desktop and then learn it wraps to five lines on a small screen and pushes the lead below the fold. If your CMS has a single field for headline and one photo crop, someone will be unhappy every day. International setups add more layers. Canonical tags, alternate links, and redirects need to be mapped like a railway schedule, and one mistake spooks search. Parity matters too. If your mobile page is missing the same structured data, the same byline, or the same comments block you will see a split in search behavior and reader trust.
You gain knobs and you gain overhead.
What responsive buys you
Responsive unifies your world. One URL per story. One analytics trail. One comments thread. Sharing is cleaner and your social previews do not splinter. Editorial writes once and knows the exact link that will travel. Designers and engineers can build components that bend instead of duplicate pages that compete. When you invest in good type scales, flexible media blocks, and smart image sizing, your content breathes on every screen without a second thought from the desk. Teams move faster because they are all looking at the same thing and not a forked branch. When breaking news happens you are not waiting on a mobile specific hotfix because the CSS that controls the small screen sits next to everything else.
The promise is simplicity with fewer places to trip.
Where responsive bites back
Responsive only works when your system is honest about weight. If you pour desktop features onto phones and simply collapse columns, you will ship slow pages. The phone still downloads what it cannot see. If your photo workflow cannot supply multiple sizes, you will end up sending a giant image to a small screen. Ads can fight with fluid layouts and jump the page. Video players that work fine at wide breakpoints can feel cramped and tap targets can get mean. The newsroom sees all of this as quality problems, not CSS problems. Which is fair. Readers blame you, not your breakpoints.
Responsive is not a free pass. It is a discipline.
Editorial tradeoffs you feel day to day
Picture a long weekend feature with lush photos, pull quotes, inline charts, and a timeline. On a separate mobile site you might short circuit that to a photo lead, a clean timeline, and a simple chart image. On a responsive site you need every block to gracefully reflow. Pull quotes should not hijack the page. Charts should not turn into postage stamps. Timelines should scroll nicely without jitter. Now look at a straight news post with updates. On a separate mobile site you might add a pinned facts box and hide older updates behind a toggle. On a responsive site you want that facts box as a reusable component that can pin, collapse, and switch style based on screen width. Then take a traffic staple like a gallery. On a separate mobile site you can choose full bleed with thumb previews and tune captions for compact space. On a responsive site you need the carousel to behave across widths and still keep captions readable. Each choice hits copy, photos, and the pace of publishing.
This is why templates are not abstract. They are daily tools.
Performance and money
Speed is not a vanity metric. On phones it drives everything from bounce rate to ad viewability to subscriber mood. A separate mobile site can be lean by design and skip heavy desktop modules. That can mean faster first paint and more readable pages on spotty networks. A responsive site can be just as fast if you make firm decisions about what loads at each breakpoint, keep JavaScript in check, and ship smaller images. The difference is where the discipline lives. With a separate mobile site you put the walls in the templates. With responsive you put the walls in component rules and asset delivery. Both roads require you to get serious about third party scripts, big hero images, and noisy embed widgets. Your ad setup matters too. Sticky units and interscrollers can hurt reading flow and slow the tap that moves a reader to the next story. When you tune for speed, your revenue team will see better viewability and more consistent session length. That is real money.
Fast pages print money on phones.
CMS questions that decide the path
Your CMS can force your hand. Do you have fields for short headlines and social headlines and can the site select based on screen width? Can editors choose photo crops for small screens without a trip to Photoshop every time? Can you flag certain embeds as mobile only or desktop only? If the answer is no, a separate mobile site gives you a set of mobile safe defaults while you modernize your tools. If the answer is yes or close, responsive starts to shine because it lets those fields work together. Think about the editorial experience. If a producer has to babysit every story, you will lose speed. If you can set smart defaults and still allow an editor to override when needed, you will get quality without slowing the newsroom. Also look at your plans for Apple News and Instant Articles. Those feeds want clean content blocks. Building that discipline into your CMS helps both mobile and desktop.
Pick based on the system you have, not the one you dream about.
SEO house rules that travel with you
Search has simple expectations if you keep your setup tidy. With a separate mobile site, keep one canonical URL for each story on the desktop side and point your mobile page to it. Use alternate links that tell search where the phone page lives. Map redirects carefully so a desktop link does not strand someone on the wrong template. Keep content parity so the snippet people see in results matches what they land on. Mirror your structured data and your social metadata so shares look the same from any device. With a responsive site, focus on getting a green light from the mobile friendly test, use readable type, and keep tap targets friendly. Keep any app banner gentle and easy to dismiss. Do not block assets that search needs to render your pages. Clean up soft 404s on mobile like dead tag pages that only exist on desktop. The goal is one story with clean signals from every device.
Search bots are picky but they are consistent.
Real world picks
You can learn a lot by watching other teams. The Guardian, BBC, Vox Media, and The Verge run responsive across the board and it shows in consistent sharing and a strong reading experience on big and small screens. ESPN just rolled out a huge redesign with a mobile first mindset and made responsive feel fast for a sports firehose. The New York Times leans on responsive for its article pages and features, which helps long reads feel good on phones. On the other side, CNN keeps a separate mobile site that lets them trim modules and run a different ad playbook. Wikipedia runs a separate mobile site with a clean skin that loads fast where network quality is rough. Amazon and Facebook use their own mix of adaptive tricks and separate mobile flows because their products have very different goals from page to page. These choices are rooted in workflow, not taste. Each publisher picked the path that matched their CMS and their daily demands.
Copy the teams whose constraints look like yours.
A quick decision framework
If I had to decide this week, I would run through a short list with the people who actually ship the news. Keep it blunt and tie every answer to a reader task or a revenue goal.
- Do we need different headlines or image crops for phones because our topics demand it most days?
- Can our CMS express those differences without a manual fix on every story?
- Do we have the patience and people to keep two template sets healthy and fast?
- Are our ads and embeds flexible enough to behave in a responsive world without jank?
- Will a single URL per story improve our social reach and analytics truth more than we will gain from a tuned mobile only flow?
Five honest answers usually point one way.
Practical to dos for the next two sprints
Give yourself two sprints to test without changing the whole site. Audit your top ten templates by traffic on phones. Measure real load time on a modest Android device and an older iPhone over a slow network. Cut one third of third party scripts on those pages and see what moves. Create a simple rule for headlines and decks on small screens and train the desk on it. Set fixed photo crops for small screens on your most used article template and enforce them. Sit down with ad ops and pick a mobile ad map with fewer jumps and better viewability. Turn off one embed type that burns time and rarely helps the story. Design a small set of components that ship lighter images on phones. Give editors a way to mark an element as heavy so it does not load on a small screen. Track the bounce rate and scroll depth after these changes. If numbers improve and the newsroom breathes easier, lock in those wins and then decide if you need a whole separate mobile site or if responsive with discipline is enough.
Small wins stack fast when phones are your first reader.
Where I am landing this week
My pick for most publishers is a focused responsive approach with strict performance rules. One URL per story keeps your world tidy and helps every team move together. Build flexible blocks, tune image delivery, and say no to heavy extras that do not help the read. If your CMS cannot support basic mobile editing power or your product goals on phones are truly different, ship a separate mobile site that is brutally simple and fast while you modernize your tools. Keep an eye on Apple News and Instant Articles because they are teaching the same lesson in a new place. Clean content blocks, light pages, and no clutter win. Windows just shipped a fresh browser and new devices are on the way, so the future is not fewer screens. It is one story that bends without breaking.
Pick a path and commit to it for a year.
Build for the reader in their hand, not the wireframe in your head.