Introduction

Wikipedia can be modeled as a directed graph where each article is a node and each internal link is an edge. If you want the shortest path between two articles, the core algorithm is usually breadth-first search, because each link traversal has equal cost.

Core Sections

Model the problem as an unweighted graph

When every click from one article to another counts as one step, you do not need Dijkstra’s algorithm or A-star to get started. Breadth-first search, often called BFS, is enough because it explores all articles one level away, then two levels away, and so on.

That guarantee matters. The first time BFS reaches the target article, the discovered path is the shortest in terms of number of links.

Fetch outbound links from the Wikipedia API

The MediaWiki API can return article links page by page. In practice, you need to handle continuation because popular pages may have too many links for a single response.

1import requests
2
3API_URL = "https://en.wikipedia.org/w/api.php"
4
5def fetch_links(title: str) -> list[str]:
6    links = []
7    params = {
8        "action": "query",
9        "titles": title,
10        "prop": "links",
11        "pllimit": "max",
12        "format": "json",
13    }
14
15    while True:
16        response = requests.get(API_URL, params=params, timeout=10)
17        response.raise_for_status()
18        payload = response.json()
19        pages = payload["query"]["pages"]
20        page = next(iter(pages.values()))
21        links.extend(item["title"] for item in page.get("links", []))
22
23        if "continue" not in payload:
24            break
25        params.update(payload["continue"])
26
27    return links

This function is small, but it already handles one of the biggest mistakes in Wikipedia graph code: assuming one API response contains every outbound link.

Run BFS and remember parents

The easiest way to reconstruct the path is to remember where each discovered article came from. Once the target is found, walk backward through the parent map.

1from collections import deque
2
3
4def shortest_path(start: str, target: str) -> list[str] | None:
5    queue = deque([start])
6    parents = {start: None}
7
8    while queue:
9        current = queue.popleft()
10        if current == target:
11            path = []
12            node = target
13            while node is not None:
14                path.append(node)
15                node = parents[node]
16            return list(reversed(path))
17
18        for neighbor in fetch_links(current):
19            if neighbor not in parents:
20                parents[neighbor] = current
21                queue.append(neighbor)
22
23    return None

Using the parents dictionary also doubles as your visited set. If an article already has a parent, you have already discovered it.

Make the search practical

A naive BFS across Wikipedia grows very fast. Even a few levels can explode into tens of thousands of pages. For experiments, add guardrails:

• limit the maximum depth
• sleep between requests to avoid hammering the API
• cache fetched link lists locally
• normalize titles so redirects and capitalization do not create duplicate work

A simple depth cap can prevent runaway searches.

1def shortest_path_limited(start: str, target: str, max_depth: int) -> list[str] | None:
2    queue = deque([(start, 0)])
3    parents = {start: None}
4
5    while queue:
6        current, depth = queue.popleft()
7        if current == target:
8            path = []
9            node = target
10            while node is not None:
11                path.append(node)
12                node = parents[node]
13            return list(reversed(path))
14
15        if depth >= max_depth:
16            continue
17
18        for neighbor in fetch_links(current):
19            if neighbor not in parents:
20                parents[neighbor] = current
21                queue.append((neighbor, depth + 1))
22
23    return None

Think about API behavior and data quality

Wikipedia has redirects, disambiguation pages, missing pages, and occasionally pages whose link structure is not useful for shortest-path exploration. If you want strong results, you should decide whether to follow redirects explicitly and whether to skip maintenance pages or namespaces that are not normal articles.

For small tools, it is often enough to start with article titles only and improve later once you can measure search size and response times.

Common Pitfalls

• Using depth-first search for this problem, which does not guarantee the first found path is the shortest.
• Ignoring API continuation and therefore missing many outgoing links from large pages.
• Failing to track visited pages, which can create cycles and huge amounts of duplicate work.
• Running unrestricted BFS on Wikipedia without depth limits or caching, which quickly becomes slow and expensive.
• Treating redirects and disambiguation pages as normal articles without deciding how they should affect the search.

Summary

• Wikipedia shortest-path search is naturally modeled as BFS on a directed graph.
• The MediaWiki API can provide article links, but you must handle continuation correctly.
• Store parent pointers during BFS so you can reconstruct the path efficiently.
• Add depth limits, caching, and rate control to keep the search practical.
• Redirects, disambiguation pages, and graph growth are the main engineering complications.