Good URL strategy for sitemap and SEO - seo

I run a site where users have their own profile pages. They are also able to post products for sale (that they have made) and write/import blog posts. I am going to be implementing a sitemap and I need to make a final decision with the URL strategy.
Here's what I currently have for products (where 1234 is the product ID that I use to lookup that product):
N.B "product" is a fixed string (although it's another word in the actual site) - all others are dynamic depending on the item.
example.com/product/1234.product-category.product-name
should I change to any of these? i.e:
example.com/maker/users_name/product-category/product-name/1234
example.com/product/product-category/product-name/1234
example.com/product/1234/product-category/product-name
The main items for consideration are:
Where should the product ID go in the URL? Both in terms of readability by the user but also in SEO terms
Should I include the user's name (as he/she made that product) ?
Should I attempt to remove the ID altogether?

I think the first example (example.com/product/1234.product-category.product-name) is the best format but I would consider changing then "." to "-". I am just thinking that if somehow a product name ends in something that triggers an different handler on your server like ".php" or ".jsp" you might have some undesired effects.
Where should the product ID go in the URL? Both in terms of readability by the user but also in SEO terms
I don't really think it matters too much where the product ID goes but as far as the user reading it, I think they pay attention to the end of the line so I would put the ID first leaving the most descriptive part (the product name) at the end.
Should I include the user's name (as he/she made that product) ?
Not sure if you allow your users to change user names, but if you did I would leave the user name out. An example would be someone getting married and changing their last name. This would hurt your SEO since the URL would change but search engines would have already indexed it the old way. You'd have to put some permantent redirects in place to handle this which could be avoided by just leaving the username out.
Should I attempt to remove the ID altogether?
You should leave the ID in the URL in the event that two products have the same name and your algorithm to generate the URL creates a duplicate link.

I prefer this:
example.com/users_name/product-category/product-name/1234
However, one should be aware that the url gets too long some times. It is difficult to represent or promote in a blog or a forum. Why not simply use
example.com/1234 and use the Title to put the other details like category and product name?
Now a days, I think search engines are getting smarter and short urls are used more and more.

Related

What is the permalink to a blog post on Shopify?

Given a product id (PRODUCTID), the permalink to the published product page on Shopify is https://SHOP.myshopify.com/products/ID.
For a blog post, there are two ids, id of the blog post, and id of the blog. How do I get the permalink to the blog post?
I tried https://SHOP.myshopify.com/articles/BLOGPOSTID, but it did not work.
Not sure what you mean by permalink. When you access a product, if you were going to want a longer term solid reference to it, I think the handle serves as a better "permalink" than ID. Handle is used for search engines, and the site map. ID's are more for an administrative view of things, and note that an ID can change if you were to accidentally delete the product and recreate it. Happens all the time I bet. But the handle, that stays.
As for referencing blog articles, yes. They remain a bit tougher than products, since they do have that extra reference ID in the path. The reference of blogs/name_of_the_blog/ID_article_handle is awkward for sure. Why Shopify still keeps the article ID in there is due to some really longstanding old code no one has to see real reason to fix.
It used to be a lot of pseudo-seo-smart people dissed the whole Shopify URL scheme as unworkable for SEO, but I think in the end, they were proven to be a hefty lot of nothing to see here, move along.

real estate large scale 301 redirect

Trying to work out what to do in regard to a redirect of a new client real estate website.
We have no access at all to the old site and the url structure on new is forcibly different due to randomly generated property IDs (our system generates a different ID from old)
The old url structure is www.mydomain.com/property/view?=1111
The new url structure is www.mydomain.com/property/street-name/2222
My instinct is to do manual 301s for every property (about 6000), matching by page title, but sadly I cant as I have no access to the structure of the old website and despite spidering it numerous times I cant get a pull of all properties off.
If any could give me any advice on what best to do to avoid bad user experience and a google frying, would really appreciate it.
Thanks in advance.
Mark
It depends on what the 1111 is. If that corresponds to an MLS ID number (some sort of UID) then you should be able to use regex to get it to work. Most of the IDX vendors offer a way to grab listings via an MLSID.
If that 1111 is instead just a GUID of the previous IDX vendor, then you might be out of luck and would need to do everything manually.

Will I get penalty if my last section of URL will repeat?

I've made system very similar to this site where site.com/item/{id}/{name}. Now I wonder if my {name} will repeat itself like in this example
site.com/item/1/something
site.com/item/2/something
site.com/item/3/something
Will I be banned from google bots for this or it is completely normal?
Shouldn't the ID specify a unique row in your database? In that case, there may be instances where name is similar to others, but probably not ever duplicated.
If it were duplicated, however, then yes this would be duplicated content and wouldn't be good for your website. You won't get 'banned from Google bots,' but the pages would have a low score in SERPs. Think of it as a filter, not a penalty.
I will get penalty if I will use /{id}/{name} if the name will repeat itself.
What I did is /{id}-{name}. This way it will never repeat itself and I will be able to find it.

What's more important in SEO: Title or link data?

I'm developing a store locator web site where users may search for a brand and get a list of stores selling this brand.
Now I'm doing some SEO. My goal is that when someone is googling for a store name or storename + city, then my site will be listed on page one.
If you visit a store on my site today, the title will show:
storename, city, country - at mysite.com
My URL will look like this:
http://mysite.com/store/?store=Mardou+&+Dean&storeid=5459
My question is:
- Should I add city name and country in my URL?
- Would it be good or bad in terms of SEO to have this url:
http://mysite.com/store/Norway/Oslo/Mardou+&+Dean/?storeid=5459
In terms of usability,the last url is best, but not sure if it matters to search engines?
I know that there is a lot more to SEO, but now I'm just wondering about this part.
Depends on how much information you want to expose to search engine, you should adjust the data used in these Microdata.
This article is worth reading:
http://www.vanseodesign.com/web-design/html5-microdata/
The impact of keywords in the URL is not as important as you think. Ensuring that your targeted terms are in the page title, content and headings, internal and external backlink anchor text etc are all much more powerful signals.
Don't confuse "exact match domains" with exact match URLs.
For more "educated" "opinion" on what matters, take a look at http://www.seomoz.org/article/search-ranking-factors

Product catalogue storage in mongoDB from an RDBMS perspective

I have a product page with an URL of the form http://host/products/{id}/{seo-friendly-url}, where the "seo-friendly-url" part may be something like category/subcategory/product.
The products controller gets the product with the specified ID and then ensures that the URL that follows is correct for the product - if it isn't the user is redirected to the appropriate URL (all URLs in the shop are generated correctly though, the redirect is just to maintain a canonical URL in the case of mistyping by the user or the URL changing since Google crawled it etc). The ID ensures fast product look-up, and the part on the end ensures keywords make it into the URL.
To check the URL, I have a SQL view which utilises a recursive common table expression to concatenate the product URL chunk with the URLs of its parent category URLs all the way up the hierarchy (generally just 3 deep).
I've recently came across document oriented storage and I can see it being very useful in a variety of situations (for example, my product entities have tags and multibuy prices and attributes etc all in different tables currently).
So on to my question - how can I achieve the above functionality in mongoDB, or is there a better way to think about it? The naive way would be to retrieve each category in the hierarchy individually, but I'm assuming that would be slow.
Related: I've read in the docs that skip/limit for is slow for large result sets - would this be noticeable for the maximum of say 10 pages of 25 products each likely to be present in a retail website category?
I think your best option is to just store the full slug with the product. Then when you get the product just check to see if the slug matches and if not, redirect. Now, the trade-off is that if you want to rename a category you will need to do a batch job to find all products in the category and change their slugs. The good news is that category renames will be much less common than views (hopefully) so your total load will be reduced.
Not sure how skip and limit are related to this question, except that they both involve mongodb. Anyway for 25 results it's really no problem. Limit isn't slow and in fact can speed things up if less than 100 (default first batch size). Skip can hurt performance, but only by making it as slow as if you fetched all skipped documents w/o the extra network traffic. Therefore I wouldn't skip 1 million docs, but skipping 100 would be fine.
You can model a collection called products, with the document like:
product:{id:someId,category:someCategory,subcategory:someSubCategory,productSlug:somenameslug}
The query to get the product given the id, category and subcategory would be something like:
db.products.find({id:123,category:cat,subCategory:subcat})
This sounds pretty simpleton but given my understanding of your question IMO this should be a good start.
For your other question, there are skip and limit modifiers to help with pagination.