Guide CMS publishing · 6 of 9
How to Review a Blog Post on Mobile Before You Publish
Run a 10-minute mobile review of one blog post: preview options, what to check from title to embeds, a worked example, and a re-check on the live URL.
Key takeaways
- Use a real phone for the final check when you can.
- Check title, cover, tables, long URLs, buttons, and embeds.
- Re-check the live URL after publishing.
To review a blog post on mobile before you publish, open its preview on a narrow screen and check it from top to bottom. Look at the title, the cover image, the first screen, tables, long links, buttons, and embeds. The whole check takes about 10 minutes and catches problems that a desktop preview hides.
This is a release check for one post, not a guide to responsive design. If your whole theme breaks on phones, that is a separate project. For the full release process, see the blog publishing guide.
Why a post that looks fine on desktop can fail on a phone
A desktop screen hides many layout problems. A wide table fits. A long title stays on two lines. A cover image shows the whole subject. On a phone, the same elements can overflow, crop, or push the content far down the page.
Many readers will open your post on a phone. Google also uses the mobile version of a page for indexing and ranking, as its mobile-first indexing guide explains. A post that works on phones is the version that counts.
Three ways to preview
| Method | How | Best for |
|---|---|---|
| Editor device preview | In the block editor, use the preview options to switch to Mobile | A quick first look while editing |
| Browser device mode | Open the preview, then use Chrome DevTools device mode | Testing several screen widths |
| Real phone | Open the preview link on your phone while logged in | The most realistic check |
The editor preview is a rough guide. Chrome’s device mode simulates phone screens in your desktop browser, but it still runs on your computer. Use the real phone for the final check whenever you can.
A draft preview usually needs you to be logged in. If you cannot sign in on your phone, check again on the live URL right after publishing.
What to check, top to bottom
| Element | Common failure | Fix |
|---|---|---|
| Title | Wraps to five or more lines | Shorten the title |
| Cover image | Crops off the main subject or the text in it | Use a cover with a centered subject and no small text |
| First screen | Shows only the cover, ads, or a banner | Trim what comes before the first paragraph |
| Tables | Cut off or force sideways scrolling | Reduce columns or split into two tables |
| Long URLs | Run past the screen edge | Link a short phrase instead of pasting the URL |
| Buttons | Too small to tap, or two buttons too close | Use one clear button with space around it |
| Embeds | Wider than the screen, or no space reserved | Use the Embed block and check the live size |
| Image credits | Caption text runs into the next block | Keep credits short and in the caption field |
For video players, the video embed guide covers sizing and playback checks. For credits, the image attribution guide shows where they belong. If content jumps as images or embeds load, that is a layout shift; see how to fix layout shifts caused by images and embeds.
Worked example: a wide table and a cropped cover
Fictional example. An imaginary coffee equipment blog prepares a post comparing grinders. The phone preview shows two problems.
| Element | Failure on phone | Fix |
|---|---|---|
| Comparison table | Six columns; only three visible without scrolling | Kept four columns that matter most; moved price notes to a short list |
| Cover image | Grinder cut in half by the crop | Replaced with a centered photo |
The text did not change. Two edits made the post readable on a phone. The team reran the check, and both items passed.
If the draft came from a doc, tables are often where problems start. The Google Docs to WordPress guide shows how to rebuild them cleanly.
Fix the post, not the device
When something fails on a phone, fix it in the post where you can. Shorter titles, fewer table columns, and clear images work on every screen. Avoid hiding blocks on mobile or adding device-only styles to one post. Those fixes are easy to forget and hard to maintain.
Some problems are not in the post at all. If every post has a cramped header, oversized ads, or a menu that covers the text, that is a theme issue. Note it and raise it with whoever manages the site. Do not try to fix it inside a single article.
Who should run the check
Give the mobile check to the person who publishes, not the writer. The writer knows the text too well and tends to read what they meant, not what is on screen. A second person sees the layout fresh.
Keep the check short and the same every time. Use the table above as a printed or shared list, tick each row, and note any fixes. Over a few weeks, the list shows which problems repeat. Repeated table failures, for example, may mean your writers need a simple rule such as “four columns at most.”
How long the check should take
For a typical post, plan on about 10 minutes. Spend two minutes on the first screen, five on the body, and three on fixes and a reload. A post with several tables or embeds may take longer. If the check regularly runs past 20 minutes, the problems are probably in the template, not the posts.
Re-check after publishing
The preview and the live page can differ. Caching, plugins, and theme scripts may load only on the public URL. After you publish, or after a scheduled post goes live, open the public URL on your phone in a private tab. Run the same top-to-bottom check.
If the scheduled time passed and the post is not there at all, the problem is not layout. Use the missed schedule guide instead.
Where DEX fits
DEX publishes approved articles through the connected CMS and checks the live page. Its Health page check reviews one URL for on-page and technical issues. A phone check by a person is still the fastest way to catch a cropped cover or a table that does not fit.
Mobile review checklist
- Open the preview on a real phone, or in device mode if you cannot.
- Check the title, cover, and first screen.
- Check tables, long URLs, buttons, and embeds.
- Fix each failure, then reload and check again.
- After release, repeat the check on the live URL.
FAQ
Is the editor's mobile preview enough?
+
It is a good first look, but a real phone is more reliable.
What breaks most often on phones?
+
Wide tables, cropped cover images, and long URLs.
Why check again after publishing?
+
Caching, plugins, and theme scripts can change the live page.
Sources
- Simulate mobile devices with device mode · Chrome for Developers
- Mobile-first indexing best practices · Google
Dex SEO is an AI SEO agent for small businesses. Every article here is planned from search data, drafted by Dex, fact-checked against the sources it cites, and reviewed by the team before it is published.
How this article was made: planned and drafted by Dex from search data, fact-checked by Dex (2 claims checked), then approved by the Dex SEO team.