Ste : Pre-launch testing

[kexej28769@nongnue]

The sooner you can start testing, the better. Some things need to be fully implemented to be tested, but others don’t. For example, user journey issues can be identified early with prototypes or wireframe designs. Content-related issues or content discrepancies between the old and new site (e.g. between desktop and mobile sites) can also be identified early on. But more technical components should only be tested once they’re fully implemented — things like redirects, canonical tags, armenia number data XML sitemaps. The earlier issues are identified, the more likely they are to be addressed before the new site goes live. Identifying specific types of issues at a later stage is not cost-effective, will require more resources, and can cause significant delays. Poor testing and not allowing the time needed to thoroughly test all the building blocks that can impact SEO and UX performance can lead to disastrous results soon after a new site goes live.

Ensuring that search engines cannot access the staging/test site
Before making a new site available on a staging/testing environment, take some precautions to prevent search engines from indexing it. There are a few different ways to do this, each with different advantages and disadvantages.

Site available for specific IPs (most recommended)
Making the test site available only to specific (whitelisted) IP addresses is a very effective way to prevent search engines from crawling it. Anyone trying to access the test site's URL will not be able to see the content unless their IP is whitelisted. The main advantage is that whitelisted users can easily access and crawl the site without any problems. The only downside is that third-party web-based tools (such as Google's tools) cannot be used due to IP restrictions.