If you’re about to approve a new website, here’s the problem: you’re looking at it on a desktop browser on your laptop. Your developer built it on a desktop. Your agency shared a preview link you opened on a desktop.
But 64.35% of global web traffic now comes from mobile devices, according to SOAX’s July 2025 research tracking Statcounter’s platform analytics going back to Q1 2009. The majority of people who’ll visit your site after launch will be on a phone — and none of the three of you checked it there.
That’s not carelessness. It’s the default review pattern. And it’s why sites ship with a navigation menu that won’t close, a form that disappears behind a keyboard, and a layout that turns into a single column of text stacked awkwardly under a hero image that’s four times too tall.
This checklist exists to break that pattern. It’s 23 specific items organized into four passes: desktop, mobile viewport, tablet, and content. It’s written for non-technical founders — the people who are the final reviewer but don’t have a QA team — and it’s designed to catch the issues that get missed when everyone reviews on the same device they built on.
If you want the collaboration workflow for how to share what you find — how to give feedback your developer can actually act on — that’s covered in How to Give Website Feedback Without the Back-and-Forth. This post is about what to look for.
Why do so many websites ship broken on mobile?
Because everyone in the review process uses the same device. The developer builds on a desktop. The designer previews on a desktop. The founder approves on a desktop. No one has a structural reason to pick up their phone during the review cycle — until someone messages after launch about the navigation that won’t close.
The gap compounds because mobile problems are invisible at desktop size. A layout that breaks at 375px looks fine at 1440px. A tap target that’s too small registers correctly with a mouse. A form that gets obscured by a software keyboard only fails when you’re actually typing into it on a phone.
There’s also an SEO consequence. Google’s mobile-first indexing means the mobile version of your site is what Google crawls and uses to rank your pages. If your mobile layout hides content or renders key sections broken, that’s the version Google sees — regardless of how polished the desktop version is. Mobile isn’t just a user experience concern; it’s a search visibility concern.
The fix is a structured mobile pass built into the review process before launch, not an afterthought. The checklist below gives you that structure.
How should you structure a pre-launch website review?
Four passes — desktop, mobile viewport, tablet, and content — each focused on the failure modes that only show up at that size or in that category. Don’t try to do all of this in a single scroll of the staging URL. Each pass requires switching from “does this look good?” to “does this specific thing work?”
Budget 45–60 minutes for the full four passes on a typical marketing site. More if there are multiple page templates (landing pages, blog posts, product pages) that each need the mobile and tablet checks.
When you find something, pin it immediately. Notes written from memory at the end of a review session are always less precise than comments left in the moment — which is the same problem async feedback tools are designed to solve. Simpl_Markup lets you click directly on an element in a live browser preview and pin a numbered comment to it, so each piece of feedback is tied to exactly what you’re looking at when you see the problem.
What should you check in the desktop pass?
The desktop pass is where most founders spend all their review time. It’s necessary but not sufficient. Six things to check:
1. Does the hero section communicate the main offer without scrolling? The first thing a visitor sees should tell them what the site is for. If someone has to scroll before they understand what you do, you’ve lost most of them. Read the hero section aloud as if you’ve never heard of the company. Does it make sense in one read?
2. Does every navigation link go to the right page? Click every item in the main navigation and every link in the footer. Staging environments are full of links pointing to placeholder URLs or pages that never got connected. A link that doesn’t work is a worse signal than a link that’s not there yet.
3. Do all images load? Scroll through the full page looking for broken image icons — the small grey box browsers display when an image fails to load. These appear when assets weren’t uploaded to the right path, when image filenames were changed after the developer linked them, or when CDN configuration went wrong.
4. Does every form work end to end? Submit each form with test data. Confirm two things: the submission goes through (check the inbox or form dashboard it connects to) and the confirmation state appears. A form that looks functional and silently fails is one of the most common pre-launch oversights.
5. Does the main CTA appear above the fold and function correctly? The primary button or call to action — “Get started,” “Book a call,” “Buy now” — should be visible without scrolling and should go where it’s supposed to. Click it. Confirm the destination.
6. Does the page scroll without layout shifts? Scroll slowly from top to bottom and watch for elements jumping position — text that moves when an image loads, sections that briefly render on top of each other, or content that appears and then pushes everything below it down. These are driven by images loading after the text has already rendered, and they feel broken even when everything else is fine.
What should you check in the mobile viewport review?
This is the pass most founders skip, and the one responsible for most post-launch embarrassment. Six items:
7. Is the text readable without zooming? The practical standard for readable mobile body text is 16px minimum. Text smaller than that causes visitors to pinch-zoom to read — and most won’t. The Baymard Institute’s 2025 mobile UX benchmark across 150+ sites found that 81% of sites scored “mediocre” or worse on overall mobile performance. Illegible text is one of the primary drivers of that number.
8. Are all buttons large enough to tap accurately? The WCAG accessibility standard for touch targets is 44×44px minimum. Anything smaller — small social icons, tight navigation links, footnote-sized CTAs — becomes a source of mis-taps. If two tappable elements are close together, there should be enough spacing that hitting one doesn’t activate the other.
9. Does the mobile navigation open, close, and work? Open the hamburger menu. Click a link. Navigate back. Close the menu. This four-step sequence is where mobile navigation fails most often: menus that open but won’t close, links that navigate but leave the menu in place, menus that block content after you’ve closed them. The same Baymard benchmark found that 69% of sites scored “mediocre” or worse specifically on mobile main navigation — making it the single most common broken element on mobile sites.
10. Do images stay within the screen width? Try to scroll horizontally. If you can, something is wrong. Images defined at a fixed pixel width wider than the device viewport force horizontal scroll — the most reliable indicator of a mobile layout failure. Look for any element that’s wider than the screen.
11. Can you complete forms without the keyboard covering the submit button? Tap into the first field of each form. When the software keyboard appears, can you still see the rest of the form? Can you reach the submit button? Forms are among the most fragile elements of a mobile site. A submit button that disappears behind a keyboard produces zero conversions from mobile visitors.
12. Does the page load in under 3 seconds on a mobile connection? 53% of mobile site visits are abandoned if a page takes more than 3 seconds to load — a figure cited repeatedly in Google’s web performance documentation. Test by loading the staging URL on a phone on cellular data, not Wi-Fi. Desktop broadband masks slow-loading assets that mobile networks will expose.
Note on how to do this pass: You don’t need to switch devices for this. Simpl_Markup’s live browser supports desktop, tablet, and mobile viewport presets that you switch mid-session from your laptop — which means you can pin mobile-specific comments without putting down your mouse.
What should you check in the tablet viewport review?
Tablets are the hardest device to design for because they sit between desktop and mobile breakpoints — often triggering neither the desktop layout nor the mobile layout cleanly. Three specific things:
13. Do multi-column layouts hold at tablet width? A two-column layout that looks right on desktop and collapses gracefully on mobile often goes wrong at the middle width: one column collapses while the other doesn’t, or the two columns stack in the wrong order, or the layout is technically neither desktop nor mobile and looks like a mistake. Preview at 768px wide and look for layouts that seem confused about what size they’re trying to be.
14. Does the navigation work in landscape orientation? At certain tablet widths, navigation switches from a hamburger to a full horizontal menu — but only at the right breakpoints. A tablet in landscape mode can end up at a width where the menu is clipped, partially visible, or switches to the wrong layout entirely. Check both portrait and landscape.
15. Do popups, modals, and banners render correctly at tablet size? Cookie consent banners, welcome overlays, newsletter modals, and promotional banners that look fine on desktop can take up too much screen at tablet width, or have close buttons that fall off the bottom of the viewport. Check each one that fires on page load.
What should you check in the content and copy review?
This pass is device-independent — you’re checking what’s on the page, not how it renders. Five items:
16. Is every piece of placeholder text gone? Use Cmd+F / Ctrl+F to search the page for “Lorem.” Check every input field for default placeholder text that wasn’t replaced. Look for dummy pricing, placeholder team member names, or “Your Headline Here” text that survived from a template or wireframe. This category of error signals that the site wasn’t reviewed before launch — it’s the first thing anyone notices.
17. Do all internal links point to the live URL, not staging?
Developers often build on staging environments at URLs like staging.yoursite.com or localhost:3000. Internal links built during development can still point to those addresses. Click through every major internal link and confirm the destination is the production URL.
18. Are page titles and meta descriptions in place? Open the browser tab and confirm the title isn’t “Untitled” or a CMS default. Check meta descriptions via browser developer tools (or a free crawler like Screaming Frog) on the key pages: homepage, primary product or service page, contact page. Meta descriptions are what Google and AI search engines read before deciding whether to retrieve a page.
19. Is your contact information correct? Phone number, email address, physical address if relevant. These get wrong in specific ways: copied from a template, updated in one place but not everywhere, or formatted as a link on desktop but not on mobile. Tap the phone number on a mobile device — it should open the dialer.
20. Does the mobile version contain the same content as the desktop version?
Google indexes the mobile version of your site first. If the mobile layout uses display: none to hide sections that exist on desktop — a common shortcut for making desktop-first layouts “work” on mobile — that content is effectively invisible to search engines. The key pages should have equivalent content at both sizes.
What should you do before you call the site launch-ready?
Three final checks that require stepping outside the review process to catch what familiarity has hidden:
21. Has someone outside the build team tested it on an actual phone? Browser emulators catch layout problems. Real devices catch different things: actual touch behavior, real cellular network speeds, rendering quirks in mobile Safari that Chrome DevTools doesn’t replicate. If you can, hand a phone to someone who wasn’t involved in building the site and ask them to complete the main action on it — sign up, book a call, buy. Watch without guiding them.
22. Did you test in both Chrome and Safari on mobile? Chrome on Android and Safari on iOS render pages differently. A site that passes every check in Chrome DevTools can have text rendering issues, flexbox behavior differences, or form handling bugs specific to Safari. Any professional review includes a Safari pass. You’ll need a Mac or iPhone — or a remote browser tool that runs a real Safari session.
23. Are all comments from previous feedback rounds resolved? Before calling the site ready, confirm that every open comment from prior review rounds is either fixed and marked resolved, or explicitly deferred with a reason. Feedback that got lost in a Slack thread — marked read but never acted on — is how sites launch with known issues that were flagged weeks earlier. A tracked review system like Simpl_Markup shows every comment’s status — open, fixed, approved — in one view, so nothing slips through on the final pass.
What should you do when you find something during the review?
Don’t collect issues to report at the end. Sending one big summary message after a review session is slower for your developer than comments sent in the moment — because by the time you write the summary, you’ve lost the specificity. “The mobile nav is weird” is not actionable without three follow-up questions.
Visual feedback pinned to the exact element takes the guesswork out. A comment that lives in the context of the broken nav — at the viewport size where it’s broken — means your developer can see exactly what you saw and fix it without a back-and-forth. If your current review process involves taking a screenshot and pasting an arrow into Slack, Simpl_Markup vs Screenshots in Slack breaks down exactly why that workflow breaks down under review pressure.
That’s the review-cycle delay that turns a one-day revision into a one-week spiral. The checklist keeps your review structured. Pinning comments to specific elements keeps your feedback actionable. Together, they give your developer what they need to fix things right the first time.
Simpl_Markup pins comments directly to specific elements on a live browser preview of your site, syncs them to your Slack workspace, and tracks every comment’s status — open, fixed, approved — so nothing gets lost between review rounds. One workspace, your whole team, flat $29.95 a month.
Run the four passes. Pin what you find. Call it done.