Changing your company’s domain name should be a rare occurrence, but we can teach you how to do it without completely dropping your current search engine rankings.  Changing it without proper redirect settings can ruin your rankings.

For the purpose of demonstration, we’ll use the example.* domain names.  Let’s say we have a highly-ranked site at  This site was running for years, with a healthy number of users, backlinks, etc.  Eventually, we were able to acquire  No matter what the marketing of other Top-Level Domains (TLD) says, .com is the most sought-after TLD that exists and is the most memorable for people.  So, we have our domain, and we want it to be our primary site.

AppLite - Domain name switching

Running another Virtual Host to handle our new .com is no problem.  We can configure it and start using it in minutes (assuming certain setup scenarios).  Email addresses, digital promotional material, social media links, etc. can be updated quickly as well.  What is not simple or necessary is changing third-party links from .org to .com – We need handle those existing references to our site in a transparent way.  These third-party sites are search engines, blogs, or any external site that references our site.

Let’s go through the steps for this process.  We’ll begin after domain name registration of  For demonstration purposes, we’ll be like Hollywood and use a non-routable IP address of

  1. Pre-planning
    1. Ensure the links in HTML, Javascript, and CSS have no domain name unless there’s a specific reason to do so. Specifically, your links are a path-only.  Examples: “”  Change to: “/graphics/logo.png”.  In almost all scenarios, you don’t need to specify your own domain because the browser knows what domain it’s on.  If you’re using a CMS tool that automatically uses the domain name (like WordPress), then update your links after the switchover.  This doesn’t apply to elements linking to a CDN.From the *nix command line, you can easily search for link references to the domain with grep:
      grep -r “” /path/to/your/documentroot
    2. Create graphics referencing the new domain name, if applicable.
    3. Prepare to change email address references to the new domain… assuming you configured your mail server to handle the new domain.
  2. DNS Configuration
    In your domain registrar’s control panel, point the following hosts to your servers IP address. This is assuming you want to use the same server and IP address as
    DNS for
    Host                       Type                      Destination IP
    @                            A                             257.258.84
    www                     CNAME                                @                            (or the domain name “”, depending on the registrar)This handles both hostnames of  and
    Some DNS control panels can redirect the request to the new domain, but they might be for the whole domain-only.  This means a full URI like //  could redirect to // only!  If your provider can 301/302 redirect wildcard URIs, then you might be done on this step.
  3. www or no www?
    To a search engine, it matters, but not in the sense of one being better than the other. If you haven’t decided on this yet, decide if a search engine is to see your site with or without the www.  Your redirects should be one of these.  For your business card or email signature, it doesn’t matter, as long as the site works.
    2018/09 – Update:  Google’s Chrome browser recently dropped the display of “www.” from the address bar.  After much outcry, it was reverted, but most agree that it will eventually go back to hiding “www.”, and other browsers will follow suit.  Therefore, we wholly recommend dropping it if you have the choice.  Aside from this, there’s also the argument of less to type… people don’t want to read too much, nor do they want to type more than they have to.
  4. Server Configuration (Example with CentOS 7/Apache 2 Virtual Host)
    We will add the new virtual hosts or and (or the wildcard *
    Depending on your Linux distribution, your httpd configuration files are commonly located in /etc/httpd or /etc/apache. We like to have separate files for each domain being hosted, and just run an include on a virtualhosts directory, like so:
    Include conf.d/virtualhosts/*.conf
    Then, we modify a file named /etc/httpd/conf.d/virtualhosts/
    or, because we have and, we can copy the old one to a new file called example.conf, then delete the old
    This sample is for port 80 to keep it simple.  We recommend you run everything on https port 443.  The redirect below will go to the https site.

    <VirtualHost _default_:80>
    DocumentRoot "/opt/web/"
    CustomLog "/var/log/httpd/" "combined"
    ErrorLog "/var/log/httpd/"
    RewriteEngine on
    # If the requested domain handled by this virtualhost is NOT, redirect it:
    RewriteCond %{HTTP_HOST} !^ [NC]
    RewriteRule ^(.*)$$1 [L,NC,R=301]

    Run “apachectl configtest” to double-check your directives, then “apachectl restart”.If you’re like me, you’ll do the extra work to change paths and primary naming to “”, but there are no functional problems with keeping the server’s internal references to “”.You can do these redirects at the page-level, but that can be a very tedious process if you’re not using a good template system.  If you have to use this method, search for “301 redirects in <your site’s development language>”.
  1. If available, use search engine tools to notify them of the change:
    1. Google
      Webmaster Tools:
      Change of address:
    2. Bing
      Webmaster Tools:
      Change of address:
    3. For other search engines, it’s easy to find by searching for “webmaster tools” or “website change of address”
  1. Test
    1. Verify in your browser’s source code viewer that there are no longer references to the old .org domain. Testing in your browsers private mode may be preferable to ensure you’re not viewing an old version of the page.
    2. Verify that when you visit a URL on the old .org domain, it immediately redirects to the same URL on the .com domain.
    3. Tail your web server’s error logs to make sure there are not 404 errors.

This setup should be kept in-place for as long as your website exists.

What about a website where you lost the domain name, and had to create a new one?

The most common reason for this is renewal lapse.  You must set calendar reminders for your domain expiration, and you must have multiple contact methods entered in your registrars contact settings.  Even if you have auto-renew turned on, remember that your payment method will eventually expire.  Each registrar has its own methods of reminding you, but you should not rely on them reminding you.  What if you updated your contact information to [email protected], handled it through Gmail, and Gmail marks all messages from that registrar as Junk?  What if the person handling that address is no longer working for you?

Again – set calendar reminders and have multiple contact methods set!  I’ve seen this happen to business owners many times – set your reminders!  You can alternatively set reminders to login to your registrar every quarter, and renew any domain names that have approaching expiration dates.

Happy Domain Hunting!