Technical SEO in Four Questions: Can Google Find, Understand, Index and Rank Your Pages?

Why I use four questions

When someone tells me "Google is not showing our page", the cause is rarely one of the hundreds of items in a typical audit tool. It is almost always at one specific stage of a pipeline, and the fix depends on which stage. So before I look at anything else I ask where the page is stuck.

Google describes Search as three stages: crawling (finding and downloading pages), indexing (analysing and storing them) and serving (returning results for a query). Rendering, the step where Google runs your JavaScript to see the finished page, happens during crawling and feeds into indexing. I split that pipeline into four questions because it matches how problems actually show up on sites:

Two of these questions get most of the attention, indexing and ranking, because those are what people can see. In my experience the early questions hide more problems than people expect, which is why I never skip them. The same order sits behind the longer diagnosis in why important pages are not getting indexed.

Question 1: Can Google find your pages?

Google has no central list of web pages. It learns about URLs by revisiting pages it already knows, following links from them, and reading sitemaps you submit. Anything that stops one of those routes from working is a discovery problem.

What I check

• Internal links. Every page that should rank needs at least one normal link to it from another crawlable page. Google can reliably follow links that are <a> elements with an href. A menu built from click handlers or buttons may look identical to a visitor and offer a crawler nothing to follow. The Internal Link Analyzer shows orphan pages and click depth for up to 100 pages.
• The XML sitemap. A sitemap helps Google find URLs, but Google calls submitting one a hint, not a guarantee. It ignores the priority and changefreq values entirely, and uses lastmod only if your dates are reliably accurate. List the canonical URLs you want indexed, and keep each file under 50 MB uncompressed or 50,000 URLs. The XML Sitemap Validator catches dead, redirected and duplicate entries.
• robots.txt. This file tells crawlers which URLs they may fetch. A stray Disallow can hide a whole section. The Robots.txt Tester shows the exact rule that decides for a given URL. I cover what robots.txt cannot do in a separate guide.
• Server health. Google says that if your site slows down or returns server errors (5xx) or rate-limiting responses (429), it crawls less. The Crawl Stats report shows response codes and host status over time.
• Redirects. Long chains slow crawling, and a redirect to the wrong place sends signals to the wrong page. The details are in the guide to 301, 302, 307 and 308 redirects.

A word on crawl budget

Crawl budget worries get far more airtime than they deserve. Google's own guide says it is aimed at very large sites, roughly a million or more unique pages that change about weekly, or 10,000 or more that change daily, and adds that these are not exact thresholds. For a normal business site, the question is almost never "is Google crawling too little" but "are my important pages linked and reachable". I would fix internal linking long before I touched crawl budget.

Question 2: Can Google understand your pages?

Finding a URL is not enough. Google fetches the HTML, then renders the page, running its JavaScript in a browser-like environment, and indexes what the rendered page contains. If the content, links or tags you care about are not in that rendered result, Google has not seen them.

What I check

• The rendered HTML. In the URL Inspection tool, run a live test and compare the rendered HTML with what you see in your browser. This is the single most useful check for script-heavy sites, and I go deeper in the JavaScript SEO guide.
• Content that needs a user action. Google's mobile-first indexing guidance says it will not load content that requires user interactions, and that primary content should not be lazy-loaded on interaction. Content that appears only after a click or a scroll gesture is a risk.
• Blocked resources. If robots.txt stops Google fetching scripts or styles a page needs to render properly, Google may see a different page from your visitors. Block crawling of low-value paths, not the files your layout depends on.
• The mobile version. Google uses the mobile version of a page for indexing. If your mobile layout drops content, headings or structured data that the desktop version has, the dropped parts are not indexed. The robots meta tags should also match across versions.
• Plain signals. A descriptive title, one clear main heading, a sensible heading order, meaningful link text and alt text on informative images all help Google work out what a page is about. The Meta Tag Checker and Heading Checker cover these on a single URL.
• Structured data. Markup can help Google understand a page and may make it eligible for rich results, but it never guarantees them. Google's guidelines require that markup describes content visitors can actually see on the page. The Schema Markup Validator checks syntax and Google's rules.

Question 3: Can Google index your pages?

Indexing is where Google decides whether to store a page and which URL represents it. Google states plainly that indexing is not guaranteed: not every page it processes will be indexed. So this question has two halves, whether anything is actively blocking indexing and whether Google sees a reason to keep the page.

Things that actively block or redirect indexing

• A noindex rule. A noindex meta tag or X-Robots-Tag header tells Google to drop the page. For Google to see it, the page must not be blocked in robots.txt, which is the reason "robots.txt plus noindex" does not work. If a page is blocked, Google never reads the noindex and the URL can still appear in results.
• Canonical signals. When several URLs show the same content, Google groups them and picks one canonical. Your rel="canonical" tag, redirects, sitemap entries and internal links are all signals, and Google may choose differently from your tag. If the wrong URL is chosen, the page you wanted can be reported as a duplicate.
• Soft 404s. A page that says "not found" but returns a 200 status is treated as a soft 404, and Google warns these keep being crawled and waste budget. Return a real 404 or 410 for removed pages.
• Errors and redirects. A page returning a 5xx or redirecting elsewhere will not be indexed under its own URL.

Pages Google chooses not to keep

The two statuses people ask about most are "Discovered, currently not indexed" (Google knows the URL but has not crawled it yet) and "Crawled, currently not indexed" (Google fetched it and decided not to index it for now). Neither is a technical error with a one-line fix. They are a prompt to ask whether the page is reachable, adds anything the site does not already say, and is linked from places that show it matters. I go through each status in the indexing guide.

How I verify

I use the Page indexing report for patterns across a site and the URL Inspection tool for one URL at a time. I do not treat a site: search as evidence of how many pages are indexed, because it is a rough view and not a report. A long error list from a crawler is not a diagnosis either; the 12 issues that matter explains how I decide which items to act on first.

Question 4: Can your pages rank?

If a page is found, understood and indexed, the remaining question is whether Google's ranking systems consider it a good result for a query. This is the stage where technical SEO matters least and is most often over-credited, so I try to be careful about what I claim.

What technical work can and cannot do here

Relevance and quality are mostly about the content: whether it answers the query better than the alternatives, comes from a source people can trust and was written for readers rather than for search engines. Google's guidance on helpful content describes what its systems aim to reward. Technical work can stop a good page from being undermined, but it cannot turn a weak page into a strong one.

Page experience: what Google actually says

Google says there is no single page experience signal. Its core ranking systems look at a variety of signals that align with page experience, and Core Web Vitals are used by those ranking systems. The targets, measured at the 75th percentile of real page loads, are:

INP replaced First Input Delay as a Core Web Vital in March 2024, so any guide that still lists FID is out of date. Google also cautions that good scores do not guarantee top rankings. You can test your own pages with the Core Web Vitals Checker.

The same Google page notes that other page experience aspects, including HTTPS and mobile-friendliness, do not directly help a site rank higher, although Google still recommends them because they make a site better to use. I would put it this way: HTTPS and a mobile-friendly layout are the price of entry for users and for the previous questions, not a ranking lever to chase. Mobile layout in particular matters because, as covered above, the mobile version is what Google indexes.

Which question to start with

You do not have to walk through all four on every problem. The symptom usually points at the right place.

If you would rather have the whole picture first, a technical audit runs all four questions across your templates, and a good audit report turns the findings into an ordered plan.

How I work through this

When I review a site I always go in order and I always test templates, not just single pages. I pick one URL for each page type, such as a service page, an article, a category and a product, and run the four questions on each. A fault in a template appears on every page that uses it, so one sample usually reveals a pattern that a single page would not.

I write down what I find before changing anything, because Search Console reports lag and you need a record to measure against. I also try not to fix a later question while an earlier one is open. If a page is noindexed, a faster server will not help. The same discipline sits behind my technical SEO work, and the platform you build on shapes where the traps are, which I cover in the guide to Shopify, WordPress and Webflow. For online stores, the ecommerce guide applies these questions to category and product pages.

If you are learning this yourself, the technical SEO days of my Advanced SEO course cover robots.txt, sitemaps, canonicals, redirects, JavaScript SEO and indexing issues.

Frequently asked questions

What is technical SEO?

It is the work that makes sure search engines can crawl, render and index your pages and that visitors get a fast, usable experience. It covers site structure, links, robots rules, redirects, canonicals, rendering, structured data and performance.

Is "Discover" in your four questions the Google Discover feed?

No. Google Discover is a separate feed with its own policies. In this framework, finding a page means Google learning that its URL exists, through links, sitemaps and pages it already knows.

Does submitting a sitemap guarantee my pages get indexed?

No. Google calls a sitemap a hint. It can help Google find URLs, but whether a page is crawled and indexed depends on many other signals, and indexing is never guaranteed.

Do I need to worry about crawl budget?

Usually not. Google's guide is aimed at very large sites, roughly a million or more unique pages that change weekly, or 10,000 or more that change daily, and it says those are not exact thresholds. For most sites, internal links and indexability matter much more.

Does HTTPS or a mobile-friendly design improve my ranking?

Google says those aspects do not directly help a site rank higher, but it still recommends both because they make a site better for people. Mobile also matters for indexing, since Google indexes the mobile version of your pages.

Where should I start if my page is not in Google?

Paste the URL into the URL Inspection tool. It tells you whether the page is indexed, which canonical Google chose and, with a live test, how Google renders the page. That answer tells you which of the four questions to work on.

How often should I run these checks?

I run the full set before and after any release that touches templates, navigation, URLs or robots rules, and look at the Page indexing and Crawl Stats reports regularly in between. Search Console data lags, so a baseline before the change is what makes the results readable.

Sources and further reading

Statements about Google in this guide are based on the pages below, checked on 24 October 2026. Platform behaviour changes, so confirm details in the original documentation before you act on them.

1. In-depth guide to how Google Search works: crawling, indexing and serving; URL discovery; rendering; canonicals; indexing is not guaranteed
2. Google Search Essentials: technical requirements, spam policies and key best practices
3. Build and submit a sitemap: a sitemap is a hint; priority and changefreq are ignored; lastmod and size limits
4. Managing crawl budget for large sites: who needs to worry about crawl budget; 5xx, 429, soft 404s and redirect chains
5. Make your links crawlable: a elements with an href
6. Introduction to robots.txt: robots.txt controls crawling and is not a way to keep a page out of Google
7. JavaScript SEO basics: crawling, rendering and indexing of JavaScript pages
8. Mobile-first indexing best practices: the mobile version is used for indexing; content and robots parity
9. Block Search indexing with noindex: noindex needs a crawlable page
10. How to specify a canonical URL: canonicals are signals, not commands
11. General structured data guidelines: markup must match visible content
12. Page indexing report: status names and what they mean
13. URL Inspection tool: indexed version, live test and rendered HTML
14. Crawl Stats report: requests, response codes and host status
15. Understanding page experience in Google Search results: what page experience does and does not do for ranking
16. Web Vitals: LCP, INP and CLS thresholds measured at the 75th percentile
17. Creating helpful, reliable, people-first content: what ranking systems aim to reward