Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm running a website that uses an SSH certificate. This leaves for potential CNames:
https: //example.com
https: //www.example.com
http: //example.com
http: //www.example.com
From an SEO perspective I understand that it's best to choose one and then set up 301 redirects.
Within Google Webmaster tools one may choose www. and non www. versions. I arbitrarily chose the non www. version. No particular reason.
I then came on this forum for some code on how to edit my htaccess file to redirect all URLs to http://example.com.
I wondered if there was a best practice here. Does choosing a non https version nullify the SSH? From a search perspective are either of the 4 versions better from an SEO standpoint?
Anyone have any experience of thoughts on which of the 4 to choose?
I presume that when you say “SSH” (Secure Shell), you mean “SSL” (Secure Sockets Layer).
“http:” means normal unencrypted insecure http. “https:” means http layered on top of SSL/TLS, which provides encryption and authentication of the website. So yes, using the non-https version means you don't get the security benefits of SSL.
SSL certificates are usually only valid for a single specific hostname. e.g. if your webserver has a certificate valid only for www.example.com, but someone tries to access https://example.com, they will get either an error message or a scary warning. A CNAME is not enough: you need a valid certificate for that name as well. So use the name specified in your certificate. (If, of course, you have paid extra for a certificate that is valid for both example.com and www.example.com, then you may choose between them. But as I probably know less than you about SEO I shall not advise which one is best.)
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I was asking myself, wether it would be okay to enforce HTTPS over normal HTTP, by 301 redirecting every HTTP request to its HTTPS counterpart.
Are there backwards compatibility issues (IE, I'm looking at you) or any other drawbacks? How do search engines handle this? Do you already have experience with this? What are your opinions?
Google themselves also enforce HTTPS, but not always. If you're sending an IE6/7 User-Agent header, you won't be redirected. Should I allow my users to use HTTP, if they want to?
The Electronic Frontier Foundation understandably advises users to always use HTTPS. Can I make that decision for my users and enforce HTTPS? Is there a reason to not use HTTP at all?
Enforcing HTTPS is becoming more and more common. We started using HTTPS where I worked previously (site had millions of hits per week) due to the fact that Firefox was assuming HTTPS if no protocol is defined, meaning users could type "websitename.com" and not find our website at all, as we only served over HTTP.
I'm sure there were SEO implications behind redirects, but I seem to recall that 301 was the suggested route. Definitely not 302.
Internet Explorer didn't give us any issues for 8, 9 or 10 - prior versions I couldn't say. Hopefully someone else here will know more regarding IE7. There is a link here which explains a few issues, though: http://msdn.microsoft.com/en-us/library/bb250503(v=vs.85).aspx
Honestly in this day an age, the number of people using browsers which do not handle HTTPS are likely to be few - it's such a standard now. My opinion is that we need to try and progress things rather than build things around that total minority who refuse to get with the times. Technology is about progress, after all.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I've noticed that a lot of websites redirect you from the unqualified domain to the www. subdomain. Is that the best practice as far as webapps go?
But not everyone does it. For example, heroku.com redirects you to www.heroku.com, but stackoverflow.com does the opposite, redirecting you from www.stackoverflow.com to stackoverflow.com.
What's the best practice here, if there is one, and why?
The web right now is leaning towards not using the 'www'. However, you should always make sure (right now anyway) that both www.domainname.com goes to the same place as domainname.com.
As for which you set as the main server name, and which is the alias, thats kind of up to you, or maybe even your target market.
You can get either to work and they both should be setup to function.
There is one difference in the DNS handling of them. A subdomain www can be re-routed with a CNAME record to another hostname, which many CDNs require (e.g. Akamai) so sites on Akamai could not use the raw top-level-domain as their final URL. A straight top-level-domain (e.g. example.com) is routed to an IP only (for A and AAAA records).
If you're just directing to your own server though without getting fancy about hostnames it doesn't make any difference, but if you're going to get into working with CDNs, it probably will make a difference.
My mom always puts "www" on the front of everything. So if I tell her "https colon slash slash secure dot example dot com", she'll likely just hit http://www.example.com/, or if I'm lucky, https://www.secure.example.com/. The world is mired in tradition. As SilicaGel said, you really need to support both.
Of course, from a technical standpoint, it matters not in the least ... except that the unqualified domain SHOULD also have some other services running on it, like SMTP (in case MX hosts can't be determined). Note that what SHOULD happen is often not what actually happens. Far too many people fail to follow standards.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 6 years ago.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Improve this question
I bought domain www.mydomain.com from godaddy.com. I hosted it at www.000webhost.com (free web-domain-hosting site). I created a subdomain subdomain.mydomain.com through ccpanel of 000webhost.
I want that subdomain to be diverted to my blog http://myblog.blogspot.in/
Right now I have a folder named subdomain in my root folder. What shall I upload in that folder so that It gets redirected to my blog?
Most domain name registrars provide a free redirection service, I think GoDaddy does too. Why not just do that?
If you want to get more technical, then redirection can be done (in code) in a few ways (in order of difficulty).
Frames. Welcome back to 1999-2002. Just put a static HTML <frameset> page up and load your target page in a whole-page frame. Your users will hate you.
<meta> redirection. Another staple from the late-1990s school of web design. Put <meta http-equiv="refresh" content="5;URL='http://example.com/'" /> in your HTML page.
Javascript redirection. In a <script> block in your page call window.location = "http://www.example.com";
Server-side redirection. All server-side redirections are done by setting the Location: HTTP header. How you do this depends on your server platform:
PHP: header('Location: http://www.example.com');
ASP: Response.Redirect("http://www.example.com") (also works for ASP.NET)
ASP.NET MVC: return Redirect("http://www.example.com"); (call inside Controller action method)
.htaccess: A bit more complicated. See the link below.
There's a whole load of redirections in a variety of platforms and languages here: http://www.webconfs.com/how-to-redirect-a-webpage.php/
You could technically use the Go Daddy subdomain forwarding function from within your Domain Manager. http://support.godaddy.com/help/article/4040/managing-a-domain-names-forwarded-subdomains
Once added, you will need to point an A record subdomain from where your DNS is actually hosted (www.000webhost.com) to the Go Daddy forwarding IP 64.202.189.170.
Use either a .htaccess file or create a PHP script with the following:
<?php
header('HTTP/1.1 301 Moved Permanently');
header('Location: http://the-network-king.blogspot.in');
To create a 301 redirect.
and save the file under name index.php else it wont pick up file.
I am not familiar with www.000webhost.com, but if they are using cPanel, you should be able to do this very easily from within cPanel. Just select "Redirects" in the "Domains" section.
Having your site behind CloudFlare is a good idea to begin with, but if redirection is all you want, they offer "Page Rules"
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Should my site be a www or non-www address? This is a pretty basic question. I wanted to see what people consider to be the best practice here. The reason I have to pick is I need to buy an SSL certificate for one or the other. Of course I can redirect to the one I pick on the back-end and the technicals are not a problem, but are there any opinions on which to pick and why?
Id answer both? Some sellers will offer both as standard. I believe Go Daddy offer the service help topic below.
http://help.godaddy.com/topic/234/article/850
The host name is essentially a convenience for your users to remember the name. From this point of view, it's mainly a marketing decision. If you've promoted example.com use that, if you've promoted www.example.com use that.
Redirections on the back-end as you seem to suggest don't sound like a good idea. The point of the certificate is to let your user be able to verify the identity of your server. If you only have example.com and if they try www.example.com over HTTPS, they'll first get a warning about an invalid certificate (thus they shouldn't follow the redirection).
You may be able to get both. Some CAs issue certificates that have SANs for example.com and www.example.com (sometimes for the same price or a little bit more, I think).
My vote is for the shorter one. Comparing your question to writing for the web, and writing in general - strive for maximum salience in the fewest words possible. 4 saved bytes can come in handy with 3rd party services like Twitter.
SSL certs support multiple names and also support wildcard pattern matching. I would add 2 names to the cert; you don't need to choose just one.
Consider adding the two patterns site.com and *.site.com to cover you, if you need to use an additional hostname / subdomain in the future.
Please note that both are needed if you wish to access the server as site.com, as the name site.com does not match the pattern *.site.com
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I have a client app that faces the internet, but only clients will access. The site should never be indexed or crawled or viewed outside of our clients. We always concerned about DDOS and attempts to gain access. If the system can add one more level of being hidden, or harder to find, I don't see the negatives.
Users will never have to enter the domain name (think kiosks), and admins can use bookmarks. Yes, security by obscurity is no solution and never relied upon. But if you can add it to an existing and robust secured system, why not?
Is there any downside to having a random domain name like j398sh3-3nj23j.com?
I would love to hear some thoughts and opinions.
If you're never using where anyone will see it (even by rDNS on an incoming connection from your server), then the only real drawback is that you're paying for it when you could as easily use a random subdomain under a domain you already control (e.g. j398sh3-3nj23j.example.com).
But it'll provide zero protection from DDOS or attempts to gain access, as anyone who is in a position to extract a normal domain name from your client app will probably be able to extract this random domain name just as easily, and they may not even bother with domain names and just get the IP address your client is connecting to anyway.
Emphatically speaking, that's useless. As was pointed out above, using some subdomain of your own would cost less, be saner, and have more utility.
If you have a number of nodes on a private network that is not physically private, use a good VPN system and machine authentication with certificates. If you do that, nothing is accessible except the Internet-facing VPN software, and that can easily ignore anything that's not legitimate.