Since 1995, the costliest search engine optimization mistake I’ve encountered is poor information architecture. And when I tell a client that the core issue with findability is the website’s information architecture, my findings are immediately passed to the technical team.
Inevitably, someone on the technical team kindly points out that the content is crawlable, and the architecture is fine. And since I don’t know Google’s algorithm, I must be wrong.
Result? A whirlwind series of conversations that yielded bruised egos, a poorly architected website with little or no search engine visibility, and frustrated clients.
How did that happen? Where were the disconnections and miscommunication?
Believe it or not, many SEO professionals, developers and other IT professionals do not understand the role of information architecture (IA) in the SEO process. In fact, this group often does not understand the role of IA in the Web development process.
These misunderstandings and misconceptions lead to bruised egos and frustrated clients. To get all web professionals on the proverbial same page, let’s review some of the differences and sources of confusion.
Understanding Information Architecture
I believe the simplest and clearest definition of information architecture comes from theInformation Architecture Institute website. Information architecture is the organization and labeling of website content to support usability and findability.
There are four words you want to hear when you work on an information architecture project:
The determination of a website’s information architecture should occur long before a site is coded and programmed.
In fact, if I read or hear the following geek-speak, I am reasonably sure that I am not talking to a qualified information architect:
301 redirects (.htaccess, etc.)
All of these aforementioned terms are parts of technical architecture, not information architecture.
Web professionals constantly confuse information architecture with technical architecture. Because of that, technical architects end up making information architecture decisions…and that is a critical mistake. I believe user-centered design (UCD) and architecture is far more cost- and time-effective than technology-centered design.
“In the long run, technology-centered design is generally counterproductive to project and business goals”
~ James Kalbach, author of Designing Web Navigation (2007, Wiley)
So let’s go back to understanding what information architects do. Organization is grouping related content into categories and providing user-friendly access to that content via global, local, and contextual navigation.
There are many ways to organize content including, but not limited to:
Why did an information architect choose to organize and label content on a website via facets or by target audience? Did the information architect iteratively test the organization and content labels with participants who fit the primary personas? That’s what information architects do. They do not determine content organization based on crawlability or the flowage of “link juice.”
Adapted from Information Architecture for the World Wide Web by Peter Morville and Louis Rosenfeld. Used with permission.
Here are some items I wish to know during a website’s information architecture project:
Primary navigation. What are the labels to be presented in primary navigation? How many navigation labels will be in primary navigation? What is the order that primary navigation labels will be presented? Where will primary navigation be placed?
Secondary navigation. Is there secondary (local) navigation for each primary navigation label? What will those labels be, and what order will these labels be presented? Where will secondary navigation be placed? If a page doesn’t contain secondary navigation, what will the layout of the page be?
Third- and fourth-level navigation (as needed). Continue with naming conventions, order in which labels are presented, and the number of labels.
Contextual navigation. What types of contextual navigation will be on different page templates (category, product, help, service, form, etc.)? Contextual links such as alternatives, upsells, most popular, and other related links are just as critical for findability as a primary taxonomy and associated local links. Is there an effective balance of parent-child links as well as sibling-sibling links?
Number of links per page. How many links per page is too many for users/searchers? For example, I would expect a category page, (wayfinder) site map, and a site index to contain more links than a product or a help page. On the flip side, how many links are too few? Orphaned–page content appears less important to search engines (because there is only one link to them). And orphaned-page content seems less important to users because that content is difficult to locate and discover.
Notice that in this list, I did not once mention canonicalization, 301 redirects, NOFOLLOW attributes, and so forth. I am certainly not saying that these technical considerations are not important for SEO and the searcher experience.
Even though it might seem as if I am dismissing technical architecture, I am not. I understand the importance of providing access to content via both browsing and searching. As Peter Morville stated in his book, Ambient Findability (2007, Wiley), “You can’t use what you can’t find.”
Technical Architecture & Findability
I agree with Morville. Many technical architects agree with Morville…but with blinders on. A perfectly architected and usable website might not be accessible to search engine spiders. And technical SEO decisions should be considered and implemented.
As a Web developer, I have to make many technology decisions for clients such as:
Content management systems (CMS)
Navigation types (text links, graphic images, menus)
Troubleshooting individual pages
Even if I don’t make final technology decisions, I am often asked to consult about those decisions from the perspective of searchers and search engines. I do not make a technology decision purely based on how a search engine interprets navigation systems and content.
First, I want to know what the IA, marketing, and usability teams have determined. Then I make technology decisions. In other words, I believe that information architecture should guide technical architecture.
Duplicate content delivery, for example, can limit direct access to desired content via the commercial Web search engines. And duplicate content delivery typically annoys and frustrates users. I know that user-generated tagging and faceted classification typically lead to duplicate content delivery.
So if I or another qualified information architect determine that a website’s content is best organized using faceted classification or user-generated tagging, I know that I will need to get a technical architect involved early in the development process to minimize the negative SEO impact.
Here is another example: menus. I hear the pros and cons of using menus for a navigation system all of the time. As an SEO, I understand why the technical team wants to implement menus: it preserves screen real estate, some search engines can crawl them (it depends on how they are coded/programmed), and “people love them.”
As an information architect and usability professional, I have to consider the failure rate of different menus (fly-out menus are more error prone than drop-down menus), the paradox of choice, and the technology used to access content.
Usability guru Jared Spool recently wrote about the 6 Epic Forces Battling Your Mega Menus, both from a human and a technical perspective.
Information architects don’t need to know Google’s algorithm or the latest URL workaround to provide SEO guidance and effective labeling advice to a technical team. They don’t need a degree in computer science. I have seen too many technology teams dismiss information architecture and usability guidance because it might harm rankings.
In reality, the organization and labeling of information will increase sales, conversions, and (yes) even search engine visibility. “It’s high time to put the ‘I’ back in IT,” said Louis Rosenfeld.
Smackdown: Which Is More Important?
I believe that a successful website architecture is a combination of an effective information architecture and corresponding technical architecture. I do not believe that technical architecture trumps information architecture. I do not believe that information architecture trumps technical architecture. I believe that technical architects and information architects must listen to and support each other.
“Information architecture is concerned with the structure and arrangement of the content and a great deal of it can be done without knowing anything about the implementation,” said Dorian Taylor, researcher, consultant and current board member of the Information Architecture Institute. “Technical architecture is concerned with the implementation of the system and a great deal of it can be done without knowing anything about the content.”
“In some ways we can say that SEO is about creating structures that are meaningful to machines—in this case, search engines—so that those machines can in turn generate structures that are meaningful to people,” Taylor continued.
We need to listen to each other instead of dismissing information architects with, “I think you are more of a UX person than an SEO,” as if their contributions to findability is less important than technical implementation. I know plenty of information architects with superb technical skills. They might know more about findability and SEO than you realize.
