Start with a question, not a score

Write down the symptom in a form that a test can answer. 'My guide is missing from search' is an indexing question. 'The page takes too long to become useful on a phone' is a loading question. 'Every route shares the homepage title' is a metadata question. Running every available tool and collecting green badges makes it easy to overlook the one observation that matters. Choose the smallest test that can confirm or reject your current explanation.

For a new public route, a useful sequence is response, browser, search engine. First inspect the response that the server returns. Then load the page in a real browser and check the experience. Finally use your verified Search Console property to inspect Google's record. Save the URL and time for each observation. Results from different hosts, unpublished previews or different releases do not describe the same page, even if they look alike.

Static HTML checks: what arrived before JavaScript

LaunchForge's public scanner observes the static HTML returned for a submitted page. It can report available evidence about metadata, headings and other supported page signals. It does not run the page's JavaScript. A missing heading in an empty application shell therefore means the heading was not observed in that response; it does not establish that Google failed to render it. Limited, blocked and incomplete responses require limited conclusions.

Use this kind of check after changing a route's title, canonical or server-rendered copy. Inspect the exact before and after value, not just the score. It is also useful when social previews show defaults and you want to know whether the intended metadata arrives in the response. A whole-site audit needs additional crawling and comparisons across URLs. One successful page check cannot establish that every route is correct.

Lighthouse: a controlled browser audit

Lighthouse opens a page in a browser and runs automated audits for performance, accessibility, best practices and SEO. The resulting report is useful for diagnosing a specific run. The mobile profile simulates constrained conditions; desktop uses a different profile. Record which profile, browser version and page build produced the numbers so future comparisons mean something. A production page with third-party requests may behave differently from a clean local preview.

Follow the report to the actual issue. If a large image delays the main content, inspect its request, dimensions and loading priority. If text is hard to read, inspect contrast and size. If a navigation control has no accessible name, fix the control. A higher score is the result of useful repairs, but it does not measure whether a page answers its target query better than competing pages. A perfect audit can still describe content that nobody needs.

Search Console: Google's record and current access test

URL Inspection gives a verified site owner information about an indexed URL and a separate live test. The indexed record and live test refer to different moments and answer different questions. A live test that succeeds does not guarantee indexing. A page in a sitemap is merely listed for discovery. When a result is absent, write down the exact reported status and the crawl date before changing code.

For example, a discovered URL that has not yet been indexed calls for a review of discovery, availability and the page's value. A noindex exclusion calls for checking whether that instruction is intentional. A different selected canonical calls for examining duplicate versions and conflicting signals. These situations should not all trigger the same framework migration or metadata rewrite. Our Search Console status guide provides a practical next-check map without claiming the scanner can see Google's internal decision.

Worked case: Lighthouse passes but the HTML lacks the article

Imagine a fictional guide whose layout renders on the server but whose article text is fetched in a browser effect. A visitor eventually sees the article and Lighthouse can inspect that rendered state. A static response check sees the heading skeleton and no article body. Those results can both be accurate. Confirm the difference by searching the initial response for a unique sentence from the article, then looking for that same sentence in the rendered page.

If the article is intended for public discovery, move the required content into the route's server data flow or generate it at build time. Keep the existing framework when it supports that path. Publish, fetch the deep URL directly and repeat the sentence check. Then check browser navigation still works. This example fixes an observed dependency on client rendering; it does not establish that the earlier page was unindexable or that the new page will rank first.

Worked case: the scan passes but a phone feels slow

A page can contain a title, canonical and useful copy while still loading a large script bundle or shifting content as images arrive. A static HTML checker has not measured those experiences. Use a mobile Lighthouse trace to investigate loading and layout behavior, then test the main interaction on a real or realistically emulated phone. Reserve image dimensions, load only needed code and check that buttons remain responsive during work.

A lab run is a diagnostic snapshot. Real-user performance depends on devices, networks, cached resources and actual interactions. In particular, do not label a Lighthouse total blocking time value as measured Interaction to Next Paint. Track field Core Web Vitals when enough real usage exists, and describe missing field data as unavailable. A new low-traffic proof of concept may have no representative field report yet; that is not a passing result.

A release checklist you can repeat

Choose representative routes: home, a content page, a tool and a missing URL. Record status codes and confirm useful text in the raw HTML. Check one canonical and one clear H1 on each public page. Run mobile and desktop audits on the same build, inspect failures, and test keyboard access to the main action. Verify that an unknown route returns an actual 404 rather than a successful homepage response.

After publication, repeat the response checks on the public hostname and submit changed canonical pages through your search-engine tools. Keep a weekly record of impressions, indexed pages, useful queries and completed tool actions. Separate owner testing from acquired visitors. If four weeks of data shows impressions for a specific repair question, improve that answer using observed needs. If there are no impressions, review indexing and discovery before multiplying near-identical landing pages.

Sources and further reading

Choose your next check

LaunchForge website SEO checker helps you review the evidence before you change your site.