Removing Blockers for SEO Changes Using WebTrends Optimize

If changes are required to improve or repair visibility in search results, how can they effect changes in a timely fashion? For the last few years, a solution has been in place: 'meta CMS' systems, or 'edge SEO' to use the phrase coined by Dan Taylor. But are these systems the only way marketers can test SEO hypotheses?

Having the flexibility to make changes when the technical stack prevents progressive changes offers huge advantages:

• Problems and technical issues can be 'patched' to prevent them from eroding traffic and sales while the development team work to fix the issue in the core code.
• We can apply testing to see what works and what doesn't in organic search. Note that testing for SEO follows a different methodology than that of more common A/B or split testing, with which you may be more familiar in CRO work.
• Both users and search engines will see the changes, thereby avoiding 'cloaking' issues with Google and the need to block duplicate page versions.
• It also avoids issues with running test variations at full traffic for extended periods, something else Google says it doesn't like

However, the traditional approach of using Cloudflare usually presents a high technical barrier for implementation.

• Not all businesses have access to, or are prepared to use, tools like Cloudflare.
• For those that do, some solutions that measure traffic for testing require the Cloudflare servers to point to a different IP address.
  • This process can require extended review and sign-off for network security reasons, and may be a deal-killer for some brands.
• Cloudflare Workers don't have a UI; implementing on a Cloudflare-ready site requires users to code or build an interface that lets brands make changes easily.

So, despite the promise of being a 'silver bullet' to fix problems or improve SEO, adoption of 'edge' solutions remains relatively niche, and very few of the commercial products announced by providers seem to materialise.

For many years, we have developed sites using a high-speed JavaScript framework. One of the problems inherent in JavaScript is that, despite advances in crawl technology, Googlebot can still struggle to 'see' content and links generated by script calls. Scripted content can take longer to render, or even fail to render at all, and therefore may not be included in the search index or drive traffic.

To address this SEO limitation, we use a technical server-side rendering implementation, one of Google's preferred fallbacks, to ensure scripted pages are fully crawled and indexed. Doing so generates the full HTML for the page, including all content and links, making it easily visible and crawlable.

We are a longstanding partner of WebTrends Optimise (WTO) for CRO testing. The solution uses a simple JavaScript snippet installed on a website to run split tests on pages. The use of WebTrends tech raised the possibility: could we implement an SEO solution, one visible to search engines, using the WTO code injection snippet?

Typically, changes made to pages for CRO and split testing are designed not to be visible to search engines. Page variants are blocked (usually by tagging them with a canonical URL), and the scripted changes made on the page are typically minor and ignored by Google. CRO experimentation affects users while they are on the page, rather than the page's appearance in search results.

But if we could render a 'test' version of the page using this solution, it would give us the chance to present a different page to search engines, without having to use the more technically involved Cloudflare route. Any site that was already utilising WebTrends Optimize for conversion testing could also potentially have an edge SEO solution.

Fortunately, a chance presented itself for us to test the theory. Our client, LeaseCar, had seen a decline in organic traffic on its homepage. We determined the likely culprit was a legacy content template with excessive copy.

LeaseCar's legacy CMS makes it challenging for editors to update page copy without direct involvement from third-party developers (a problem many marketing teams and SEOs know all too well). However, the WTO testing snippet was already on the site due to ongoing work with conversion optimisation.

Therefore, we created an optimised version using the standard WTO page variant creation tools, but the initial implementation of it was only a scripted solution, effectively a page test. Although this showed a 'nicer' version of the page to users, the page code still reflected the original version, which resulted in lower search traffic. Following consultation with the WTO team, we were able to amend the rendered code to display the 'new' version.

We recorded initial visibility drops on the page at the end of May, with content formatting suspected as the primary factor.

• A test version was created using WTO and replaced with the live version at the start of June. However, the page's HTML code was still the 'original' version, and the page effectively operated as a CRO test rather than a SEO one.
• The test was changed to server rendering mid-July after consultation with the WebTrends team on how to achieve it. From this point, the HTML code and the visual appearance of the revised page matched.
• Clicks began returning to previous levels following the content improvements.
• We raised a development ticket to change the base code to the amended version.

• Improvements were subtle but only appeared after the page rendering change. Until this point, it was technically cloaked with the page code and visual appearance not matching.
• The changes involved removing a lot of additional content from other pages and reducing the homepage's overall length, rather than adding elements specifically designed to optimise for search terms.
• The changes confirmed that utilising WTO as a meta CMS system to effect changes for organic search is a viable method, and one that avoids extensive architectural changes for sites shifting to a Cloudflare solution.
• The existing problems about running a meta CMS still apply. Having a rendered/public version of a page that differs from the base code version can still cause issues for developers or additional page testing.
• It remains a priority to implement improvements to the site's core code as soon as possible.
• The use of WebTrends Optimize is a valid solution for mitigating search problems when blockers are in place for directly editing a site's content, and can be brought into play relatively quickly, especially if the tool is already in place for CRO testing.

To enquire further about how we can implement WebTrends technology to assist with SEO testing and optimisation, please get in touch.