Migration of URL schema between servers - url

I'm the sysadmin of a web site that is being migrated from a URL schema of plain HTML files to a dynamic Content Management System.
As example the old URLS are like www.example.com/books/somefolder/book31Chapter23.html and the new ones are like www.cms.example.com/x?book=31
The site is hosted in two servers, one 'old' serving the static old URLS at the main domain www.example.com and one 'new' with the CMS at a subdomain www.cms.example.com.
Web servers are nginx and the CMS is written in yii (PHP) but this shouldn't matter conceptually for this question.
There are many URLS and only part of the content has been migrated to the new CMS, so we have three cases:
user requesting old URL of content that hasn't been migrated: in
this case the web server (nginx) serves the content from the 'old'
server.
user requesting new URL (migrated content): this is served
directly by the new server
user requesting old URL of content that has been migrated: the
request reaches the old server. There's a mapping list and we have
nginx do a temporaty redirect from the old url to the new url, so
traffic is redirected to the CMS in the new server.
So far this has been working and as new content is migrated the redirect mapping list is updated.
The problem is that I'd like the second server with the CMS to serve content as the main domain example.com and not a subdomain cms.example.com , that and also the temporary redirects seem to affect SEO for Google etc.
Ideally I want in the 3rd case to do a permanent redirect to the new CMS URL schema without using a subdomain, noting also that currently the CMS is hosted in a different server (I could merge everything in one if needed). Also for the 2nd case users would go to the new URL using the naked domain and not a subdomain.
How do I achieve this in the current set up (using nginx redirects, DNS or whatever is needed)? is there a better set up for migrating urls between two servers?
thanks!

Related

Expression Engine 2.5.5 - New domain overwritten by old domain

domainA = old url,
domainB = new url
EE 2.5.5 website ‘domainA’ is being re-branded as ‘domainB.’ Bluehost has both domains on the account; ‘domainB’ is now the primary domain and ‘domainA’ is parked (going to be an Add-on that redirects to ‘domainB’).
Whenever we try to visit ‘domainA’ the browser redirects to ‘domainB’ - it’s the same site, same files, etc. - but the URL needs to reflect the new name. Nothing else is changing.
(Multiple) Bluehost techs have said there must be a redirect in the EE code and/or DB. I have checked and changed every instance of ‘domainA’ that I could find in:
CP Home -> Admin -> General Config
/sitefolder/expressionengine/config/config.php
The database, particularly exp_sites
Are there any other instances of the original url hidden in the code?
After completely emptying the server and speaking with my fourth (4th!) Bluehost tech today, we discovered that domain forwarding was active on domainB (rerouting it to domainA) in the GoDaddy account (the domains are registered separate from the web host).

IIS 7 redirect and rewrite for retired domain

I have an old domain for a company that has merged with another company and they want to decommission the old site and redirect traffic to the new domain. OldCompany.com will now point to NewCompany.com. However, to keep their SEO rankings we also want to map the pages from the OldCompany.com domain to the corresponding pages on NewCompany.com.
I know it's possible to setup Rewrite Maps in IIS (I've done this), but if the OldCompany domain is now pointing to the NewCompany web server, but the site itself was not migrated, will I still be able to use rewrite rules in conjunction with redirects to point OldCompany.com/about.html to NewCompany.com/subDirectory/about.aspx?? Do I need to setup these pages in order to accomplish this? Will Rewrite rules work without the pages from the originating site in place?
Right now I am able to setup a HTTP Redirect for the entire OldCompany.com domain by just creating a new site in IIS and using the HTTP Redirect to do this. What I really want is the more granular solution outlined above, so that people get to the pages they are looking for and not just the new site's homepage.
You should not do the redirect with new site (in application level). This would just break any existing incoming links. Better approach is to redirect old domain (with the whole url path & query string that you may have) with 301 redirect and map all relevant old urls to urls in the new site.
Usually it's done with multiple steps:
Tell Google Webmaster Tools the new domain address (in case you use that)
Create IIS rewrite rule to redirect (with 301) old domain to the new domain, preserving path & query string info
Create IIS rewrite rules (in your new site) to map any old url to the new structure, with permanent redirect (301) or redirect to same other page when user can move forward, if exact page is not found from the new structure.
This will tell Google that the URLs have changed and point to the new location.

Azure domain url not showing my page routes

I got problem trying to set the URL of my site. The project is based on mvc azure.
Usually azure has URL like: xyz.cloudapp.net So when i set my site live i added a domain that points to the azure project. www.xyz.com.
The issue is that if i try to click on 'Contact' or 'About' buttons i want the URL on the browser to show up as www.xyz.com/about and www.xyz.com/Contact. But whenever i click on the about or contact button, the browser URL still shows as www.xyz.com.
I have over 50 pages in my site however, Google is only indexing it as one. Can some one please tell me how can i get this URL showing the pages i am routing too.
Use domain control panel, can routing with cname or A record. Use Url routing "/Contact" make sure "/"
For A record, use Azure Production VIP and enter the two recording. one hostname null(xyz.com), two hostname www(www.xyz.com). May also be a name you want to(my.xyz.com).
For cname, The only difference, dont use VIP. Instead use xyz.cloudapp.net
Use domain control panel for all these processes.
Sample Azure Url
Sample Cname Url
DNS Check see end of document WWW A Record

Map a domain to an MVC area

Anybody got any experience in mapping a domain to an MVC area?
Here's our situation:
Old system (still active but will soon redirect to new store):
www.example.com - our main site where we send traffic
store.example.com - our store site which is a completely separate site that is indexed in google
New system:
www.example.com - same site as before
www.example.com/store - new store site - built in an ASP.NET MVC area
Because store is a separate domain google gives it a separate entry in the search results. I'd like to keep this benefit in future but wondering whether or not there is a good way to map a domain (store.example.com) to the MVC area or if its just going to be more trouble than its worth.
PS. I'm not trying to keep existing indexing - its a completely separate store so thats not possible. I just want to redirect to the corresponding page in the new store. I'm just trying not to lose the benefit of two domains for SEO purposes.
I would use URL Rewriting, either in ASP.NET or in IIS7 Application and Request Routing (ARR) to change incoming requests for store.example.com/... to example.com/store/....
MVC will have no issue with this - it doesn't get to see anything but the new URL and it will generate links only for the new layout.
Other alternatives:
Create a website for the store.example.com that just does a wildcard 301 redirect for each page to the corresponding page on the new site.
If the URLs don't overlap at all, point the old domain to the new MVC site and add duplicate routes for each action, e.g. shop.example.com/info.aspx?item27 might have a route "/info.aspx/{pathinfo*}" ... which loads an Action that knows how to handle the old URL parameters and can do a Redirect to the new Action.
I have sites where there are many URLs mapped onto the same Action - in fact, every legacy URL that has ever been used for a page still works today, including even the old .ASPX URLs which are now served up by an MVC Action. Some legacy URLs are dealt with using a 301 response, others which legitimately have duplicate content on the site are handled as normal but the page also includes a canonical URL to point out which one is the preferred URL.

SSL-secured website best practices

I have a website (www.mydomain.com) that is secured with an SSL certificate. It is an ASP.NET website and I have forced certain pages via code to be required to use the https:// prefix. If they don't it will redirect them to the https:// equivalent. Is this a good practice? Is there an easier way to do this? Not every single page requires SSL.
Also, when the users use my URL in the form of mydomain.com instead of www.mydomain.com they get a certificate error because the certificate was registered for www.mydomain.com. Should I use the same approach as I am with the http:// and https:// issue I mentioned above? Or is there a better way of handling this?
Your approach sounds fine. In my current project, I force HTTPS when a user goes to my login page, (Based on a config flag which lets me test locally without dealing with needing a cert). This allows me to access other pages unsecured which is handy.
I have a couple places where our server grabs the output of other pages (rendering to html to PDF and fetching dynamic images for example). Because of our environment, our server can't resolve it's public name, so if we were to force ssl at the site we'd have to add, our internal IP address (or fake the domain name).
As for your second question you have two options to handle the www.example.com vs example.com. You can buy a certificate that allows you to have multiple domain names. These are known as UCC certificates.
Your second option is to redirect example.com to www.example.com or the other way around. Redirecting is a great option if want your content to be indexed by google or other search engines. Since they will see www.example.com and example.com as two seperate sites. This means that links to your sites will be split reducing your overall page rank.
You can configure sites in IIS to require a Cert but that would A) generate an error if someone isn't visiting with https and B) require all pages to use https. So, that won't work. You could put a filter on IIS that checks all requests and redirects them as https calls if they are on your encryption list. The obvious drawback here is the need to update your list of pages every time a new page is added (e.g. from an XML file or database) and restart the filter.
I think that you are probably correct in building code into the pages that require https that redirects to an https version if they arrive via http. As far as your cert error goes, you could redirect with a full path (that includes the www) instead of a relative path to fix this problem. If you have any questions about how to detect whether the call uses https OR how to get the full path of the current request please let me know. Both are pretty straightforward but I've got sample code if you need it.
UPDATE - Josh, the certs that handle multiple subdomains are called wildcard certs. The problem is that they are quite a bit more expensive than standard certs.
UPDATE 2: One other thing to consider is to use a Master page or derived class for the pages that need SSL. That way, instead of duplicating the code in each page you can just declare it as type SSLPage (or use the corresponding Master page) and have the Master/Parent class handle the redirect. Again, you'll need to do some URL processing if you take this approach but it is pretty trivial.
Following is something that can help you:
If it is fine to display all your website pages with https:// then you can simply update your code to use https:// and set two bindings in IIS. One is for http and another is for https. In this way, your website can be accessible through any of the protocol.
Your visitors are receiving a name mismatch error because the common name used in your SSL certificate is www.mydomain.com. Namecheap is providing RapidSSL certificates through which you can secure both names under single SSL. You can purchase this SSL for www.mydomain.com and it will automatically secure mydomain.com (i.e. without www).
Another option is you can write a code to redirect your visitors to www.mydomain.com website even if they browse mydomain.com.

Resources