Preferred URL structure for directory pages?

[4RS_John]

Hi Moz-Mind,

We've got a bunch of duplicate content issues in our directory of trucking-related businesses, caused by search terms that can appear in any order, (classic mistake). We're taking advantage of this our work on URLs to try to improve our URL structure, and I'm not sure which way I want to go.

These are the options we're considering. What does the Moz-mind think of each of them?

• example.com/location-name/service-name
• example.com/service-name/location-name
• example.com/service-name-near-location-name

For the moment location-name would be a city & state abbreviation, like atlanta-ga, (unless it's better to use something else).

Since these are search URLs, it's also possible to add a distance restriction, and a keyword, to the search criteria. How do you suggest adding the distance restriction?

• example.com/service-name/location-name/50-miles
• example.com/service-name/within-50-miles/location-name
• example.com/service-name-within-50-miles-of-location-name

And the keyword?

• example.com/service-name/location-name/keyword
• example.com/service-name/location-name/keyword/{actual-keyword}
• example.com/service-name-near-location-name/keyword

Something else?

I was leaning toward example.com/service-name/location-name/within-50-miles, but I thought of the /service-name-near-location-name/ and /service-name/within-50-miles-of/location-name options today and really like how they make sense both to computers and to people, not unlike example.com/GA/atlanta/service-name/50

I'm looking forward to hearing what the community thinks. There must be an established best practice for directories, but if it's kind of ugly I'd like to find an even better way, if possible.

Thanks,

John

[4RS_John]

Thanks for the insight - it does make sense to go with /location-name/service-name because people might want to look at all services in a location, but all locations for a service doesn't make much sense, (unless someone's scraping my site, and I don't want to make life easy for those people!).

Things like /within-50-miles will be canonicalized to the base location as you suggest. You're right that there isn't much difference between that and simply /service-a/location-a

I want everything to be bookmarkable, so keyword search will be either a parameter or another path, (like /keyword-{urlencoded keyword content} ), and I may or may not canonicalize that to just the location/service combo, or simply noindex it, or leave it as-is and see what happens. The /location-a/ part of the URL can accept a lot of formats, and some, like GPS coordinates, will have to be noindexed to avoid duplicate content, (I guess I could rel=canonical them to the closest town or something, I can save that as an experiment for later).

Thanks again for the insight. It makes sense to me.

[RuthBurrReedy]

There are a lot of different ways that you can go with this, some of which will be pretty much equal in value. I would recommend going /service-name/location-name, or /location-name/service-name, depending on which of these is more important to be viewed by itself (so ask yourself: are there times when someone would be looking at the service without looking at the location, or vice versa?). The main important thing, as you point out, is that it's one or the other, not both.

I would recommend making location its own folder /within-50-miles, and adding it to the end of the URLs, rather than creating a whole different hierarchy for distance restriction.

With the keywords, how would you add in the actual keyword? Would it be with a URL parameter?

Even without the use of URL parameters, you should carefully consider which of these pages will be the canonical version. /service-a/location-a and /service-a/location-a/50-miles won't be that different in content, I imagine. It would probably be a good idea to use the canonical tag to point the distance-restricted pages back to the location pages, and let users drill down from there, rather than trying to make every permutation of factors its own landing page. Does that make sense?