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.
Related
I have an online shop in development, all went well until I decided to do SEO on the shop. After this, if I chose a product variation from front-end it just redirects me to a random product.
This picture describes the first state. The default product load.
This picture describes what is happening after you select a variation. As you can see the product name stays the same, but the link indicates that a totally different product is displayed.
If I have the debug mode enabled when selecting a variation it throws "An error occurred while processing your request" and in the request file I can see that besides some errors (Deprecated: array_key_exists(): Using array_key_exists()) it shows the request for a different product.
I can't understand why this is happening, so I am in dying need of your help.
That's the way Prestashop 1.7 works :
First time a customer lands in a multi-variation page, the default attribute will be loaded,
URL will show only the ID product.
Once you choose an attribute , an AJAX call will refresh the page
with the current attribute and URL will change with id_product-id_product_attribute value.
Not sure what you mean by "random product" as in both of your examples I see an attribute
being selected.
Anyway there are several (paid) modules to change this behaviour in a better SEO perspective,
this is definitely one of the most famous :
https://addons.prestashop.com/en/url-redirects/16633-pretty-urls-seo-friendly-url-remove-ids-numbers.html
EDIT: Just noticed that the ID product is different in the two screenshot, this could be related to some DB issues with attribute too, you should check if you have some not coherent values between id_product and id_product_attribute(s)
I found a fix for this. Apparently or appeared because I was using the duplicate function for uploading products. I don't know why but on some products it makes this behavior.
I've spent over 12 hours to find a explanation for this and I was unable to find one. The PrestaShop forum straight up banned me for posting this topic.
My advice is to NOT USE PRESTASHOP it's and old sistem and full of bugs, the support is expensive and I get the impression that even they don't understand their system.
If you find yourself in this situation, know this. Don't duplicate and upload products using "add new" function.
And I can't state this enough, do yourself a favour and don't use Presta, with all the expenses the time to invest and what the product looks like at the end of the road, is just a waste of time. Even after you finish is guaranteed to break in 1-2 years, any updates will break your store and you will need to invest even more more to fix it. It's an old, slow and buggy CMS. It's days are numbered.
Thanks a lot for help.
Best regards, Daniel.
I want to sell some products that are also prezent on another webshop. They are providing a datafeed with every information about the product, and they have nothing against that i post the info on my webshop.
The question is should i worry about duplicate content? The number of products is to high and it`s not worth rewriteing their description. Will google think that i stole the content?
Depends.
Personally i would prevent Google from indexing DC pages by adding this to the <head>...</head>:
<meta name="robots" content="noindex,follow"/>
The URLs, which come into question, won't rank anyway. So it's (usually) Ok to keep them completely out of Google's sight and don't have to worry any more about all the Algorithm-Updates.
Or, if i have a lot of pages and need more Crawl-Budget, i would use the robots.txt file:
User-agent: *
Disallow: /path/to/affiliate/products/
In this case the Linkjuice cannot flow freely within my site anymore, but all the important pages get indexed. Plus it's incredibly easy to implement. (Just don't do this if you have a lot of deeplinks to your Products from your Homepage etc.)
Matt Cutts in 2009:
"Can product descriptions be considered duplicate content?"
http://www.youtube.com/watch?v=z07IfCtYbLw
He doesn't say "its bad" but he clearly shows that Google doesn't like it.
Matt Cutts in 2012:
"Is it useful to have a section of my site that re-posts articles from other sites?"
http://www.youtube.com/watch?v=o7sfUDr3w8I States that it's propably a good idea to remove DC Pages (Like content from RSS-Feeds, Press Releases or Product-Description Feeds).
So to make a long story short - I really don't say "start panic" or whatever, i just say "remove everything from your site which could send out negative signals to Google, so you don't have to worry about it anymore" and then you can go on and build up your Brand to sell as many products as possible ;o)
Do worry about the content the site comes under the category of Affiliate sites so the product description would be same. it wont effect your site
If you want to do it properly I would get all the content re-writen. There is an amazing service out there too callws wordai.com.
Their site will re-write the content for you as if a human has on the Turing Plan.
You can then check the content with copyscape.com too see how unique it is!
Best of luck.
I've been working on a project that requires draft/live versions of content and have thought of a design such as below:
Article
ID
Creator
CreationDate
DraftContent(fk to ArticleContent)
PublicContent(fk to ArticleContent)
IsPendingApproval
ArticleContent
Title
Body
I am wondering if it would be better to change the foreign keys upon an article being published or if it is better to just copy the contents from the draft table to the live table.
Any suggestions?
Edit: Both draft and live versions exist at once although the live version is the only one that is visible to the public. There can only be one draft and one live table
Part of the reason for this design is to force users to have their articles approved before they go live.
Update:
We decided to use Kieren's solution with a slight modification. Instead of using a column for items like IsPublished IsLive we decided to use a single state column. Otherwise the design remained the same.
Draft articles that become live and then are 'published'
The usual thing would be to have a status/type flag on the article table - IsLive.
Using separate tables is unnecessary and redundant; changing foreign keys doesn't make much sense either. Think of the article as a valid object, whether its draft or live. The only difference is, in most cases you only want to display live articles. In some cases in the future, you might want to display both.
Articles that might be edited and have a new draft version after initially becoming live
In terms of one article having both a live and draft version - the most common pattern would be to have a master Article entity/object, and then say ArticleVersion coming from that. The ArticleVersion would have the IsLive property, or even better, the Article itself would have a property, CurrentLiveVersionId. That way there can be a live and draft versions lying around, but you'd only usually join Article onto the ArticleVersion by that CurrentLiveVersionId to get the current live version.
Advantages of having the ArticleVersion table include the fact that the entire history of an article, a changelog, can be stored, so you can revert to previous versions if needed, or review changes. All for a very low implementation cost..
Let me know if I can clarify this method.
Your design looks appropriate to me. When a new version goes live, I would:
UPDATE the PublicContent key to point to the (formerly) draft article.
DELETE the no-longer-referenced formerly-published article.
NULL the DraftContent key or, if your model calls for always having a draft version, INSERT a new, empty draft into ArticleContent and point the DraftContent key to it.
I'm implementing the hreview portion of microformats on a site to be indexed by Google.
http://www.google.com/support/webmasters/bin/answer.py?answer=146645
The item field of a review feels clunky to me, since I can't imagine why I'd included the name of the item being reviewed inside the review itself.
For example. If you are on Yelp there is a page about a restaurant. The name of the restaurant is at the top, but it wouldn't' make sense to repeat the restaurant name also inside each review block.
So I'm wondering if the item field is one of the ones that can be invisible to the user and still indexed by google? Incidentally, I just checked and it looks like Yelp has this field with a display: none; to the user.
Can anyone verify this?
Do you have some reason to believe there are fields that can't be hidden and still indexed by Google? It seems likely to me that Google will index all hidden fields, just because I doubt it's worth checking for them. But I'm not sure about that.
Hiding fields isn't recommended for microformats. A core idea behind microformats is you should be presenting the same content to both computers and humans. If the content isn't anywhere on the page, that violates that idea. If it's somewhere else on the page, which is often the case for reviews, you can use the include pattern.
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.