Google Search uses automated systems to discover and crawl pages, process their information into an index, and then select and order relevant results from that index for each search query. That one sentence is the whole model. Everything people argue about when they talk about "the Google algorithm" is really a debate about one small piece of this larger process.
Here's the thing most explanations skip. "The algorithm" is not one formula that runs on every website and spits out a score. Google itself describes multiple automated ranking systems working inside a bigger search process, and its own high-level stages are crawling, indexing, and serving search results. Ranking is part of serving results. It is not a stand-in word for everything Google does to a page.
Before anyone searches for anything, Google has to discover web addresses, fetch the pages it can reach, render what those pages show, and try to understand and store the useful parts. When someone actually types a search, Google interprets what they're asking, looks for matches already sitting in its index, and runs its ranking systems to pick and order the results. None of the earlier steps guarantee a page shows up for a particular search, or shows up high on the page, or shows up at all.
If you've ever typed how does Google rank websites into a search bar, or sat with a colleague wondering how does Google ranking algorithm work, the short answer is that Google mostly doesn't rank websites at all. It ranks pages, for specific searches, using information it already collected ahead of time. That distinction is the one most marketing conversations skip past, and it's the one this piece, a Google search algorithm explained at the process level rather than the factor level, is built around.
What is Google's search ranking algorithm?
Google's own published model names three stages: crawling, indexing, and serving search results. Ranking lives inside that third stage. It is the part where Google's systems select and order the pages it already has in its index for one specific search.
A useful way to teach this, expanding on Google's own overview, is: discover, then crawl and render, then analyze and index, then understand the query, then find matches, then rank and present results. That's a teaching breakdown built on what Google has published, not a leaked blueprint or a claim that Google runs exactly six separate systems with these names. Treat it as a map, not an engineering diagram.
Two different jobs are happening here, and keeping them apart clears up a lot of confusion. One job is building and refreshing the searchable collection: discovering addresses, crawling them, rendering what they show, and indexing the result. The other job is answering one particular request: understanding a query, finding what matches it, and deciding what order to show it in. The first job runs continuously in the background. The second runs every time someone searches.
Google also ranks pages, not whole sites, as the main unit. It does use site-wide signals and classifiers to help understand individual pages, so the rest of a site isn't irrelevant. But a strong page on a weak site and a weak page on a strong site are both real possibilities, and Google is explicit that favorable site-wide signals don't mean every page on that site will rank well, and the reverse is also true.
Here's the part worth sitting with: Google does not guarantee that it will crawl, index, or serve any given page, even one that follows every piece of guidance Google publishes. That isn't a disclaimer buried in fine print. It's close to the center of how the whole system works, and it's why "we did everything right and still didn't rank" is a sentence that can be true. It's also the honest answer to how does Google rank websites: not by website at all, but page by page, search by search.
How does Google discover and crawl pages?
Crawling is Google fetching content from an address it already knows about. Discovery is the earlier, separate step of learning that address exists in the first place.
There's no master directory listing every page on the internet. Google has to keep finding new and changed pages on its own, and it does that through a few routes: addresses it already knows from earlier visits, links from pages it has already found, and sitemaps that site owners submit to help it along. A submitted sitemap can make discovery faster and more efficient, but it doesn't force Google to crawl or index anything on the list. It's a hint, not an instruction.
The program doing the actual fetching is Googlebot, what most people mean by "crawler," "bot," or "spider." Googlebot runs its own algorithmic process to decide which sites to visit, how often to come back, and how many pages to pull on any given pass, while trying not to overload the servers it's hitting. It does not visit every known address, does not revisit every page on a fixed schedule, and does not fetch new content the moment it's published. If you're waiting for a new page to show up and nothing has happened yet, that alone tells you very little.
Access has to come before anything else can matter. If a page is blocked from crawling, or sits behind a login, Googlebot can't see it no matter how good the content is, and a page that opens fine for a logged-in employee isn't necessarily one Googlebot can open at all. A working page returns the HTTP success status, 200, which establishes basic technical eligibility. That's a floor, not a ranking signal, and clearing it tells you nothing about whether the page gets indexed or chosen for anything.
Rendering is the piece that trips people up most. It means Google processes a page roughly the way a browser does, including running JavaScript that might bring content onto the page after the initial load. Google says it renders pages and runs JavaScript using a recent version of Chrome, which matters because a page that relies on JavaScript to show its real content might not show that content to a crawler that only reads the first response. Google can process a lot of JavaScript, but that is a different claim from Google processing every implementation exactly as a developer intended, and only the first one is safe to make.
Being published, being discoverable, and being crawlable are three different conditions, and clearing all three still doesn't mean the content has been indexed.
What happens when Google indexes a page?
Indexing is Google analyzing a page's content and deciding how, or whether, to represent that information inside its searchable database.
Google's index is not a live mirror of the web. It's a stored, processed collection, and when someone searches, Google looks through that collection rather than re-fetching the entire internet in real time. Treating "the internet," "everything Google has found," and "the Google index" as three names for the same thing is a common mistake, but they are three different sets.
What actually gets processed goes beyond logging an address. Google's description of indexing includes analyzing text, images, video, and information found in a page's markup. This is about understanding and representing a page, not grading individual tags or elements against a checklist, and it's worth resisting the urge to read ranking weight into any of it.
One wrinkle indexing has to deal with is duplication. The same or very similar content is often reachable through more than one address, and treating each as a totally separate piece of information would just create clutter. Google handles this by grouping similar pages and picking one representative, the canonical page, to show in search results. A site owner can signal which version they'd prefer, but that's a preference, not a command: Google still makes the final call, and canonicalization only applies to genuinely duplicate or near-duplicate content. It is not a way to merge separate articles into one stronger page.
Meeting the minimum technical bar, crawler access, a working response, and indexable content, makes a page eligible for indexing. It doesn't promise inclusion. And inclusion itself doesn't promise anything about showing up for a particular search. Google has said directly that a page can be reported as indexed in Search Console even when its owner never sees it show up for the queries they check. Indexing answers whether information made it into the collection. Serving answers whether that information gets picked for this request. A page can clear the first question and still miss the second.
Three related controls are worth knowing apart from each other, because conflating them causes real confusion. Blocking a page with robots.txt stops Google from crawling it, but the URL can still turn up in search results in some form, since Google learned about its existence from somewhere other than the page's own content. A noindex instruction tells search engines not to index a page once they can actually access and read that instruction, which means a crawler blocked by robots.txt may never see the noindex rule at all; Google doesn't support putting noindex inside robots.txt either. A canonical declaration, meanwhile, communicates a preferred duplicate, not an exclusion order. Treating any of the three as interchangeable is where a lot of "but I told Google not to" frustration comes from.
Indexing puts information into Google's searchable collection. It doesn't assign that information a fixed, permanent spot.
How does Google choose results for a search?
When someone searches, Google interprets the request, looks through its index for matching information, and runs automated ranking systems to select and order whatever counts as useful for that specific request.
Understanding a query is more involved than matching an identical string of words. Google describes handling misspellings and connecting related wording through synonyms, and its own example is a search for "change laptop brightness" matching a page written as "adjust laptop brightness." The words differ; the underlying request is the same, and Google's systems are built to notice that. That doesn't mean wording never matters, and it doesn't mean Google reads every request perfectly. It means exact phrasing is not the whole story.
Once the request is understood, Google's systems search the index for matching material, then rank and order what they find. It's fair to call the first part retrieval and the second part ranking, as a useful explanatory split rather than a full map of Google's internal architecture. What it rules out is picturing Google re-reading the entire live web after someone hits search, or scoring every indexed document identically for every query. Neither is how the public overview describes the process.
Ranking also isn't one universal scoreboard that every website occupies a fixed rung on. Google says the relative weighting its systems apply shifts with the nature of the query, and context like location or language can change what counts as a good answer. A local search and a broad informational search can reasonably pull different results and present them differently, and that's a feature of the system, not an inconsistency in it.
Presentation is its own decision layered on top of ranking. The features that show up on a results page can shift with the query; Google's own example is that "bicycle repair shops" tends to surface local results, while "modern bicycle" leans toward images. That's not a fixed formula tied to those exact words. It illustrates that the type of answer a query seems to want shapes how results get presented, and Google also actively avoids stacking up near-duplicate results.
Paid search sits outside all of this. Google states plainly that buying ads does not influence how its ranking systems treat an advertiser's organic results, and it labels ads "Sponsored" or "Ad" to keep them visually separate from the ranked list. It also says it doesn't take payment to crawl a site more often or rank it higher. An ad above the organic results says nothing about where that same page would land organically.
A search result is an outcome for one query in one context. It isn't a permanent property attached to a website the way a credit score is attached to a person.
Why do rankings change?
Search results move because the available information changes, because expectations change, and because Google's own systems change. A movement by itself doesn't tell you which of those happened, or whether anything happened to your page specifically.
The web keeps producing new and updated content, and what counts as a useful answer shifts with it. A page doesn't need to be touched at all for its relative position to move, because the pages around it, and the systems evaluating all of them, can shift instead. That cuts against two common assumptions: that every decline is a penalty, and that every gain proves a specific edit worked. A ranking movement is something you observed, not something you've fully explained.
Google calls its significant, broad changes core updates, and it says these happen several times a year. The word "broad" matters here. Google describes core updates as changes to the overall system rather than actions aimed at particular sites or pages, so a drop that follows one doesn't by itself prove a page did something wrong or broke a policy. It's a reassessment, not a verdict.
None of this happens without testing. Google describes evaluating proposed changes, reviewing data on how they perform, and running live traffic experiments before anything ships broadly. It also works with external Quality Raters who assess how well results satisfy real search requests. Their ratings help Google benchmark whether its systems are working overall, but a rater is not personally deciding where any individual brand's page lands. That distinction is worth holding onto whenever someone asks who is "grading" their content.
There's no universal published timetable for any of this. Google doesn't guarantee a fixed interval from publishing to discovery, crawling, indexing, or a particular ranking outcome, and it says plainly that site changes are not guaranteed to produce a noticeable search impact. A timing statement about one kind of update shouldn't get stretched to cover every stage of the pipeline.
A search position is a changing comparison, playing out against an also-changing field. It isn't a certification, and it isn't a promise.
What should marketers take from this model?
The real payoff of understanding this pipeline isn't a new checklist. It's a better set of questions to ask before reacting to a ranking change, and a way to diagnose a traffic drop methodically instead of guessing.
Three questions cover most of what needs checking: Does Google know this page's address, and can it reach the content? Has Google processed that content into its searchable collection, and how is it handling duplicate versions? And is that information being selected for the searches your real audience runs? These line up with access, indexing, and selection, and they're conceptual checkpoints, not a recovery script.
Google Search Console gives evidence for the first two questions: the URL Inspection tool for one page, and the Page Indexing and Crawl Stats reports for a wider view of access and processing. None of that exposes Google's actual ranking calculations, and an indexed page can still fail to show up for the specific query someone checks. Search Console tells you what Google did with a page. It doesn't tell you why a competitor outranked it this week.
This same foundation carries into Google's AI-driven search features. A page has to already be indexed and eligible to appear in regular Google Search with a snippet before it can serve as a supporting link in AI Overviews or AI Mode, and Google says there are no extra technical requirements beyond that baseline. How Google's AI features actually read a site builds on the same crawl-and-index foundation covered here, and these features can also run what Google calls query fan-out, several related searches behind the scenes that feed one answer. Clearing the ordinary bar doesn't guarantee an AI citation any more than being indexed guarantees a top organic result, which is exactly why ranking first doesn't automatically mean an AI citation follows.
For a leadership conversation, the cleanest version of this model fits in three sentences: "Google can access this page." "Google has indexed it." "Google selects it for the search we care about." Those are three different claims, and publishing more pages doesn't make any of them automatically true. Keeping them separate is also what makes individual-factor debates easier to place. Whether a page's indexing status matches its device parity is one of those debates. Whether on-page structure is pulling its weight is another. So is whether a page has simply slipped off the site's internal map entirely.
That's the honest, short version of how does Google ranking algorithm work, and the complete Google search algorithm explained in a way a marketing lead can actually use: a three-stage pipeline, not a single formula. Use crawl, index, and rank as your starting questions the next time someone brings you a ranking claim to evaluate.
