Website Looks Different on Mobile: Broken or Meant to Be?

You approved a design on a wide screen. Two columns, a menu across the top, an image sitting neatly beside the text. Then you opened it on your phone and the columns are stacked, the menu is three lines in a corner, and something you specifically asked for is not where you left it. The question underneath is not really about layout. It is whether you have been sold something faulty, or whether this is how it is supposed to work and somebody should have said so. Nearly everything written about this is written by developers for developers, which is why it never quite answers you. There is a line between a deliberate change and a genuine fault, and you can apply it yourself in about ten minutes.

A responsive site is usually the same page, sent to every device, drawn differently according to how much room there is. Google describes responsive design as the same HTML on the same address, displayed to suit the screen size.

So, some difference is not optional. A navigation bar with seven items across a laptop cannot physically fit across a phone. Three columns of cards become three unreadable slivers. Something has to give, and what gives is the arrangement.

This is also why Google cares. It says it crawls and indexes using the mobile version of your content, so what a phone gets is what search sees. That raises the stakes on one particular kind of difference, which is content that is present on desktop and absent on mobile.

None of that means every difference is fine. It means the wrong question is "why does it look different" and the right one is "has anything been lost".

The test is whether a visitor can still find out what they need and do what they came to do. Everything else is arrangement.

These are normal, and worth recognising so you stop worrying about them. Columns stacking into one. Navigation collapsing behind an icon. Images resized or cropped differently. Decorative panels dropping away. Secondary material reordered, or moved into a tab or an expandable section, which Google explicitly permits as long as the primary content stays equivalent.

These are faults, and each one is checkable without any technical knowledge. Ordinary text that requires side-to-side dragging to read. Content or a button clipped off the edge of the screen. A menu that will not open, or opens and will not close. A form you cannot finish, or a field you cannot see while typing in it. A cookie banner or chat bubble sitting permanently over the thing you need to tap. Primary information that exists on desktop and simply is not on the phone version.

The W3C guidance on reflow puts a number on the first of those: vertical content should be usable at a width equivalent to 320 pixels without losing information or function and without needing two-directional scrolling, with sensible exceptions for things that are genuinely two-dimensional, like a map or a large data table.

Do this on the live public site, not in the builder's preview. A design preview is a drawing of the page; the phone is the page. Log out first, or use a private window, because what you see as an administrator is not what a customer meets.

Start with the page somebody complained about, then the pages that earn money. For a service business that is usually the service page, the contact page and whatever the main button does. Turn the phone sideways as well as upright, because landscape breaks things portrait does not.

At each step, try the actual task. Open the menu and close it. Tap every link in it. Fill in the contact form to the end and submit it. Start the booking. Tap the phone number and the email address. Accept and then reopen the cookie controls. Look at what happens when you make a mistake in a form, because error messages are a classic place for text to appear off screen.

Then make the text bigger in your phone's settings and go through the same pages again. This one catches a surprising amount, because a layout that only just fits at the default size falls apart as soon as somebody with tired eyes turns the text up.

Write down what happened, on which page, on which phone, and take a screenshot. That record is the difference between "the site looks wrong on mobile", which nobody can act on, and a reproducible fault.

When somebody competent picks this up, the order tells you a lot about whether they are going to fix the cause or the symptom.

They reproduce it first, on a real device rather than only in a desktop emulator, because an emulator finds the breakpoint quickly and a real phone shows the actual experience. They record the address, the phone, the browser, the orientation and whether they were logged in.

Then they separate the list into deliberate changes and defects, and show you which is which. That step is the one that gets skipped, and skipping it is how an owner ends up paying to undo responsive behaviour that was correct.

Then they check parity: is the principal content, along with the headings and the page's own title and description, the same on the phone as on the desktop? Google's warning here is worth taking seriously, because if the mobile version carries less, search has less to work with.

Then they find the cause before proposing a remedy. A missing viewport setting, a fixed-width element, a rule at the wrong breakpoint, an oversized image, a script error, a blocked stylesheet, a third-party widget, a consent layer, or something changed in a recent update. Which one it is decides whether this is twenty minutes or a fortnight.

Then the smallest scoped change, tested somewhere other than production, and the same device and journey list run again afterwards.

Nobody can quote this honestly without seeing the site, because the same symptom covers a one-line change and a rebuild. What can be shown are marketplace indicators, which are not a local rate and not a quote.

Upwork's web developer hiring page states a general marketplace range of $15 to $50 per hour, and lists $500 to $2,000 for ongoing maintenance and support covering bug fixes and updates. Its HTML developer rate page reports historical worldwide contract medians of $15 to $30 per hour with examples at $20, $36 and $80 by skill level. Those are figures from one marketplace, and they describe what people charge there rather than what your job should cost.

The things that push a job up the range are worth knowing before you get a quote. One template affected, or many. A custom component or a third-party widget in the middle of it. Missing primary content on mobile rather than a layout problem. Separate mobile addresses rather than one responsive site. A decision about what should be cut on a small screen, which is your call and takes meetings. Checkout or booking in the affected path, which has to be tested properly. And whether the fix is a rule, a template, or a replacement.

Ask for the affected pages, the devices to be tested, and what counts as done, in writing. A promise of "mobile optimised" with no test list attached is not something you can hold anybody to. The same principle covers what a website costs you every month: the recurring items belong in the quote as clearly as the one-off ones.

Everything in the ten-minute test is safe, and so is running the public address through PageSpeed Insights, which reports mobile and desktop separately. So is clearing your browser cache and trying again, which rules out the most embarrassing cause. So is comparing a real phone against a desktop emulator to find roughly where the layout changes.

Where to stop is clearer here than in most website work. Do not edit theme files, custom styles, plugins, scripts, caching, content delivery settings, consent tools or booking code on a live site without a backup, a preview and a plan for putting it back. A visual tidy-up can quietly change the desktop version too, because both often share the same components.

One specific thing deserves naming, because it is the most common bad advice on this subject. Do not hide the sideways scrolling with an overflow rule before finding what is overflowing. It makes the screenshot look right, leaves the cause in place, and can hide real content off the edge where neither a visitor nor search can reach it.

If you use an Android phone, TalkBack is built in and you can listen to a page if you are comfortable doing so. Report what you heard as an observation rather than a verdict, because that is a check, not a conformance assessment.

There is no Arlington rule about how a website must behave on a phone, no city standard and no local certification. The technical standards here are national and international.

What is real locally is ordinary business support. The City of Arlington lists small business resources including permits, Urban Design Center services, library workshops and mentorship connections, and Arlington Economic Development points to the Tarrant Small Business Development Center, which has satellite offices in Arlington, for mentoring and consulting. Neither funds a mobile repair, and it would be wrong to imply otherwise.

Two Texas points do touch this. What somebody says while selling you the work falls under the state's rules on false, misleading or deceptive practices, which is a reason to insist on a testable definition of done rather than a slogan. And if the work changes how visitor information is collected or which third-party tools handle it, the Texas Data Privacy and Security Act may be relevant to the businesses it covers, with its own small business provisions. It is not a layout rule, it does not apply automatically because a site has a contact form, and none of this is legal advice.

The habit that prevents this is short enough to actually keep. Hold a list of the devices you care about, which for most local businesses means a current iPhone, a current Android, portrait and landscape, plus one small width. Hold a second list of the tasks that matter: menu, contact, booking, checkout, search.

Check those tasks on those devices after anything meaningful changes. A new theme, a plugin, a template edit, a chat tool, an embedded video, a batch of photographs. That is when mobile breaks, and it almost never announces itself, because the person who made the change was looking at a desktop.

The other half is writing down the intended mobile treatment when the site is built or redesigned. If it is a recorded decision that a panel drops away on small screens, nobody has to relitigate it eighteen months later. If it is not recorded, every future difference looks like a fault.

You will know it is right when ordinary text needs no sideways dragging, nothing is clipped or covered, the menu opens and closes, every task can be finished, the phone version carries the same primary information as the desktop one, and enlarging the text does not break any of that.

Why does my website look weird on my phone?

Usually because a wide layout has been rearranged to fit a narrow screen, which is intended. It is worth checking anyway, because a genuine fault can sit alongside the intended changes and looks similar at a glance.

Should my mobile site look identical to the desktop version?

No, and forcing it to usually makes things worse. The requirement is that a visitor can find the same information and complete the same tasks, not that the geometry matches.

My builder's preview looks fine. Why does the real phone not?

A preview is a rendering inside the editor, and it does not claim to reproduce every device. Test the live public address on a real phone, logged out.

Is small text on mobile a failure?

Not by itself, and there is no single font size that passes or fails. The testable questions are whether ordinary reading needs sideways scrolling, and whether the page still works when somebody enlarges the text in their phone settings.

Can I just hide the part that sticks out?

You can, and it is the wrong move. It makes the screenshot tidy while leaving the cause in place, and it can push real content off the edge where nobody can reach it. Find what is overflowing first.

Is this covered by what I already paid for?

It depends on your original scope, any warranty period and what changed since. A defect present at handover is a different conversation from one that appeared after a platform update or a plugin you installed. The agreement decides it, not an industry convention.

The difference between a phone and a laptop is not the problem. Stacked columns and a collapsed menu are what a narrow screen requires, and no amount of paying somebody will change that. What matters is whether anything has been lost: information that is not there, a task that cannot be finished, or text that has to be dragged across to read.

Ten minutes with your own phone and a list of the pages that earn you money will tell you which of those you have. It also turns a vague complaint into something a developer can act on in an afternoon rather than a morning of establishing basics.

If the test turns up something you would rather hand over, Arlington Website Designer builds and maintains sites for businesses around Arlington, TX, and mobile faults are usually a small, specific fix rather than the rebuild they get quoted as. Send us the page, the phone and what you were trying to do, through the contact page, and you will get back which of it is intended, which of it is broken, and what the broken part would take.