SEO Effective Basic Technical Steps

1.Establish project scope

The first step is to determine how the scope of the project will affect SEO (and, ideally, involve a technical SEO in its inception from the planning stages).

General questions such as the project motivation (what problem is being solved?), deadlines, priorities, team structure, project leader, key contacts, and the best format for feedback/updates (email / phone / scrum / meeting?) are just as important as technical questions at this stage, as they can help gauge the best way to test and establish authority.

Establish SEO authority

Ensure the project leader and dev team understand the impact that small changes can make to traffic and/or sales, and the importance of taking technical SEO testing into account.

Determine the development release cycle

While traditional projects demand that lots of changes are released at once, many development teams now opt for Agile/Lean projects, releasing selected changes in small batches. This makes it easier to roll-back and identify a cause of any issues (providing the changes are recorded).

However, the more frequent the release, the less time there will be to gather data for testing purposes: cycles for some releases can be reduced to days and are often based on the amount of development work required rather than the time it takes to test or the risks associated with the changes. SEO’s main job at this point is to make sure there is enough time to crawl the staging to compare to the live site.

Obtain technical specs and change logs

Get full information on what’s being changed in a technical spec, and request access to a changelog so that you can refer back post-release if there are any issues.

Now is a good time to identify which URLs (or sets of URLs) will be impacted by the changes, including what is at risk of being changed in error, so that the most efficient testing can be set up.

2.Access the staging environments, Search Console and analytics

Getting access to the staging site

Gaining access to the staging environment at this stage for the purpose of crawling it before putting it live means fewer delays when it comes to testing since it’s better to come across complications sooner rather than later.

Use your crawler to gain staging access with a static IP address, custom user agent, or basic username and password and crawl them in the same way as crawling a live site.

Crawling a staging site should always be discussed with the development team before running any significant crawls, as a staging environment is often run on less powerful servers than the live one. Big crawls can impact the speed at which the crawler can perform and also cause disruption to the development work if they affect the performance of the server.

Establish access to Search Console and analytics

Now is also a good time to make sure you and whoever is responsible for SEO has access to all versions (www/non-www and HTTP/HTTPS) of the site in Search Console and sufficient access to analytics to track if there are search performance issues after the changes are put live.

3. Prepare data

Decide how best to crawl the staging site now and configure the crawl so crawling can start as soon as you’re given the nod. It’s sometimes a good idea to limit the crawl to a few levels of the site if you’re pushed for testing time, depending on what will be impacted by the changes.

If the staging site is disallowed in the robots.txt file, copy the live site robots.txt directives into the overwrite feature of the crawler you are using.

Gather data on live site

Using your crawler's Test vs Live feature, you can compare the staging environment (complete with the new changes) to the live one. This highlights any changes that have been made that might have a negative impact on search engine rankings and traffic.

To prepare for comparing the live site to the staging one, run a fresh web crawl on the live site.Using a crawler for testing also means you can test new XML Sitemaps and robots.txt changes before they go live, crawl the site with modified URLs and test the impact of removing parameters.

4.Test on staging: pre-release crawl

Once all the changes have been made to the staging site, then it’s time to start crawling: this is where things get really interesting, and when all the prep you’ve done will come in handy.Once the report has run, pay particular attention to the dashboard, where you can see the changes that have occurred between crawls.

5. Test on live: post-release crawl

Run another crawl of the live site immediately after the release goes live, limited to a few levels to get quick results, and compare to the live list crawls that were run at the start of the process.

Watch the Search Console Crawl Error report and your analytics package (plus any other monitoring software you have available) like a hawk for a few days after release to watch for potential problems that slipped through the net during the testing process. Bear in mind that crawl errors will be delayed by two or three days in Google Search Console, so your analytics package is a better tool for immediate feedback.