Chuyển đến nội dung chính

The Difference Between URL Structure and Information Architecture - Whiteboard Friday

Posted by willcritchlow

Questions about URL structure and information architecture are easy to get confused, but it's an important distinction to maintain. IA tends to be more impactful than URL decisions alone, but advice given around IA often defaults to suggestions on how to best structure your URLs. In this Whiteboard Friday, Will Critchlow helps us distinguish between the two disparate topics and shares some guiding questions to ask about each.

Click on the whiteboard image above to open a high-resolution version in a new tab!

Video Transcription

Hi, everyone. Welcome to a British Whiteboard Friday. My name is Will Critchlow. I'm one of the founders of Distilled, and I wanted to go back to some basics today. I wanted to cover a little bit of the difference between URL structure and information architecture, because I see these two concepts unfortunately mixed up a little bit too often when people are talking about advice that they want to give.

I'm thinking here particularly from an SEO perspective. So there is a much broader study of information architecture. But here we're thinking really about: What do the search engines care about, and what do users care about when they're searching? So we'll link some basics about things like what is URL structure, but we're essentially talking here about the path, right, the bit that comes after the domain https://ift.tt/2yYIvZg.

There's a couple of main ways of structuring your URL. You can have kind of a subfolder type of structure or a much flatter structure where everything is kind of collapsed into the one level. There are pros and cons of different ways of doing this stuff, and there's a ton of advice. You're generally trading off considerations around, in general, it's better to have shorter URLs than longer URLs, but it's also better, on average, to have your keyword there than not to have your keyword there.

These are in tension. So there's a little bit of art that goes into structuring good URLs. But too often I see people, when they're really trying to give information architecture advice, ending up talking about URL structure, and I want to just kind of tease those things apart so that we know what we're talking about.

So I think the confusion arises because both of them can involve questions around which pages exist on my website and what hierarchies are there between pages and groups of pages.

URL questions

So what pages exist is clearly a URL question at some level. Literally if I go to /shoes/womens, is that a 200 status? Is that a page that returns things on my website? That is, at its basics, a URL question. But zoom out a little bit and say what are the set of pages, what are the groups of pages that exist on my website, and that is an information architecture question, and, in particular, how they're structured and how those hierarchies come together is an information architecture question.

But it's muddied by the fact that there are hierarchy questions in the URL. So when you're thinking about your red women's shoes subcategory page on an e-commerce site, for example, you could structure that in a flat way like this or in a subfolder structure. That's just a pure URL question. But it gets muddied with the information architecture questions, which we'll come on to.

I think probably one of the key ones that comes up is: Where do your detail-level pages sit? So on an e-commerce site, imagine a product page. You could have just /product-slug. Ideally that would have some kind of descriptive keywords in it, rather than just being an anonymous number. But you can have it just in the root like this, or you can put it in a subfolder, the category it lives in.

So if this is a pair of red women's shoes, then you could have it in /shoes/women/red slug, for example. There are pros and cons of both of these. I'm not going to get deep into it, but in general the point is you can make any of these decisions about your URLs independent of your information architecture questions.

Information architecture questions

Let's talk about the information architecture, because these are actually, in general, the more impactful questions for your search performance. So these are things like, as I said at the beginning, it's essentially what pages exist and what are their hierarchies.

  • How many levels of category and subcategory should we have on our website?
  • What do we do in our faceted navigation?
  • Do we go two levels deep?
  • Do we go three levels deep?
  • Do we allow all those pages to be crawled and indexed?
  • How do we link between things?
  • How do we link between the sibling products that are in the same category or subcategory?
  • How do we link back up the structure to the parent subcategory or category?
  • How do we crucially build good link paths out from the big, important pages on our website, so our homepage or major category pages?
  • What's the link path that you can follow by clicking multiple links from there to get to detail level for every product on your website?

Those kind of questions are really impactful. They make a big difference, on an SEO front, both in terms of crawl depth, so literally a search engine spider coming in and saying, "I need to discover all these pages, all these detail-level pages on your website." So what's the click depth and crawl path out from those major pages?

Think about link authority and your link paths

It's also a big factor in a link authority sense. Your internal linking structure is how your PageRank and other link metrics get distributed out around your website, and so it's really critical that you have these great linking paths down into the products, between important products, and between categories and back up the hierarchy. How do we build the best link paths from our important pages down to our detail-level pages and back up?

Make your IA decisions before your URL structure decisions

After you have made whatever IA decisions you like, then you can independently choose your preferred URLs for each page type.

These are SEO information architecture questions, and the critical thing to realize is that you can make all of your information architecture decisions — which pages exist, which subcategories we're going to have indexed, how we link between sibling products, all of this linking stuff — we can make all these decisions, and then we can say, independently of whatever decisions we made, we can choose any of the URL structures we like for what those actual pages' paths are, what the URLs are for those pages.

We need to not get those muddied, and I see that getting muddied too often. People talk about these decisions as if they're information architecture questions, and they make them first, when actually you should be making these decisions first and then picking the best, like I said, it's a bit more art than science sometimes to making the decision between longer URLs, more descriptive URLs, or shorter URL paths.

So I hope that's been a helpful intro to a basic topic. I've written a bunch of this stuff up in a blog post, and we'll link to that. But yeah, I've enjoyed this Whiteboard Friday. I hope you have too. See you soon.

Video transcription by Speechpad.com


Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don't have time to hunt down but want to read!

Nhận xét

Bài đăng phổ biến từ blog này

What Google's GDPR Compliance Efforts Mean for Your Data: Two Urgent Actions

Posted by willcritchlow It should be quite obvious for anyone that knows me that I’m not a lawyer, and therefore that what follows is not legal advice. For anyone who doesn’t know me: I’m not a lawyer, I’m certainly not your lawyer, and what follows is definitely not legal advice. With that out of the way, I wanted to give you some bits of information that might feed into your GDPR planning, as they come up more from the marketing side than the pure legal interpretation of your obligations and responsibilities under this new legislation. While most legal departments will be considering the direct impacts of the GDPR on their own operations, many might miss the impacts that other companies’ (namely, in this case, Google’s) compliance actions have on your data. But I might be getting a bit ahead of myself: it’s quite possible that not all of you know what the GDPR is, and why or whether you should care. If you do know what it is, and you just want to get to my opinions, go ahead and ...

Optimizing AngularJS Single-Page Applications for Googlebot Crawlers

Posted by jrridley It’s almost certain that you’ve encountered AngularJS on the web somewhere, even if you weren’t aware of it at the time. Here’s a list of just a few sites using Angular: Upwork.com Freelancer.com Udemy.com Youtube.com Any of those look familiar? If so, it’s because AngularJS is taking over the Internet. There’s a good reason for that: Angular- and other React-style frameworks make for a better user and developer experience on a site. For background, AngularJS and ReactJS are part of a web design movement called single-page applications, or SPAs . While a traditional website loads each individual page as the user navigates the site, including calls to the server and cache, loading resources, and rendering the page, SPAs cut out much of the back-end activity by loading the entire site when a user first lands on a page. Instead of loading a new page each time you click on a link, the site dynamically updates a single HTML page as the user interacts with the site...

How We More than Doubled Conversions & Leads for a New ICO [Case Study]

Posted by jkuria Summary We helped Repux generate 253% more leads, nearly 100% more token sales and millions of dollars in incremental revenue during their initial coin offering (ICO) by using our CRO expertise . The optimized site also helped them get meetings with some of the biggest names in the venture capital community — a big feat for a Poland-based team without the pedigree typically required (no MIT, Stanford, Ivy League, Google, Facebook, Amazon, Microsoft background). The details: Repux is a marketplace that lets small and medium businesses sell anonymized data to developers. The developers use the data to build “artificially intelligent” apps, which they then sell back to businesses. Business owners and managers use the apps to make better business decisions. Below is the original page, which linked to a dense whitepaper. We don’t know who decided that an ICO requires a long, dry whitepaper, but this seems to be the norm! This page above suffers from several issues: ...