How should you build and test a new website? Set up a test environment first, then validate functionality and content

A new website can be built in a separate test environment. After checking its content and functionality, verify its appearance across devices, search settings, and analytics data collection. Fix any issues and retest before making it public. For a redesign of an existing website, a copy of the site and database can serve as the testing foundation; a brand-new website can be built on a separate subdomain. The guidance below focuses on test environments and pre-launch checks. Specific checks will still depend on the site’s functionality—a single SEO audit is not enough to establish that a website is ready.

Isolate the test environment first and decide when to make the site public

Semrush’s migration guide recommends first copying the website files and database when redesigning a site, then adjusting the settings so the copy connects to the test database and URL. This prevents changes from affecting the live site. If the live site uses a CDN, configure it in the test environment as well to check compatibility. This approach applies to migrating an existing website; it does not mean a brand-new website must start with a copy.

Before the site is ready to go public, you can add password protection and a temporary noindex directive. These serve different purposes: a password restricts access, while noindex asks search engines not to index pages and should not be treated as a confidentiality measure. Google’s guidance on launching an ecommerce website also notes that keeping a site fully closed to the public can maintain confidentiality while allowing testers to check it, but the trade-off is that it may take longer to appear in search results and the Shopping tab after launch.

Test the publishing workflow alongside the content

For a redesign, simply moving the old content over is not advisable. Semrush recommends first taking stock of underperforming, duplicate, and outdated content, deciding what to improve, merge, or delete, and prioritizing pages that already generate more traffic and conversions.

• Complete page titles, descriptions, and headings, check internal links, and remove placeholder text.
• Have the people responsible for content test publishing content and links, rather than relying solely on developers to check how pages look.
• Check image dimensions, field names, publication dates and time zones, and whether caching interferes with content display.

The last two points draw on the ConocoPhillips redesign case study presented by Nielsen Norman Group in 2021: local content managers tested the site early, identified these issues, and resolved them before launch. These are lessons from a case study, not official acceptance criteria that apply to every website.

Check across devices, not just whether the homepage works

Check functionality and appearance on both desktop and mobile devices, covering the major browsers. In a 2018 article on checking interactive content, Screaming Frog noted that a piece of content appeared to work properly on desktop and mobile but still showed gaps at the edges on an ultrawide screen. Where feasible, include widescreen and high-resolution environments in testing. If content can be embedded, test the embed code separately; a working original page is not a substitute for an embed test.

Retest after fixes, then review launch settings

A technical SEO audit should address serious errors first, then review warnings and notices. Run it again after making fixes. Before launch, also check that canonical tags point to the intended versions and confirm that analytics tools actually receive data for the events you intend to track—not merely that the code has been installed.

Finally, check each page that is ready to go public and intended for indexing to ensure that temporary development restrictions and noindex directives have been removed. Also review compliance matters such as the privacy policy. These checks serve different purposes: search settings cannot replace functional testing, and working data collection does not mean the publishing workflow is free of problems.