Some sites, like here at SO, allow 'bogus' slugs in the URL. Before implementing URL slugs on my site, I have a question of 'best practices'...
Given a structure like example.com/123/article-slug-here/, if my site allows bogus slugs by querying on the ID -
Should I ...
just do a redirect to the appropriate/canonical URL (verifying the slug, and redirecting in case of a mismatch)?
-or-
return a 404, since technically example.com/123/this-article-s-u-x doesn't exist?
Neither. Leave it as it is. Google will figure out the canonical url and keep them in their index.
You could do redirect (301 Moved Permanently of course) only if you wish to punch Google to update the changed url in their index more quickly. If it's not important, no need to bother.
P.S. I basically did the same thing in my blog. Once I changed the title of some entry and after a while (a few weeks) Google updated their index in accordance to the new canonical url that was specified in the page. Simple and works.
Related
When i add seo friendly url on opencart like 'abcd-test' or 'abcd-test.htm' it worked.
but when i added 'abcd-test/22123.htm', IT redirected to 'www.example.com/abcd-test/22123.htm' but it displayed
The page you requested cannot be found!
I already have a website in another framework other than opencart which is doing well on google ranking. but i need to move this website on opencart and i need to make same url for most of the pages. during that process my existing website have url like "www.example.com/category-s/12234.htm
so will any one facing same problem and any one have the solution for this situation.
You are not able to due to the way that OpenCart's router works. It takes the URL and delimits it on the forward slash. It then matches the key that is between the slashes to a variable value and ultimately routes based on that variable value.
For example:
http://mysight.com/one/two/three would be equivalent to something like http://mysight.com/index.php?var1=1&var2=2&var3=3.
Note: This example is not based on an OpenCart page it is merely explaining how OpenCart's router translates to raw PHP.
By including forward slashes in your SEO URL aliases OpenCart thinks that it needs to match keys that just don't exist and because it can't route to a valid page it simply redirects you to a default 404 page.
I found the answer:
In opencart To dayplay
www.example.com/test-abc/12234.htm
Here we need to have category or manufacturer with seo keyword test-abc and
12234.htm in product seo url.
Url/product
Url/parent-cat/product
Url/parent/child/product
so if I am in www.example.com/test-abc,
it is category page and if I am in www.example.com/test-abc/12234.htm, it means It is product page which beloigs to test-abc category.
it work me
Friends, this is a complex problem for me. I have researched on this many times and at last have came to you (with hope that I will get the solution). We had products URLs like:
/product_info.php/products_id/75
As per SEO, I wanted keyword rich URL so, we added a slug in products.php file and modified the URL as:
/product_info.php/products_id/75/product-title
But its also not an ideal URL. I wanted this as:
domainname.com/products/product-title/75
Changes I made in .htaccess file is as follows-
RewriteRule ^products/([A-Za-z0-9-]+)/([0-9]{2})/?$ product_info.php?products_id=$2=$1 [L]
RedirectMatch 301 ^/product_info.php/products_id/([0-9]{2})/([A-Za-z0-9-]+)$ http://www.livevaastu.com/products/$2/$1
Now problem is- our old URLs (which has no slugs) are indexed by Google. And I am not getting any idea how to redirect those old ones to new ones. Also there are many products pages so I couldn't redirect them one-by-one. You guys are genius. Can you help me any how. (without laughing on me). M not a developer.
You can't produce product_info.php?products_id=$2=$1 from your old URLs of /product_info.php/products_id/75 because they don't have the product title ("slug").
For one thing product_info.php?products_id=$2=$1 doesn't make any sense. Is that a typo? What are the key/value pairs in that query string?? This should look something like products_id=$1&product_title=$2 where each derived "value" from the mod_rewrite match gets assigned to a known "key", something you can use in $_GET or $_REQUEST to find the value.
Edit to help with what I think you are trying to achieve here, based on discussion:
If you want your old URLs to lead to the new "pretty" URLs, you will need to use PHP to do this. As mentioned, there simply is not adequate information in the URL to invent the product names. But you could pretty easily have something at the top of each page (i.e. in a header file) which looked to see if the "title" $_GET parameter is present or not (once you clean up the double-equal sign and replace it with proper key/value pairs). This might look something like:
<?php
if( !isset( $_GET['product_title'] ) ) {
// Code here to look up $product_title from the $product_id, presumably in a DB
header("HTTP/1.1 301 Moved Permanently");
header("Location: /products/$product_title/$product_id");
exit();
}
I am using ColdFusion 9.
I am creating a brand new site that uses three templates. The first template is the home page, where users are prompted to select a brand or a specific model. The second template is where the user can view all of the models of the selected brand. The third template shows all of the specific information on a specific model.
A long time ago... I would make the URLs like this:
.com/Index.cfm // home page
.com/Brands.cfm?BrandID=123 // specific brand page
.com/Models.cfm?ModelID=123 // specific model page
Now, for SEO purposes and for easy reading, I might want my URLs to look like this:
.com/? // home page
.com/?Brand=Worthington
.com/?Model=Worthington&Model=TX193A
Or, I might want my URLs to look like this:
.com/? // home
.com/?Worthington // specific brand
.com/?Worthington/TX193A // specific model
My question is, are there really any SEO benefits or easy reading or security benefits to either naming convention?
Is there a best URL naming convention to use?
Is there a real benefit to having a URL like this?
http://stackoverflow.com/questions/7113295/sql-should-i-use-a-junction-table-or-not
Use URLs that make sense for your users. If you use sensible URLs which humans understand, it'll work with search engines too.
i.e. Don't do SEO, do HO. Human Optimisation. Optimise your pages for the users of your page and in doing so you'll make Google (and others) happy.
Do NOT stuff keywords into URLs unless it helps the people your site is for.
To decide what your URL should look like, you need to understand what the parts of a URL are for.
So, given this URL: http://domain.com/whatever/you/like/here?q=search_terms#page-frament.
It breaks down like this:
http
what protocol is used to deliver the page
:
divides protocol from rest of url
//domain.com
indicates what server to load
/whatever/you/like/here
Between the domain and the ? should indicate which page to load.
?
divides query string from rest of url
q=search_terms
Between the ? and the # can be used for a dynamic search query or setting.
#
divides page fragment from rest of the url
page-frament
Between the # and the end of line indicates which part of the page to focus on.
If your system setup lets you, a system like this is probably the most human friendly:
domain.com
domain.com/Worthington
domain.com/Worthington/TX193A
However, sometimes a unique ID is needed to ensure there is no ambiguity (with SO, there might be multiple questions with the same title, thus why ID is included, whilst the question is included because it's easier for humans that way).
Since all models must belong to a brand, you don't need both ID numbers though, so you can use something like this:
domain.com
domain.com/123/Worthington
domain.com/456/Worthington/TX193A
(where 123 is the brand number, and 456 is the model number)
You only need extra things (like /questions/ or /index.cfm or /brand.cfm or whatever) if you are unable to disambiguate different pages without them.
Remember: this part of the URL identifies the page - it needs to be possible to identify a single page with a single URL - to put it another way, every page should have a unique URL, and every unique URL should be a different page. (Excluding the query string and page fragment parts.)
Again, using the SO example - there are more than just questions here, there are users and tags and so on too. so they couldn't just do stackoverflow.com/7275745/question-title because it's not clearly distinct from stackoverflow.com/651924/evik-james - which they solve by inserting /questions and /users into each of those to make it obvious what each one is.
Ultimately, the best URL system to use depends on what pages your site has and who the people using your site are - you need to consider these and come up with a suitable solution. Simpler URLs are better, but too much simplicity may cause confusion.
Hopefully this all makes sense?
Here is an answer based on what I know about SEO and what we have implemented:
The first thing that get searched and considered is your domain name, and thus picking something related to your domain name is very important
URL with query string has lower priority than the one that doesn't. The reason is that query string is associated with dynamic content that could change over time. The search engine might also deprioritize those with query string fearing that it might be used for SPAM and diluting the result of SEO itself
As for using the URL such as
http://stackoverflow.com/questions/7113295/sql-should-i-use-a-junction-table-or-not
As the search engine looks at both the domain and the path, having the question in the path will help the Search Engine and elevate the question as a more relevant page when someone typing part of the question in the search engine.
I am not an SEO expert, but the company I work for has a dedicated dept to managing the SEO of our site. They much prefer the params to be in the URI, rather than in the query string, and I'm sure they prefer this for a reason (not simply to make the web team's job slightly trickier... all though there could be an element of that ;-)
That said, the bulk of what they concern themselves with is the content within and composition of the page. The domain name and URL are insignificant compared to having good, relevant content in a well defined structure.
I am changing the way links show on my web site. I changed from allowing space in the URL to a new format where the URL has dashes where spaces used to be.
This effects only ONE string in the middle of the URL.
Google has indexed many of my pages with the old spaces in the URL but now they show up as 404s. Is it possible for me to put some code in place (temporary) that can redirect those URLs with spaces to the ones with dashes. I think it's a 403 redirect. A permanent redirect.
Thanks,
We wen't through the same thing recently. We ended up creating a LegacyController, which basically called into RedirectToActionPermanent or RedirectToRoutePermanent. (HTTP 301 - Moved Permanently).
Ideally, you should let IIS7 do the redirects, but we couldn't, because we needed to call our DB in order to figure out where to go.
If your redirect is as simple as you say it is (e.g no "dynamic" info in the URL), then you should use IIS.
Why don't you try to configure you routing to support both: legacy and new routes?
Basically /a b c/page and /a-b-c/page should be mapped to the same action of controller.
One of our website has URL like this : example.oursite.com. We decided to move our site with an URL like this www.oursite.com/example. To do this, we wrote a rewrite rule in our Apache server that redirect to our new URL with a code 301.
Many websites link to us with URLs of the form example.oursite.com/#id=23. The problem is that the redirection erase the hash part of the URL with IE. As far as I know, the hash part is never sent to the server.
I wanted to implement the redirection with javascript to keep the hash part, but the Search Engine will not be aware that our URL changed. (no code 301 returned)
I want the Search Engine to be notified of our new URL(301) because we need to transfer the page rank to our new URL.
Is there a way to redirect with a 301 code and keep the hash part(#id=23) of in the URL ?
Search engines do in fact care about hash tags, they frequently use them to highlight specific content on a page.
To the question, however, anchor locations are unfortunately not sent to the server as part of the HTTP request. If you want to redirect a user, you will need to do this in Javascript on the client side.
Good article: http://web.archive.org/web/20090508005814/http://www.mikeduncan.com/named-anchors-are-not-sent/
Seeing as the server will never see the # (ruling out 301 Redirects) and Google has deprecated their AJAX Crawling scheme, it seems that a front-end solution is the only way!
How I did it:
(function() {
var redirects = [
['#!/about', '/about'],
['#!/contact', '/contact'],
['#!/page-x', '/pageX']
]
for (var i=0; i<redirects.length; i++) {
if (window.location.hash == redirects[i][0]) {
window.location.replace(redirects[i][1]);
}
}
})();
I'm assuming that because Google crawlers do indeed execute Javascript, the new pages will be indexed properly.
I've put it in a <script> tag directly underneath the <title> tag, so that it get executed before any other JS/CSS. Note that this script should only be required for your index file.
I am fairly certain that the hash/page anchor/bookmark part of a URL is not indexed by search engines, and therefore has no effect on your page ranking. Doing a google search for "inurl:#" returns zero documents, so that backs up my assumption. Links from external sites will be indexed without the hash.
You are right in that the hash part isn't sent to the server, so as far as I am aware, there isn't a good way to be able to create a redirection url with the hash in it.
Because of this, it's up to the browser to correctly manage the hash during a redirect. Firefox 3.5 appears to do this successfully. If you append a hash to a URL that has a known redirect, you will see the URL change in the address bar to the new location, but the hash stays on there successfully.
Edit: In response to the comment below, if there isn't a hash sign in the external URL for the part you need, then it is entirely possible to rewrite the URL. An Apache rewrite rule would take care of it:
RewriteCond %{HTTP_HOST} !^exemple\.oursite\.com [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/(.*) http://www.oursite.com/exemple/$1 [L,R]
If you're not using Apache, then you'll have to look into the server docs for something similar.
Google has a special syntax for AJAX applications that is based on hash URLs: http://code.google.com/web/ajaxcrawling/docs/getting-started.html
You could create a page on the old address that catches all requests and redirects to the new site with the correct address and code.
I did something like that, but it was in asp.net, which I guess it's not the language you use. Anyway there should be a way to do this in any language.
When returning status 301, your server is supposed to return a 'Location:' header which points to the new location. In practice, the way this is implemented varies; some servers provide the full URL (netloc and path), some just provide the new path and expect the browser to look for that path on the original netloc. It sounds like your rewrite rule is stripping the path.
An easy way to see what the returned Location header is, in the python shell:
>>> import httplib
>>> conn = httplib.HTTPConnection('exemple.oursite.com')
>>> conn.request('HEAD', '/')
>>> res = conn.getresponse()
>>> print res.getheader('location')
I'm afraid I don't know enough about mod_rewrite to tell you how to do the rewrite rule correctly, but this should give you an idea of what your server is actually telling clients to do.
The search bots don't care about hash tags. And if you are using them for some kind of flash or AJAX calls, you have more serious problems than your 301 redirects don't work. Because unless you have the content in an alternate form, the search engines are not indexing your site and you are definitely suffering as far as SEO goes.
I registered my account so I can't edit.
zombat : I'm sorry I made a mistake in my comment. The link to our video is exemple.oursite.com/#video_id=233. In this case, my rewrite rule in Apache doesn't work.
Nick Berardi: We changed the way our links work. We don't use # anymore, only for backward compatibility