Checks to run before you request indexing

Request indexing after the live URL is the page you want Google to keep. A public scanner such as SEO Optimizer can read HTML, response headers, robots.txt, the sitemap, and a lab performance run. It cannot see owner-only Search Console data, and a clean report is not a ranking promise. The checks below follow published Google Search Central and web.dev guidance.

Give every page a distinct title

Google's guide, Influencing your title links in search results, says every page needs a title element, and that the text should be descriptive and concise. Skip vague labels such as "Home", titles that repeat the same boilerplate, and titles that stuff the same words in over and over. Google builds the title link from the title element, the visible heading, large on-page text, og:title, anchor text, and other page text. It can replace a title that is incomplete, out of date, or a poor match for the page.

That same guide says there is no limit on how long a title element can be. The title link is truncated to fit the device width. Write a short title that says what this URL is about, and make the visible heading agree with it. Google has to recrawl the page before a title change can show in results, which the guide says may take a few days to a few weeks.

Write a description only the snippet might use

Control your snippets in search results says Google creates snippets from the page content, and that it sometimes uses the meta description when that text describes the page more accurately than the copy on the page. The same description on every URL does not help someone who sees several of your pages at once. Write a unique summary for the pages you care about, especially the home page and other URLs people actually search for.

The guide also says there is no length limit on a meta description. The snippet is truncated to fit the device. It does not describe the meta description as a control for where the page ranks. If you need to hide a snippet or cap its length, the same document covers nosnippet, max-snippet, and data-nosnippet.

Point duplicates at one canonical URL

When the same content is available at more than one URL, How to specify a canonical URL with rel="canonical" and other methods lists the signals Google uses, from stronger to weaker: redirects, a rel="canonical" link, then inclusion in a sitemap. Using more than one of those signals, without contradicting them, raises the chance that your preferred URL is the one in search results. None of them is required. If you do not choose, Google picks the version it considers best.

• Put an absolute rel="canonical" link in the head. The guide recommends a self-referential canonical on the preferred page itself, and it recommends absolute URLs rather than relative ones.
• Keep the canonical, the sitemap, and internal links on the same URL. The guide says not to declare one URL in the sitemap and a different URL in rel="canonical".
• Do not use robots.txt or the URL removal tool to choose a canonical. The guide also says noindex is a poor way to pick a preferred URL, because noindex removes the page from Search.
• Prefer the HTTPS URL. Google prefers HTTPS over the same page on HTTP unless the certificate is invalid, the page loads insecure resources other than images, the HTTPS page redirects to or through an HTTP page, or the canonical points at the HTTP page.

List only the URLs you want crawled

Build and submit a sitemap says an XML sitemap should list the canonical URLs you want in search results, using fully qualified absolute URLs in a UTF-8 file. A single sitemap is limited to 50 MB uncompressed or 50,000 URLs. Google ignores changefreq and priority. It uses lastmod only when that timestamp is consistently and verifiably accurate, and lastmod should mark a real change to the content, the structured data, or the links, not a copyright-year edit.

Submitting the sitemap is a hint. The guide says it does not guarantee that Google will download the file or crawl every URL in it. Add a Sitemap line to robots.txt and submit that same URL in Search Console so you can see whether Google could process it. Leave out redirects, error URLs, noindex URLs, and duplicate variants.

Make the page crawlable, then link to it

Link best practices for Google says Google generally crawls a link when it is an a element with an href that resolves to a real URL. Click handlers, routerLink attributes, and javascript: URLs are not a reliable substitute. Anchor text should describe the destination. The guide says every page you care about should have a link from at least one other page on the site, and that there is no ideal number of links on a page.

If a URL should stay out of the index, use noindex. Influencing your title links in search results notes that robots.txt can stop Google from crawling a page and still fail to keep that URL out of the index when another site links to it. Without the page content, Google may build the title link from off-page text such as anchor text.

Read field Core Web Vitals separately from lab scores

Philip Walton's Web Vitals article on web.dev, last updated October 31, 2024, defines a good experience as an LCP within 2.5 seconds, an INP of 200 milliseconds or less, and a CLS of 0.1 or less. It says to judge those targets at the 75th percentile of page loads, split between mobile and desktop. The Chrome UX Report, PageSpeed Insights field data, and the Search Console Core Web Vitals report are the field sources named there.

Understanding Core Web Vitals and Google search results tells site owners to strive for an LCP in the first 2.5 seconds, an INP under 200 milliseconds, and a CLS under 0.1. It says good Core Web Vitals, together with other page-experience aspects, align with what Google's core ranking systems seek to reward. That is a recommendation about user experience, not a promise that a faster page outranks a more useful one.

A Lighthouse run, including the lab scores in a public scan, is still useful while you are editing. web.dev notes that Lighthouse cannot measure INP, because a lab load has no user input, and that Total Blocking Time is the lab proxy. Use the lab run to find a regression. Use Search Console field data to decide whether real visits meet the thresholds.

Match structured data to the visible page

Introduction to structured data markup in Google Search recommends JSON-LD when your setup allows it, because it is easier to maintain than markup mixed into the HTML. The structured data has to describe that page. Do not add a JSON-LD block for content a visitor cannot see.

General structured data guidelines says markup must be a true representation of the page content, and it says not to mark up content that readers of the page cannot see. The same page says Google does not guarantee a rich result even when the Rich Results Test passes: "Using structured data enables a feature to be present, it does not guarantee that it will be present." Check the live URL with the Rich Results Test, then confirm Search Console has seen the markup with URL Inspection.

Request indexing only for the finished canonical URL

Work through the list on the exact URL you want in search results, after it returns a successful HTTP status. The title element, the visible heading, the canonical, and the sitemap entry should name that same URL. The page should not be noindex, and another page on the site should link to it with an ordinary href.

• Fetch the final URL and confirm it is HTTPS, returns successfully, and is the canonical you listed in the sitemap.
• Read the rendered HTML, not only the raw template, if the title, canonical, or main text is added by JavaScript. How to specify a canonical URL with rel="canonical" and other methods says the clearest canonical is the one in the HTML source, left unchanged by script.
• Compare a lab performance run with the field Core Web Vitals report before you treat speed as finished.
• Use Search Console URL Inspection on that canonical URL when you want Google to recrawl it. Influencing your title links in search results says updated titles still wait on recrawling, which can take a few days to a few weeks.

Then read the page as a visitor. Google's guide, Creating helpful, reliable, people-first content, defines people-first content as content created primarily for people, and not to manipulate search engine rankings. A crawlable, fast URL still has to be the page someone needed. SEO Optimizer can show the public technical signals. Search Console remains the place for indexing, queries, and field Core Web Vitals on a property you verified.