Responsive themes rearrange the pages they made, not the tables, PDFs, maps and booking widgets added inside them. Test one of every kind of page on a real phone, and fix whatever needs pinching.

Responsive, except where it counts

The home page looks fine on a phone. The menu folds into a button, the photographs fit, and the text is easy to read.

Then the visitor taps through to the price list, and the page slides sideways under their thumb. They pinch, zoom, drag it back, and lose their place.

This is the usual state of a small business site on a modern theme: responsive on the pages the theme controls, broken on the pages holding the details customers came for.

Prices, menus, directions and booking. The pages closest to a decision.

The pages that usually break

The fourth costs the most, because it sits at the moment somebody has decided. A booking box that cannot be finished on a phone becomes a phone call at best, and a lost booking at worst.

Why one wide element spoils the page

A responsive theme rearranges its own layout to suit the screen. It cannot rearrange things it did not make.

Tables, documents, maps and widgets bring their own dimensions. Google's embed code for a map, for example, sets a fixed width in pixels, usually more than the 360 to 414 pixels of a phone held upright.

When one element is wider than the screen, the page either slides sideways or shrinks everything to fit, depending on the phone. Either way, the header and the menu suffer with it.

Tables that cannot shrink

A table can only get as narrow as its content allows. Six columns of prices will not fit across a phone however well the theme is written.

One fix is to change the shape: a short list per service or per size, stacked down the page.

The other is to let the table scroll sideways inside its own box while the page stays still, with the first column fixed so each row keeps its label.

The first suits most small businesses. Visitors rarely compare every cell; they are looking for their own row.

PDFs, maps and booking boxes

An embedded PDF is the least reliable of the three. On many phones it shows only its first page, a blank box or a prompt to download.

Put the content on the page as text, and offer the PDF as a download for people who want to print it.

A map can be set to fill whatever screen it is on. On a phone, an address with a directions link often does more, because it opens the phone's own map app.

Most booking systems now offer a mobile-friendly embed or a full booking page of their own. One set up years ago may predate both.

A worked example

A dog grooming salon in a row of shops on a busy road had its site rebuilt two years ago on a responsive theme. Most of it worked well on phones.

The price page was a table pasted from a spreadsheet: a row for each size of dog, and columns for bath, full groom, nails, teeth and de-shedding.

On a phone, that table pushed the page wider than the screen, and the prices shrank to a size nobody could read without zooming.

The booking page was worse. The booking system sat in a box set to a desktop width, so the calendar was cut off and the confirm button hid below the box's own scroll.

The owner found out when a regular customer mentioned at the counter that she always phoned to book, because the website never let her finish.

The table became one short list per dog size. The booking box was switched to the provider's mobile embed, with a link to its full booking page above it, and both pages were tested on two phones.

Test every kind of page, not every page

Most sites have far fewer kinds of page than pages: home, service, contact with its map, prices, booking, gallery, blog post, form, thank-you page, and any landing page used for ads.

Open one of each on a real phone, upright and then sideways. Scroll to the bottom, tap every button, and complete every form for real.

Chrome's developer tools can imitate a phone screen on a desktop. That is quick for a first look, but no substitute for a real phone.

Search Console's Mobile Usability report covers the whole site and names the faults: content wider than screen, text too small to read, clickable elements too close together.

Never switch zooming off

One tempting fix does real harm: a line of code that stops visitors zooming at all. It hides a symptom, leaves the overflow in place, and takes away the tool people with low vision rely on.

Safari on the iPhone has ignored that setting since 2016 for exactly that reason. Fix the overflow and leave zooming alone.

Why it breaks again later

The pages most likely to break are the ones added after launch, by somebody working on a desktop, pasting from a document and checking the result on the same screen.

The habit that prevents it is small: every new page is opened on a phone before it is linked from anywhere, and again after any theme, plugin or widget update.

The counter-case

Not every wide element needs rebuilding.

A detailed specification table for trade buyers may genuinely need a large screen. Those visitors are usually at a desk, and a table that scrolls inside its own box is a fair compromise.

A business whose visitors arrive mostly on office computers can fix the busiest pages now and the rest at the next redesign. A page nobody visits can wait for it too.

But the pages closest to a decision, the prices, the directions and the booking, should work on a phone without anybody pinching.

The phone test

  1. List every kind of page on the site.
  2. Open one of each on a real phone.
  3. Turn the phone sideways and check again.
  4. Complete the booking and every form for real.
  5. Read the Mobile Usability report in Search Console.
  6. Replace embedded PDFs with text on the page.
  7. Open every new page on a phone first.

Step four is the one most checks skip. A booking box can look complete on a phone and still fail at the final step, which nobody discovers by looking.

The same problem with the menu itself is covered in the mobile menu nobody can find.


Frequently asked questions

Why do some pages need zooming on a responsive site?

Because the theme only rearranges what it made. Tables, PDFs, maps and booking widgets bring their own widths, and one element wider than the screen spoils the page.

Which pages usually break on phones?

Price tables pasted from spreadsheets, embedded PDFs, fixed-width maps, booking widgets in fixed boxes, pages carried over from an old site, and landing pages built elsewhere.

How should a wide price table be fixed?

Usually by turning it into one short list per service or size, stacked down the page. Otherwise, let it scroll sideways inside its own box.

Should a menu or brochure be an embedded PDF?

No. On many phones an embedded PDF shows only its first page or nothing at all. Put the content on the page as text and offer the PDF as a download.

How do I test the site on a phone?

Open one of each kind of page on a real phone, upright and sideways, and complete every form. Search Console's Mobile Usability report covers the rest.

Can we simply stop visitors zooming in?

No. It hides a symptom, leaves the overflow in place and removes a tool people with low vision rely on. Safari on the iPhone ignores that setting anyway.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Price list that needs pinching on a phone?

Send us the web address. We will test every kind of page on real phones and list what overflows.

Start a Conversation