Web Development
Responsive design in Hannover
Most traffic comes from mobile devices. Responsive layouts therefore underpin SEO, conversions and usability, not a design nicety.
What responsive design delivers
A responsive site adapts layout, typography and controls to screen size and input type. Technically: fluid grids, flexible images, CSS media queries. Typical breakpoints sit at 320 / 768 / 1024 / 1440 px, as a starting point, not a rule: the right breakpoint is wherever your own content visibly breaks.
| Building block | Practice |
|---|---|
| Layout | CSS Grid / Flexbox, mobile-first |
| Typography | clamp() instead of fixed pixels |
| Touch | Targets at least 44×44 px |
| Images | srcset, WebP/AVIF, lazy loading |
Mobile-first and Google
Google primarily indexes the mobile version. Mobile-first indexing has been the default case for years, not the exception. A slow or unusable mobile experience hurts rankings and conversions together, not just one of the two.
Core Web Vitals (LCP, INP, CLS) measure real user experience. Details in the performance guide.
Local search: Many queries start on smartphones. Mobile-friendly UX is a prerequisite; Hannover tactics in the local SEO guide.
UX and business impact
Responsive sites typically reduce bounce and make forms, navigation and reading easier. Measure in analytics and Search Console, not industry averages alone.
The guide to UX design for business websites shows how these decisions work together beyond individual breakpoints.
Forms: Fewer fields, appropriate input types (tel, email), autofill, inline validation.
Navigation: Hamburger or bottom nav, key actions within thumb reach.
One codebase instead of two sites
Separate mobile and desktop properties double maintenance: two codebases, two places to apply security updates, two places where content can drift apart. One responsive site means one content set, one deploy, consistent analytics.
A separate mobile domain carries an extra risk: if content diverges too far between the mobile and desktop versions, it can read as cloaking, whether or not that was the intent. A single responsive codebase avoids that risk structurally.
New device classes (foldables, large tablets) benefit automatically when the layout is built fluidly.
Common responsive mistakes in relaunches
- Desktop first, mobile later: almost always creates compromises in navigation and forms.
- Breakpoints from device lists instead of content: layouts still break despite "correct" pixel values.
- Oversized images: hero visuals look good but destroy mobile LCP.
- Small touch targets: polished design, poor usability.
100vhon mobile: the fixed viewport unit ignores the collapsing and expanding address bar in mobile browsers, so content jumps or gets cut off.100dvh(dynamic viewport height) fixes this, but older components often still miss it.- No real-device testing: DevTools emulation cannot show real scroll, keyboard-overlap and tap issues.
A recurring mistake is treating "responsive" as visual polish only. In practice it is a system of layout, performance, content and conversion paths.
Responsive and conversion in B2B
For business sites, success is not "it fits on phone" but whether users can complete actions:
- send an enquiry
- request a callback
- book an appointment
- understand a service page quickly
If these steps are hard on mobile, conversion drops even when rankings are strong.
Three conversion-path checks
| Check | Goal | Example |
|---|---|---|
| Entry | first key information visible immediately | value proposition without scrolling |
| Interaction | forms and buttons with low friction | field types, clear errors, large CTA |
| Completion | clear confirmation and next step | thank-you state with contact option |
For local businesses in Hannover this mobile clarity matters because many first contacts happen on the go.
Common mistake
Emulator testing in the browser is not enough. Chrome DevTools' simulated view shows neither how a real address bar behaves nor keyboard overlap on iOS nor real scroll momentum. At minimum, core journeys belong on real devices before a site goes live.
BitAutor in practice
In responsive work, we deliberately separate what an emulator shows from what a real device shows. Three problems show up regularly in real-device testing that DevTools never surfaces: the collapsing address bar in mobile browsers, which makes 100vh layouts jump; keyboard overlap on iOS, which can hide a form's CTA behind the on-screen keyboard; and real scroll momentum, which makes sticky elements behave differently than in emulation.
We set breakpoints from content, not from a device list: resize the viewport until the layout visibly breaks, that's where the breakpoint goes, regardless of whether it matches a common device width. For copy-heavy sections we reach for clamp(); for components with fixed proportions (tables, fixed-size image cards) we often still use discrete breakpoint values, because fluid scaling is harder to predict there.
We size the testing budget from actual analytics data, not a wish list: the two or three device classes that real visitors actually use most get real-device testing, everything else runs through emulation and Lighthouse. For internal tools with confirmed desktop-heavy usage, that priority shifts accordingly, "responsive" there means not broken on mobile, not the same testing effort as the public marketing site.
Pre-launch test plan
Device matrix
- iPhone class (small and large)
- mid-range Android
- tablet (portrait and landscape)
- desktop (at least two widths)
Scenarios
- load homepage on mobile network
- read service page and submit enquiry
- submit form with intentional error
- open, close and re-open navigation
Success metrics
- mobile Core Web Vitals at least "needs improvement", target "good"
- bounce rate on top pages decreases after relaunch
- mobile conversion rate moves closer to desktop
FAQ on responsive design
Is a CSS framework enough for responsive quality?
No. Frameworks provide components, not good information architecture or conversion decisions.
What breakpoints are "correct"?
The right breakpoints come from your content and components, not from a rigid device list. Resize the window until the layout visibly breaks, that's where the breakpoint belongs.
How much responsive testing is enough?
At minimum: core journeys on real devices plus Lighthouse and Search Console checks. Emulators alone miss real issues like a collapsing mobile address bar or keyboard overlap.
Does responsive design affect SEO directly?
Yes, both directly and indirectly: mobile-first indexing makes the mobile version the basis for evaluation, and better UX usually improves engagement signals too.
Do internal tools need the same responsive effort as a marketing site?
No, if usage data confirms the audience works mostly on desktop. "Not broken on mobile" is often enough there, while the public website justifies the full testing effort.
Pre-launch checklist
- Correct viewport meta, no horizontal scroll
- Readable text without zoom (roughly 16 px base)
- Images not served oversized
100dvhchecked instead of100vhfor full-height mobile layouts- Test on real devices, not only DevTools
- Search Console: no mobile usability errors
Key takeaways
- Responsive is an SEO baseline since mobile-first indexing
- Performance and touch UX are part of responsive, not extras
- One codebase saves maintenance and avoids cloaking risk versus separate mobile domains
- Real-device testing finds bugs emulators structurally cannot show
- Locally: combine mobile UX with local SEO
