Verify a changed small business homepage from the customer’s path, not only from the editor preview. The page should load at the public URL, identify the business accurately, make the main action usable, work on small screens and keyboards, remain crawlable, and produce the expected measurement signal. Keep a rollback copy until those checks pass.
Confirm the live page and business identity
Open the canonical HTTPS address in a private browser window and on a phone using a different connection if practical. Confirm that the final URL, certificate, status, page title, favicon, business name, contact details, hours, service area, and legal footer are correct. Check both the bare domain and the `www` form if both exist; they should resolve consistently rather than show different homepages.
Compare the live page with the approved change. Look for stale cache content, missing styles, broken images, placeholder text, private notes, and incorrect environment banners. Test navigation links, phone and email links, maps, appointment or quote buttons, forms, confirmation messages, and error messages. Submit forms only with authorized test data and confirm where the message goes.
Test the primary customer journey
State the homepage’s main job in one sentence, such as requesting a quote, calling the shop, booking a service, or visiting a product category. Starting from the first screen, complete that action on desktop and mobile. Check that menus open, focus is visible, buttons are not covered by banners, and the action remains understandable without relying on color alone.
The W3C Web Accessibility Initiative’s Easy Checks cover page title, image text alternatives, headings, contrast, text resizing, keyboard access, visible focus, forms, labels, errors, and basic structure. W3C also warns that these preliminary checks are not a complete accessibility evaluation, so record them as a first review rather than a conformance claim.
Test at a narrow width and with text enlarged. Navigate using only Tab, Shift+Tab, Enter, Space, and Escape. Confirm that every interactive control can be reached in a sensible order and that a keyboard user can dismiss menus or dialogs. If the page contains motion, video, or changing content, verify that controls do not trap or distract the visitor.
Verify search-facing signals
View the rendered source or inspection output and confirm the intended title, meta description, canonical URL, robots directive, main heading, organization details, and structured data. Make sure the canonical points to the public preferred URL and that no staging-domain or `noindex` instruction leaked into production.
Google’s website debugging guide says the URL Inspection tool can show how a page appears in Google’s index, run a live URL test, show rendering, and submit the URL for indexing. Use the live test after the public deployment, then save the result or issue details. Indexing is not immediate and a request is not a ranking guarantee.
Check performance, analytics, and rollback
Load the page once without browser extensions and watch for visibly delayed content or layout jumps. Check the browser console and network panel for failed essential requests. Verify that analytics or consent behavior matches the approved privacy design; do not create tracking solely to pass this test. Use a labeled test conversion if the business has an authorized analytics flow, then exclude it from organic reporting where possible.
Record the release identifier, timestamp, tested devices, results, and unresolved limitations. A homepage change passes when the live customer journey, accessibility basics, search signals, and measurement path agree. If a critical action fails, restore the known-good version and investigate off-line instead of leaving a partially working homepage public.
Sources
- Easy Checks - A First Review of Web Accessibility — W3C Web Accessibility Initiative
- Debug Your Website Pages — Google Search Central