Imagine a library where every book exists, but none of them reference any other. No footnotes. No "see also." No card catalog connecting related works. Every reader would need to already know exactly which book held the answer, because nothing in the building pointed anywhere else. Finding information would depend entirely on luck or memory.

The web does not work that way, and the reason is a single idea so simple it is easy to take for granted: any document can point directly to any other document, anywhere, and a reader can follow that pointer with one click. This idea is called the hyperlink, and it is the feature that gives the World Wide Web its name. In Chapters 5 and 6 you learned how to structure a single page with HTML. This chapter teaches you how to connect pages — to each other, to other websites, and to specific points within a page — and how to organize those connections into a website that makes sense to the people who use it.

Every HTML page you built in Chapters 5 and 6 was, on its own, an island. It had structure, headings, and meaning, but nothing connected it to anything else. The feature that turns a collection of separate documents into a web is the hyperlink — a piece of text, an image, or another element that, when activated, takes the user to a different location: another page, another part of the same page, a file, or an external resource.

The idea of linked documents predates the web itself. Researchers had imagined systems of cross-referenced information for decades before any of it was built. What made the World Wide Web different was that it combined this idea with a simple, universal way to address any document on any connected computer, and a simple piece of HTML markup — the anchor element, which you will meet in the next section — that any author could use to point to it.

Links matter for two audiences at once. For people, links are how they move through information: from a search result to an article, from a homepage to a product page, from one paragraph to a related idea. For machines, links are how search engines discover new pages in the first place — a search engine finds your site largely by following links to it, and finds the rest of your site by following the links inside it. A page with no incoming links is difficult for anyone, human or machine, to find at all.

HTML creates a link with the anchor element, written as <a>. The anchor element needs one essential attribute to function as a link: href, short for "hypertext reference." The value of href is the destination — the path or address the browser should go to when the link is activated.

Whatever content sits between the opening <a> tag and the closing </a> tag becomes the clickable link. Most often this is text, but it can also be an image or a small group of elements. Whatever it is, that content is what the user sees and clicks.

An anchor element without an href attribute is not a functioning link — browsers will display it without the usual link styling and it will not be reachable by keyboard the way a real link is. If an element should behave like a link, it needs href. If it should trigger a script action with no destination, it is usually better written as a <button>, a distinction Chapter 9 returns to.

By default, browsers style links in a recognizable way — typically underlined and colored, with a different color once a link has been visited. This default styling exists so that links are visually distinguishable from ordinary text without any extra effort from the page author. You will learn to style links deliberately, including their hover and visited states, when Chapter 12 introduces pseudo-classes. For now, leave the default styling alone and focus on writing correct, working href values.

Chapter 3 introduced relative paths for linking stylesheets, scripts, and images. The same idea applies directly to links between pages. A relative link describes a destination relative to the location of the current file — not as a complete address, but as directions from "here."

Three patterns cover the large majority of relative links you will write in a typical project.

Relative links have an important advantage: because they describe a path rather than a complete address, an entire project folder can be copied, renamed, or moved to a new server, and every internal link will continue to work — provided the files keep the same positions relative to one another. This is why Chapter 3 emphasized clean, consistent project structure: relative links depend on it directly.

An absolute link uses a complete URL: a protocol such as https://, a domain name, and usually a path. Chapter 2 explained URLs in depth as part of how the web works; here, the focus is simply on when and how to use a full URL inside an anchor element.

Relative links only make sense for files that live inside your own project, because they describe a path through your own folder structure. To link to a page that lives anywhere else — a different website entirely — you need the complete address.

One more situation calls for an absolute link even within your own site: if you ever reference your own pages from outside contexts — an email, a social post, another company's website — those references need the full address, because there is no "current file" for a relative path to be relative to.

A link does more than point somewhere; it makes a small decision on behalf of the user about how they will get there. Two decisions matter most: whether the link opens in the same tab or a new one, and whether the link's text tells the user what to expect.

By default, a link replaces the current page. Adding target="_blank" opens the destination in a new tab instead, leaving the original page open. This is sometimes useful — for example, linking to an external reference that a reader might want to consult without losing their place — but it should be used deliberately, not by habit. Opening too many links in new tabs leaves users with a cluttered row of tabs and can be disorienting, especially for people using screen readers, who are not always told that a new tab has opened.

When you do use target="_blank" for a link to another website, pair it with rel="noopener noreferrer". Without it, the newly opened page can, in some browsers, gain a limited ability to access and redirect the original tab — a small but real security and privacy concern. noopener blocks that access; noreferrer additionally withholds referrer information from the destination site.

Two special href patterns let a link launch a different application instead of navigating to another page. A mailto: link opens the user's email program with a new message addressed to the given address. A tel: link, most useful on phones, starts a call.

The words inside a link should make sense even if a reader sees them out of context — which is exactly how many screen reader users browse, by pulling up a list of every link on a page in isolation from the surrounding sentences. Link text such as "click here" or "read more" tells that reader nothing about where the link goes.

Not every link needs to leave the current page. A link can also jump to a specific location within the same page — or within a different page — using a fragment identifier: an href value that begins with a hash symbol, #, followed by the value of an id attribute somewhere on the page.

Every id attribute value must be unique within a page. Once an element has an id, a link anywhere can jump straight to it.

A fragment identifier can also follow a filename to jump to a location on a different page: href="resources.html#video-guides" opens resources.html and scrolls directly to the element with id="video-guides".

Chapter 6 introduced <nav> as one of the landmark elements that gives a page meaningful structure. A navigation menu is simply a group of links, wrapped in <nav>, that lets a visitor move between the major pages or sections of a site.

The standard pattern wraps the links in a list — almost always an unordered list, since the order of a navigation menu rarely carries meaning on its own. This is not just convention: a list communicates to assistive technology that the links form a related group, and many screen readers announce how many items the list contains, which helps a listener understand the scope of the menu before navigating through it.

Two details in that example are worth noticing. First, aria-label="Main" distinguishes this navigation landmark from any others on the page — useful once a site also has, say, a footer navigation menu. Second, aria-current="page" marks which link represents the page the visitor is currently on, which both sighted users and assistive technology can use to orient themselves. Chapter 26 builds on this idea when it covers active navigation states across a full multi-page site.

A breadcrumb trail is a small row of links, usually placed near the top of a page, that shows the path from the site's home page down to the page currently being viewed. The name comes from the fairy tale in which a trail of breadcrumbs marks the way back. On a website, a breadcrumb trail marks the way back up the site's hierarchy.

Notice that the trail uses an ordered list, since the sequence from home to current page genuinely matters, and that the final item — the current page — is plain text, not a link, since linking to the page a visitor is already on serves no purpose.

Information architecture is the practice of organizing and labeling the content of a site so that people can find what they need. It is a planning activity that happens before — and continues alongside — writing any HTML. A site with strong information architecture feels obvious to navigate; a site with weak information architecture leaves visitors clicking around, unsure where to look.

Two broad patterns describe most small to medium sites:

Before writing a single file, it helps to sketch a site map — a simple diagram or outline listing every planned page and how they connect. Restructuring a site map on paper costs minutes; restructuring a site after dozens of pages already link to one another costs hours of careful path-fixing. This is the same lesson Chapter 3 taught about project folders, applied one level up: plan the shape of the whole site, not just the shape of one folder.

This is a flat structure: every page is one click from every other page through the same navigation menu. That choice is deliberate, not accidental — for a five-page learning site, a flat structure is simpler to build, simpler to maintain, and easier for a visitor to understand at a glance than a hierarchy would be.

Every idea in this chapter comes together in one practical task: building a small set of pages that link to each other correctly and consistently. This section walks through that process from start to finish, using the Student Learning Site site map from Section 7.9.

A site built this way — small, flat, consistently linked, and carefully tested — is exactly the foundation the rest of this textbook builds on. Part III adds styling and layout to these same pages. Part IV adds JavaScript interaction. Part V revisits navigation again, in Chapter 26, to show how to keep a shared header and footer consistent without duplicating effort across many more pages than five.