Choose the page's job before choosing its title
A useful title tells a visitor which problem this page solves. Start by writing a plain sentence about the page, not a list of keywords. A tool lets someone do something; a comparison helps them choose; a guide explains a procedure. If the title promises a free checker, the page needs a working check and a clear explanation of its scope. If it promises a guide, the first screen should make the procedure easy to find.
Give each distinct public page its own title and description. Changing only the city, year or product name while repeating the same body creates weak pages, even if every metadata check passes. Before adding another route, ask what decision a visitor can make there that they cannot make on your existing page. This tool checks the supplied head; it cannot judge the originality or usefulness of the page's answer.
What the free checker reads
Paste the complete published HTML, including the head. The checker lists title elements, description metadata and common Open Graph and Twitter card fields. Each result shows the supplied value, the number of characters and any duplicate declarations observed. Missing fields are described as missing from this sample rather than asserted to be missing everywhere. A rendered browser copy and an initial server response may contain different values.
The parser runs in your browser after you press the button. It treats the input as data, does not execute scripts and does not load image URLs found inside the sample. The text is neither uploaded nor saved by this tool. The result is a metadata inventory, not a Google preview or a ranking score. It cannot check whether a remote image exists or whether a social platform has cached an older version.
Use length targets as editing aids
This project uses 60 characters for titles and 155 for descriptions as practical editorial targets. These are not Google limits. Search results have different layouts, and the displayed text may be shortened or rewritten. A short title can still be vague; a longer title can still be appropriate. Read the words aloud and check whether the main topic remains clear if the brand or final phrase is not visible.
For a fictional bicycle workshop, 'Home' provides little context. 'Bicycle puncture repairs | Example Workshop' is more informative if that is what the page offers. A useful description could explain booking, what to bring and the next step. Do not invent turnaround times, prices or locations just to make a snippet attractive. A visitor should be able to verify every specific promise in the page body.
Separate search text from social previews
The title element and meta description describe the page for search and other consumers. Open Graph fields describe a shared link for clients that support the protocol. Twitter card fields provide a similar presentation contract for supporting clients. Keep the topic and destination consistent across them, but do not assume that a complete social card guarantees a Google ranking improvement. A link preview and an organic search result are different outputs.
Use a real share image that matches the page, an absolute HTTPS image URL and readable text at small sizes. For this site's cards, the design target is 1200 by 630 pixels. Test the image directly and check its response type, dimensions and cache policy. A pasted og:image value alone proves none of those things. Avoid embedding private project names or user data in a share image for a public page.
Repair metadata where the server creates the head
On this TanStack Start codebase, public route metadata is declared through the route head function and a shared inventory. That makes it available during server rendering. For another website, first identify its framework and hosting behavior before copying a fix. A legacy client-rendered project and a current server-rendered project can need different verification steps. Do not add a second metadata library until you know who already owns the tags.
Look for conflicts between the root layout, individual route and any effects that run after the page loads. If a shared default survives beside the page-specific value, remove the redundant source. Then publish and inspect the actual response for home and two deep pages. Testing only a client-side navigation can hide a broken direct request. Testing only the homepage can hide repeated defaults on every inner route.
A repeatable before-and-after record
Capture the exact URL, response date and current title before editing. Record one intended improvement, such as replacing a generic title with the page's real task. Make the change, publish it and obtain a fresh response from the same URL. Run that sample through this checker and compare values. Keep the change small enough that another person can explain what improved without reading your entire chat history.
Next, inspect a neighboring route that shares the layout. Its title should remain specific to that route. Open the page at a narrow viewport and confirm the visible H1 still agrees with the title's promise. Follow the main action and check that it delivers what the description says. These are practical quality checks that a tag-counting tool cannot perform. They also catch copy that is technically valid but misleading.
When Google shows different words
A changed source tag does not mean the search result updates immediately or uses your exact wording. Google can create title links from several page signals and generate snippets that match a query. First distinguish an old crawl from a deliberate alternate display. Use Search Console to inspect the URL and compare crawl dates, then examine the current page's visible title, body and metadata for conflicting descriptions.
If the page is not indexed, repeatedly rewriting the meta description is rarely an evidence-led first move. Check the reported indexing status, response code, crawl controls and canonical destination. If it is indexed but receives few clicks, compare actual queries and impressions before changing the promise. Keep a dated change log and allow enough observations to avoid reacting to one unusual day. The goal is a clear, useful page that matches the searcher's task.
Sources and further reading
Choose your next check
LaunchForge website SEO checker helps you review the evidence before you change your site.