Is there any way to change the actual structure of a url in Shopify, rather than just the handle? For instance if I add a product it will be available at the following urls:
/products/some-product
/collections/collection-name/products/some-product
Is there any way I could change this to /collection-name/some-product, i.e. remove unnecessary words from the url?
I also realise you can add redirects, but this isn't what I want.
When thinking on the product page you should never think of playing or using the url which has 'collections'. If you take a deep look on the source code of a product you'll realize they all have a rel canonical tag pointing to the
../products/some-product
even if the product is displayed within the url
../collections/collection-name/products/some-product
If the collections url doesn't have that canonical tag, use it, otherwise crawlers/robots would consider it duplicate content because 2 different urls would show the same content.
Then if you're ok with the first part, you'll only have
../products/some-product
In such case, you will never be able to change the
../products/
part. But this is good as it helps Shopify store owners maintain a really well structured organization of products.
If you still for some reason need to play hard with urls, you can deep a bit into Application Proxies.
Related
I was wondering if it was possible to change the default URL for blogs. Our client has recipes and would like it to be mydomain/recipes instead of the mydomain/blogs
If not, is it possible to copy the blog.liquid template and rework that somehow on its own custom page? Ultimately, is there any way to achieve this behavior without having to move the recipes to some other platform?
You can have /blogs/recipes but you can't have just /recipes.
There is no way in Shopify to change this no matter what you try.
If he is concerned about SEO the /blogs/recipes won't affect it or it least it wont affect it as hard as he think.
The best you can do is generate a proxy page with an App and add the products there, but the URL will be something like /a/recipes, which will be an overkill for just an url.
Shopify does not support URL rewrite rules, so the bottom line is - you can't achieve this with only Shopify.
You can create a separate page that pulls the blogs posts from Shopify if this is really important for your client, but once again - it's an overkill.
I have been building a forum from scratch with my friends just for fun, and we're starting to see bots and scrapers go by. The problem we're having is that you can load a page /post/1 with four replies, and each reply includes a little permalink to itself /reply/1#reply-1. If I am on /post/1 and navigate to /reply/1, I'll end up right back where I started, just with the anchor to the reply. But! Scrapers have no idea this is the case, so they're opening every /post link and then following every /reply link, and it's causing performance issues, so I've been looking around SEO sites to try to fix it.
I've started using rel=canonical on the /reply page, to tell the bots they're all the same, but as far as I can tell that doesn't help me until the bot has already loaded the page, and thus I wind up with tons of traffic. Would it be correct to change my
Permalink
tags to
Permalink
since they should be the same content? Or would this be misusing rel="self" and there's another, better rel tag I should be using instead?
The self link type is not defined for HTML (but for Atom), so it can’t be used in HTML5 documents.
The canonical link type is appropriate for your case (if you make sure that it always points to the correct page, in case the thread is paginated), but it doesn’t prevent bots from crawling the URLs.
If you want to prevent crawling, no link type will help (not even the nofollow link type, but it’s not appropriate for your case anyway). You’d have to use robots.txt, e.g.:
User-agent: *
Disallow: /reply/
That said, you might want to consider changing the permalink design. I think it’s not useful (neither for your users nor for bots) to have such an architecture. It’s a good practice to have exactly one URL per document, and if users want to link to a certain post, there is no reason to require a new page load if it’s actually the same document.
So I would either use the "canonical" URL and add a fragment component (/post/1#reply-1, or what might make more sense: /threads/1#post-1), or (if you think it can be useful for your users) I would create a page that only contains the reply (with a link back to the full thread).
We are implementing a new Url structure for our existing site (Urdb.org) and I'm struggling with Url mechanics and how it relates to SEO.
In our world, we deal with the parent entity: "record", i.e. world-records, e.g. "Largest Toothpick Beard" and "attempt", e.g. "George Gaspar, Feb 2009". There is only one page, but the various attempts are on different tabs within the page.
The choices for Url are:
urdb.org/WR/toothpick-beard#GeorgeGaspar1
urdb.org/WR/toothpick-beard/GeorgeGaspar1
urdb.org/WR/toothpick-beard?attempt=GeorgeGaspar1
I had been planning on going with choice 1, but the problem is that unless I'm mistaken the page has to load first, then dynamically switch to the attempt view that the user is requesting which would be awkward.
Choice #2 seems to work from a server-side POV, but I'm strongly inclined to reduce the number of unique Urls across the site.
The only reason I list #3 is that I know in Google Webmaster tools I can instruct them to ignore certain querystring values.
Help is appreciated!
The last thing you want to do for SEO is limit the amount of content (unless its all dupe). You'll find everywhere that content is king. More spiderablke content / better chance of ranking.
Anyways, i'd say the second suggestion for full on SEO friendlyness and if you don't want to be spidered you could use suggestion 3 and exclude the parameter attempt from search engines using robots.txt
If the value of the href for Canonical tags is populated via javascript function, would that affect the Search engine indexing (as search engines ignore javascript) ?
I'm not sure I fully understand the question as you worded it. But here's my take:
Canonical tags are used to make sure that Google (et al) knows that the same page with different URLs are, in fact, the same page.
This saves Google a lot of processing time, because it will treat those pages as a single page instead of trying to index every one of them. Also, your domain's search engine ranking will probably go up because Google doesn't think you're duplicating content.
For any page that could be duplicated because of parameters, you should include a canonical link of the page you want known as the original. So yes, it would help in your case. Though you cannot put a canonical link on someone else's domain pointing to your domain, so putting it on a partner's page would not have the intended consequences.
If you want more information, read up here: Google Webmaster Central: Specify Your Canonical
I have an existing journal website with the following url structure
http://example.com/dbtable_id/
(eg. http://example.com/89348/)
where 89348 is the primary key id of the journal article.
I want to add the title of the article to the url for SEO purposes like
http://example.com/dbtable_id/article-title
(eg. http://example.com/89348/hello-world)
I like this approach because I don't need to change the PHP code since it will still look up the article by dbtable_id. All I have to do is append url friendly titles to relevant links in template files and add one more rule to a .htaccess file.
Is there anything I should be concerned about? Am I following best practices? Will the possibility for mismatch between "dbtable_id" and "article-title" affect SEO?
There are some that argue that shallow paths are better than deeper paths, but I don't put too much stock in this. A semantic page with a screwed up URL will always do better than an unsemantic page with a "perfect" URL.
So i say, go for it. As long as it doesn't have any querystring parameters, you should be fine.