Home > Articles > Home & Office Computing > The Web/Virtual Worlds/Social Networking

  • Print
  • + Share This
This chapter is from the book

Developing an Optimized Site Architecture

We think of print publications as mostly self-contained units. Sure, we refer to related works in the bibliography or source list of a publication. But we expect print publications to be consumed whole. This is another key difference between print and the Web. Web users do a lot more skimming and scanning than print users. Only after they determine that the information matches what they're looking for do they bother to read. This is a central insight of this book, and it affects every aspect of Web publishing, including design and architecture.

For our purposes, Web architecture is the practice of designing information experiences that help users find the information they're looking for. In a sense, writing for search engines is part of this practice. If you write in a way that helps users find information more easily through search engines than if they navigated to it from a home page, you are approaching an optimal user experience. But search is not enough, either; you also need to design for navigation. The goal is to create engagement, and in some cases, conversions. It's not enough to get a visitor to click a link; that click should land the user on a relevant page. Search can draw users to lower-level pages and encourage them to navigate up; or it can draw users to higher-level pages and enable them to navigate down. And horizontal navigation is also part of a good architectural plan. In any event, the content experience doesn't end with getting the user to come and click on something; you must get the user to engage with it.

Many architectural discussions at IBM and other companies focus on designing a hierarchy of pages that enables users to easily move from the top level to the specific information they're looking for. This is a good approach if you are designing a user experience for navigation. But it leaves out key considerations that can help users find information from search. Some search engines rely on metadata—extra-linguistic information hidden from view in the code of pages—to help determine the relevance of those pages. Though Google does not use metadata as part of its ranking, it does analyze how pages are interlinked with the rest of the Web to help determine relevance. Thus, architecting a set of pages for search engines necessarily includes paying attention to metadata and linking.

In this book, we focus on Google as the most popular search engine in the United States and elsewhere. From an architectural perspective, this means a thorough discussion of linking. This is the subject of an entire chapter later in the book.

Before we do that, we will first discuss how the standard practice of designing a hierarchy of related pages around a central topic or theme relates to keyword usage for search engines. To reach a more general audience, most architects design information around topics starting at a high level. This architecture should help users drill down into the information in the hierarchy, according to their individual needs. To enable this experience, you should choose different related keywords for each page in the topic, following the hierarchy. For example, on the IBM Web site, we might start with a high-level page on IBM Servers and then develop pages related to a specific product line, like the BladeCenter and other IBM offerings within this topic, such as BladeCenter hardware (Figure 1.1).

Figure 1.1

Figure 1.1 A hierarchy of pages in ibm.com.

You might think this is a fairly straightforward process. The architect designs the hierarchy of pages, and the writer picks keywords to fit into it. We suggest that this process rarely works the way it is drawn up on paper. At IBM, we struggle with pages in a hierarchy that do not produce search referrals because users simply do not search on the keywords we chose for those pages. Imagine a hierarchy of pages in which the third level down the tree is the highest ranking page because it uses a popular keyword, yet the top-level page in this hierarchy gets little or no search engine traffic because few users ever search on its keyword.

We suggest (and will demonstrate later in the book) that the best practice is to optimize the top pages of the hierarchy with the most competitive keywords—the ones that draw the broadest audience. Pages lower in the hierarchy need to be optimized for narrower, more targeted audiences, who typically use long-tail keywords. You do this by choosing related keywords that are more likely to appeal to specific segments of the broader audience. The point of our chapter on the relationship between architecture and writing is that architecture reflects writing practices: When we create search-first architectures, we do a better job of creating an information experience for users for the whole hierarchy, not just for isolated pages within it.

The goal of information architecture is to serve users with relevant information. But how do you know what information is relevant to them? We suggest that the search-first architecture does a good job of creating relevant information for a large set of users, with less guesswork and less trial-and-error than common architecture processes. Keyword data is the best information available from which to design your information. It not only helps you isolate specific keywords that will draw higher volumes of users to specific pages, but it helps you understand how keywords and phrases are related to one another. If you optimize a hierarchy of pages for a set of related keywords, you not only direct users to specific pages they might be interested in; you can also get them to navigate to other pages in the hierarchy from their initial search referral. If they find the top-level pages relevant, chances are they will find pages targeted toward more narrow audiences even more relevant.

In large organizations with a complex matrix of Web sites, content creators can unwittingly compete for the same keywords, thus harming visitors' overall experience. For this reason, large organizations need to manage keywords across their whole site, not just within specific areas.

Suppose you own a part of a company's Web content—perhaps the marketing pages related to a portion of your company's product portfolio. You do all the keyword research related to that portfolio, develop a site architecture that maps pages to popular keywords and desired visitor interaction, and write optimized content for each page in the architecture. In short, you do everything right to attract the most targeted audience possible to your pages. However, suppose that a colleague owns the Web content for a related set of offerings in your company's portfolio. She does everything you do and optimizes her pages for the same keywords, all the way down to the long-tail ones. You are now unwittingly competing with your colleague for the same targeted audience.

As unlikely as this scenario is, competition is actually quite common in a company such as IBM that has a large and diverse portfolio of offerings, and many Web pages related to them. Even for themes such as Green IT, several efforts might spring up at the same time and could unwittingly compete with one another for the same users, unless these efforts are coordinated. For this reason, we recommend corporate-wide keyword management systems, which enable content owners to reserve specific keywords for specific pages. These systems can spread keyword usage across an enterprise in way that is similar to, but more pervasive than, what you do when you develop a keyword-based architecture around your theme or topic. With such a tool in place, you can optimize your enterprise for popular keywords and attract targeted audiences to the most important pages for your business.

  • + Share This
  • 🔖 Save To Your Account