It’s not uncommon for new websites to be developed on a temporary URL or IP address. This allows developers to code the site where it can be reviewed, tested and tweaked by the marketing team without an unfinished site being accessible to the masses.
Most site issues can be tested and tweaked while on that development URL, and you can be confident that they will work as advertised once the live site rolls out. However, the dev URL itself presents some issues that can make some previously fixed issues re-appear on the live site.
Broken links: Any internal site link that uses an absolute URL (the full URL starting with ‘http’) will need to be changed once a site moves from the dev server to going live. This is why many developers prefer to use relative urls (everything after ‘site.com’). Relative URLs link to the relative position of the page, assuming the same URL. As a web marketer I always prefer absolute URLs, but we can save that discussion for another day.
Doing a global change for absolute URLs shouldn’t be that hard. A simple find/replace should do the trick. But sometimes things get missed. Once the site goes live, it’s important to rerun all your broken link checks to make sure all absolute URLs have been changed and no more broken links remain.
301 Redirect Old URLs: See Tip #1.
Change Redirecting Links: New site launches often come with a number of old URLs redirecting to their new location. That’s great. But don’t leave those old links in the content of your pages. Redirecting links are not a problem for visitors since they are taken to the intended page anyway, but every redirecting link does cause a small loss in link value as it goes through the hop.
To ensure every internal link maintains maximum value, be sure to use the destination URL of each link rather than the old URL that is set up to redirecting to the destination URL.
If your website has undergone multiple revisions, it’s possible you already have a list of URLs redirecting from an even older version of your URLs to the version of the site. It’s a good idea to go back and change those redirecting URLs to point to the brand new URLs. Search engines will support 3-5 redirection hops, but each hop may cause a loss in value. By updating the older redirects, you reduce the number of hops down to one for minimum loss.
Site Speed: Finally, check your site speed. Many dev servers are local and therefore tend to be a lot speedier than the live server. Checking for site speed on the dev server is important, but once the site is live, check it again as new opportunities for increasing the speed may present themselves. Check for anything that might be slowing down the visitor’s on-site experience, such as oversized images and excessive code bloat. Even shaving milliseconds off loading times can make noticeable difference.
There are certainly a lot more performance checks to do immediately after launching a new site, but these are the most frequently overlooked. Always check these issues while on the dev server, but be sure to do so again once the site goes live to ensure nothing gets missed.