The Difference Between URL Structure and Information Architecture – Whiteboard Friday

The Difference Between URL Structure and Information Architecture – Whiteboard Friday

The Difference Between URL Structure and Information Architecture – Whiteboard Friday 1920 1080 willcritchlow

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 www.example.com/whatever-comes-next.

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!

* Checkbox GDPR is required

*

I agree

Will you like to book a consultation today?

We promise you’ll be glad to have us as the only premium website developer you’ve ever had!

Will you like to book a consultation today?

We promise you’ll be glad to have us as the only premium website developer you’ve ever had!

Bear Design - WordPress Development

Bear Design provides website development and design, creating content uploaded websites and improving web page placements and web traffic. Bear Design websites are unique, easy to use and responsive. Site owners can easily edit the content, or can trust the Bear Design & Communications to keep them up to date and supply quality content regularly.


GET IN TOUCH
160 City Road, EC1V 2NX London, United Kingdom
Monday – Thursday: 9:00 AM – 5:00 PM
Friday: 9:00 AM – 2:00 PM

WE ARE IN LONDON

Bear Design - WordPress Development

Bear Design provides website development and design, creating content uploaded websites and improving web page placements and web traffic. Bear Design websites are unique, easy to use and responsive. Site owners can easily edit the content, or can trust the Bear Design & Communications to keep them up to date and supply quality content regularly.


WE ARE IN LONDON

GET IN TOUCH
160 City Road, EC1V 2NX London, United Kingdom
Monday – Thursday: 9:00 AM – 5:00 PM
Friday: 9:00 AM – 2:00 PM

Bear Design - WordPress Development

Bear Design provides website development and design, creating content uploaded websites and improving web page placements and web traffic. Bear Design websites are unique, easy to use and responsive. Site owners can easily edit the content, or can trust the Bear Design & Communications to keep them up to date and supply quality content regularly.


GET IN TOUCH
160 City Road, EC1V 2NX London, United Kingdom
Monday – Thursday: 9:00 AM – 5:00 PM
Friday: 9:00 AM – 2:00 PM

WE ARE IN LONDON

© Made with by Bear Design

© Made with by Bear Design

    We are Bear Design

    WE DESIGN

    YOUR WORLD

    Bear Design & Communications Ltd.

    Address : 160 City Road, EC1V 2NX London, United Kingdom
    Phone : +36 702 448 100
    Email : [email protected]

    Opening hours :
    Monday – Thursday: 9:00 AM – 5:00 PM
    Friday: 9:00 AM – 2:00 PM

    Are you sure?
    You must approve our cookie policy to use our site. I you refuse it you will redirect to the Google.
    Refuse
    Approve Cookies
    Cookie Policy
    Cookie Policy
    This Bear Design Cookie Policy (“Policy”) outlines the general policy, practices, and types of cookies that Bear Design And Communications Ltd.. (“Bear Design”, “we”, “us” or “our”) may use to improve our services and your experience when visiting our websites.Cookies are small pieces of text used to store information on web browsers. They’re used by many websites to store and receive identifiers and other information on devices, such as a handheld phone or computer. Our site and services use cookies and other similar technologies (collectively in this Policy, “cookies”), in order to provide a better service to you and to generally improve our sites and services. For example, we may use cookies to help direct you to the appropriate part of our websites, by indicating that you are a repeat visitor. We may also use information to present you with services that are matched to your preferences.Some portions of our websites are functional without cookies, and you may generally choose whether to accept cookies. Most web browsers are set to accept cookies by default, however, you may be able to delete cookies yourself through your browser’s cookie manager. To do so, please follow the instructions provided by your web browser. Please note that disabling cookies will reset your session, disable auto-login, and may adversely the availability and functionality of our websites and the services we can provide to you.As part of our services, we may also place cookies on the computers of visitors to websites protected by Bear Design. We do this in order to identify malicious visitors, reduce the chance of blocking legitimate users, and to provide customized services.Our websites use first party cookies (i.e., cookies set directly by Bear Design) as well as third party cookies, as detailed in the table below.
    Type of CookieWhy we use these cookiesWho serves them and where can you find out more information?
    Analytics and research of usersThese are used to understand, improve, and research users visiting //beardesign.me and their needs for our product offerings. For example, we may use cookies to understand what pages a user browses before submitting a sales request form. We do not share information about this analysis with any third parties.Selected third parties listed and defined as follows:
    • Google Analytics – Web traffic tracking – //www.google.com/policies/privacy/
    • Bing – Conversion tracking from Bing ads – https://advertise.bingads.microsoft.com/en-us/resources/policies/microsoft-bing-adsprivacy-policy
    • Doubleclick – Google advertising platform that analyzes browsing activity across website to establish user profile – //www.google.com/policies/technologies/ads/
    • Twitter – Analyzes browsing activity across website to establish user profile – https://support.twitter.com/articles/20170514
    • Facebook – Analyzes browsing activity across website to establish user profile – https://www.facebook.com/policies/cookies/
    A user can delete these cookies through browser settings.
    Improving Website experienceThese provide functionality to help us deliver a better user experience for our website. For example, cookies help facilitate chats with our sales representatives, allow you to search the website, and deliver the user quickly to their intended website location.1st party and selected third parties as defined below:
    • __cfduid 3rd party cookie – This cookie is strictly necessary for Cloudflare’s security features
    • __hssc Cookie for keeping track of sessions. This is used to determine if we should increment the session number and timestamps in the __hstc cookie. It contains: the domain, viewCount (increments each pageView in a session), session start timestamp. (Expires: 30 min)
    • __hssrc Whenever HubSpot changes the session cookie, this cookie is also set. We set it simply to the value “1”, and use it to determine if the user has restarted their browser. If this cookie does not exist when we manage cookies, we assume it is a new session. (Expires: None. Session cookie)
    • __hstc The main cookie for tracking visitors. It contains: the domain, utk (see below), initial timestamp (first visit), last timestamp (last visit), current timestamp (this visit), and session number (increments for each subsequent session) (Expires: 2 years)
    • hsfirstvisit This cookie used to keep track of a user’s first visit. (Expires: 10 years)
    • hubspotutk This cookie is used for to keep track of a visitor’s identity. This cookie is passed to HubSpot on form submission and used when deduplicating contacts. (Expires: 10 years)
    • wordpress_ WordPress cookie for a logged in user.
    • wordpress_logged_in_ WordPress cookie for a logged in user.
    • wp-settings- WordPress also sets a few wp-settings-[UID] cookies. The number on the end is your individual user ID from the users database table. This is used to customize your view of admin interface, and possibly also the main site interface.
    • wp-settings-time- WordPress also sets a few wp-settings-{time}-[UID] cookies. The number on the end is your individual user ID from the users database table. This is used to customize your view of admin interface, and possibly also the main site interface.
    • __cfduid 3rd party cookie – This cookie is strictly necessary for Cloudflare’s security features
    A user can delete these cookies through browser settings.
    LAST UPDATE: 24.01.2018, LONDON
    Approve
    Refuse
    Cookie Policy
    This Bear Design Cookie Policy (“Policy”) outlines the general policy, practices, and types of cookies that Bear Design And Communications Ltd.. (“Bear Design”, “we”, “us” or “our”) may use to improve our services and your experience when visiting our websites.Cookies are small pieces of text used to store information on web browsers. They’re used by many websites to store and receive identifiers and other information on devices, such as a handheld phone or computer. Our site and services use cookies and other similar technologies (collectively in this Policy, “cookies”), in order to provide a better service to you and to generally improve our sites and services. For example, we may use cookies to help direct you to the appropriate part of our websites, by indicating that you are a repeat visitor. We may also use information to present you with services that are matched to your preferences.Some portions of our websites are functional without cookies, and you may generally choose whether to accept cookies. Most web browsers are set to accept cookies by default, however, you may be able to delete cookies yourself through your browser’s cookie manager. To do so, please follow the instructions provided by your web browser. Please note that disabling cookies will reset your session, disable auto-login, and may adversely the availability and functionality of our websites and the services we can provide to you.As part of our services, we may also place cookies on the computers of visitors to websites protected by Bear Design. We do this in order to identify malicious visitors, reduce the chance of blocking legitimate users, and to provide customized services.Our websites use first party cookies (i.e., cookies set directly by Bear Design) as well as third party cookies, as detailed in the table below.
    Type of CookieWhy we use these cookiesWho serves them and where can you find out more information?
    Analytics and research of usersThese are used to understand, improve, and research users visiting //beardesign.me and their needs for our product offerings. For example, we may use cookies to understand what pages a user browses before submitting a sales request form. We do not share information about this analysis with any third parties.Selected third parties listed and defined as follows:
    • Google Analytics – Web traffic tracking – //www.google.com/policies/privacy/
    • Bing – Conversion tracking from Bing ads – https://advertise.bingads.microsoft.com/en-us/resources/policies/microsoft-bing-adsprivacy-policy
    • Doubleclick – Google advertising platform that analyzes browsing activity across website to establish user profile – //www.google.com/policies/technologies/ads/
    • Twitter – Analyzes browsing activity across website to establish user profile – https://support.twitter.com/articles/20170514
    • Facebook – Analyzes browsing activity across website to establish user profile – https://www.facebook.com/policies/cookies/
    A user can delete these cookies through browser settings.
    Improving Website experienceThese provide functionality to help us deliver a better user experience for our website. For example, cookies help facilitate chats with our sales representatives, allow you to search the website, and deliver the user quickly to their intended website location.1st party and selected third parties as defined below:
    • __cfduid 3rd party cookie – This cookie is strictly necessary for Cloudflare’s security features
    • __hssc Cookie for keeping track of sessions. This is used to determine if we should increment the session number and timestamps in the __hstc cookie. It contains: the domain, viewCount (increments each pageView in a session), session start timestamp. (Expires: 30 min)
    • __hssrc Whenever HubSpot changes the session cookie, this cookie is also set. We set it simply to the value “1”, and use it to determine if the user has restarted their browser. If this cookie does not exist when we manage cookies, we assume it is a new session. (Expires: None. Session cookie)
    • __hstc The main cookie for tracking visitors. It contains: the domain, utk (see below), initial timestamp (first visit), last timestamp (last visit), current timestamp (this visit), and session number (increments for each subsequent session) (Expires: 2 years)
    • hsfirstvisit This cookie used to keep track of a user’s first visit. (Expires: 10 years)
    • hubspotutk This cookie is used for to keep track of a visitor’s identity. This cookie is passed to HubSpot on form submission and used when deduplicating contacts. (Expires: 10 years)
    • wordpress_ WordPress cookie for a logged in user.
    • wordpress_logged_in_ WordPress cookie for a logged in user.
    • wp-settings- WordPress also sets a few wp-settings-[UID] cookies. The number on the end is your individual user ID from the users database table. This is used to customize your view of admin interface, and possibly also the main site interface.
    • wp-settings-time- WordPress also sets a few wp-settings-{time}-[UID] cookies. The number on the end is your individual user ID from the users database table. This is used to customize your view of admin interface, and possibly also the main site interface.
    • __cfduid 3rd party cookie – This cookie is strictly necessary for Cloudflare’s security features
    A user can delete these cookies through browser settings.
    LAST UPDATE: 24.01.2018, LONDON
    Approve
    Refuse
    Welcome
    We use cookies to ensure that we give you the best experience on our website. Before you continue browsing you must approve or refuse our cookie policy.
    Approve
    Refuse
    Cookie Policy