Search Engine Architecture
Scalable Web Crawling
Beyond the Seed URLs
A web crawler's journey begins with a list of starting points, known as seed URLs. Think of these as the first entries in a vast, ever-expanding address book. From these seeds, the crawler follows every hyperlink it finds, discovering new pages. The collection of all URLs that have been discovered but not yet visited is called the Crawl Frontier—the boundary between the known and the yet-to-be-explored web.
Not all URLs in the frontier are created equal. A large-scale crawler can't just visit them in the order they're found. It needs a prioritisation strategy. It might prioritise pages from high-authority domains, like major news sites or government portals, assuming they contain important information. It also considers freshness, frequently re-crawling pages that are known to update often, like a live news blog, while visiting a static 'About Us' page less frequently. This logic ensures the most valuable and timely content is indexed first.
Taming the URL Chaos
The web is messy. A single webpage can often be accessed through multiple different URLs. This creates a massive duplication problem for crawlers. Processing the same page multiple times wastes bandwidth, storage, and processing power.
# All these URLs might lead to the same page:
http://example.com/page
https://example.com/page
http://www.example.com/page
https://www.example.com/page
https://example.com/page?session_id=12345
https://example.com/page/index.html
To combat this, crawlers perform URL normalisation. This is a process where URLs are converted into a consistent, standard format. It involves steps like converting the domain to lowercase, removing the 'www' prefix, and stripping unnecessary tracking parameters or session IDs. The goal is to ensure that http://Example.com/ and http://example.com are treated as the same URL.
After normalising, the crawler must still determine the one true source for a piece of content. This is called canonicalisation an essential step for search engines to avoid indexing duplicate content. Web developers can signal the preferred URL by placing a special tag in the HTML head of a page:
<link rel="canonical" href="https://www.example.com/the-real-page" />
This tag tells the crawler, "Even if you found this content at a different address, please consider this href link to be the original source." By respecting this directive, crawlers can consolidate all signals—like inbound links—to a single, authoritative URL, leading to a cleaner and more efficient index.
Playing by the Rules
A crawler that fetches pages too quickly can overwhelm a web server, slowing it down or even causing it to crash. To prevent this, well-behaved crawlers adhere to a politeness policy which involves leaving a reasonable delay between requests to the same server.
Most importantly, ethical crawlers respect a file called robots.txt. This is a simple text file that a website owner can place in the root directory of their site to give instructions to automated bots. It specifies which parts of the site should not be crawled.
User-agent: *
Disallow: /private/
Disallow: /checkout/
User-agent: Googlebot
Disallow: /tmp/
Sitemap: https://www.example.com/sitemap.xml
In this example, the User-agent: * directive applies to all bots, forbidding them from entering the /private/ and /checkout/ directories. There's also a specific rule just for Googlebot. The file can also point crawlers to a sitemap.xml file, which provides a helpful map of the site's important pages.
Navigating the Modern Web
The early web was mostly static HTML documents. Today, many pages are dynamic, loading content using JavaScript after the initial page has loaded. This poses a challenge for crawlers, which traditionally only read the raw HTML source. If important content or links are generated by JavaScript, a simple crawler will miss them entirely.
This is a core challenge of accessing the 'Deep Web'—parts of the internet not reachable through standard hyperlinks, such as content hidden behind search forms, login walls, or complex user interactions.
Modern crawlers like Googlebot have evolved into full-blown rendering engines. They load a page in a headless browser (a browser without a visual interface), execute the JavaScript, and then index the final, rendered page. This allows them to see the web much like a human user does. However, this process is significantly more computationally expensive than just parsing HTML.
Another lurking danger is the spider trap, an algorithmic black hole for web crawlers. A poorly configured server can accidentally generate an infinite number of pages. A classic example is a calendar with a 'next month' link that never ends, allowing a crawler to get stuck requesting pages for the year 3000, 3001, and so on. Distributed crawlers employ heuristics to detect these traps, such as monitoring for URLs with ever-increasing path depths or repetitive patterns, and will eventually stop following them.
What is the primary purpose of URL normalisation in web crawling?
A website's robots.txt file contains the line Disallow: /private/. According to politeness policies, how should a crawler react?
