Which pages should you check first?

Choose pages tied to a clear customer action. For a service business, start with a service description and enquiry form. For a shop, choose a category, product and basket journey.

Write a short task for each page before opening your phone. Examples include finding delivery information, choosing a size or requesting an appointment. Keep the task specific enough that someone else can repeat it.

Set up a simple review sheet

• Record the page address and the task you want to complete.
• Note the phone and browser you use.
• Describe the point where you need help or become unsure.
• Attach a screenshot and write what you expected instead.
• Assign someone to check the result after the change.

Hypothetical example: a local florist wants customers to order a birthday bouquet. Test choosing a bouquet, finding the delivery area and reaching the order form. Avoid turning this first review into a discussion about the whole brand.

For that florist, I would review the product information before debating a new homepage animation. Make your own priority list equally concrete: which customer task will you inspect today?

What is mobile-first indexing, and why does it matter?

Google uses the mobile version of your content for indexing and ranking. Indexing means adding information about a page to its search index; mobile-first indexing means the mobile content is the starting point. This is explained in Google's mobile-first indexing guidance.

Open the same page on a computer and phone. Compare the substance of the page, including the service explanation and product details. Put anything missing on the review sheet.

Ask for evidence when technical checks are needed

Ask your developer to inspect how Google sees the page using URL Inspection in Search Console. Google recommends this check when investigating content visibility. Source: Google's troubleshooting guidance.

If access restrictions need investigation, include the page address in the task. Use the robots.txt setup guide as your next reading. For a separate review of your page inventory, use the XML sitemap guide.

How do you check if your site is mobile-friendly?

Try to finish a real task on a real phone. Then ask someone unfamiliar with your website to repeat it without coaching. Write down their questions instead of explaining how the website is supposed to work.

Follow the journey from arrival to action

1. Open the page directly, as a visitor arriving from search might do.
2. Find the information needed to decide whether the offer suits you.
3. Open the menu and choose another relevant page.
4. Use the main button and check its destination.
5. Fill out the form, including any dropdowns and date fields.
6. Rotate the phone and repeat the most awkward step.

Arrange test submissions with your team. Mark them clearly so they are not treated as genuine orders. Agree where to stop if the journey includes payment or a booking commitment.

Describe the failure precisely

Use wording such as: “After choosing a date, I cannot find the confirmation button.” Include the actions immediately before the problem. Ask the person making the fix to repeat those actions when handing the work back.

If your review involves a booking journey, keep the appointment booking guide alongside your notes. Decide which parts of that journey belong in this week's review and which need a separate session.

How does responsive design support mobile SEO?

Responsive design changes a page's layout to suit the screen. Google recommends this approach because it is easier to implement and maintain. It uses the same page address and HTML, the code describing the page, across devices. Source: Google's configuration guidance.

Ask to see representative pages before accepting a design update. Include a long product name, a detailed service page and a form with several fields. Review the awkward examples as carefully as the tidy demonstration page.

Check fit, reading and interaction

web.dev recommends fitting content to the available screen width and reserving space for images before they load. Its guide also explains the viewport setting, which controls how the browser sizes and scales a page. Source: responsive web design basics.

For image work, give the developer one troublesome page and the relevant photo. The image SEO guide is a useful follow-up for that separate task.

Hypothetical example: a small furniture shop has a table of dimensions. Ask a colleague to compare two chairs using only their phone. Make the acceptance test finding the measurements and returning to the product choice.

What content should remain available on mobile?

Keep the essential information equivalent across phone and computer versions. Google specifically recommends matching primary content, meaningful headings and page metadata, such as titles and descriptions. Source: Google's content and metadata guidance.

Review information before shortening the page

Compare product specifications, service scope, delivery information and contact details. Mark each item as present, missing or needing clarification. Ask the business owner to approve any proposed deletion.

For long explanations, consider expandable sections. Google suggests these as an alternative to removing content, but warns against loading primary content only after an interaction such as a click. Source: Google's content loading guidance.

Ask your developer a direct question: “Is this explanation already available in the page, or fetched only after someone opens the section?” Request a check of the answer rather than trying to judge the code yourself.

During the same review, compare the page title and description. If those need rewriting, use the meta description guide and keep that writing task separate from the layout repair.

How can you turn the findings into a weekly plan?

Give each issue an owner and an acceptance test. My suggested priority is missing essential content, blocked customer tasks, then reading and layout problems. Adjust that order when your own review provides a stronger reason.

Use a small, repeatable schedule

1. Monday: select the pages and write the customer task for each one.
2. Tuesday: run the phone checks and collect specific examples.
3. Wednesday: review the findings with your developer and agree the first fixes.
4. Thursday: repeat the original tasks after the changes.
5. Friday: accept completed work and assign the remaining issues.

Include loading problems in the same process

Ask your team to include PageSpeed Insights in the review. Request the tested page address alongside the findings. Turn each proposed change into a task rather than forwarding an unexplained report to everyone.

For layout checks, Lighthouse is another named tool to discuss with the developer. The web.dev guide describes its audit for the viewport setting. Source: viewport checking with Lighthouse. Pair the technical review with your original phone task.

Write the handover like this: “On the service page, the enquiry button becomes difficult to locate after selecting an option. Please investigate and return the page for the same test.” Keep the original screenshot until you accept the change.

Record a short list of unfinished issues rather than marking the entire website complete. After the next template or navigation change, revisit the pages you checked. Keep the task descriptions so another team member can repeat them.