Selecting SEO elements to test

The means and inclination to test SEO changes in the industry is growing (finally), but the willingness to test does not always mean that it will be successful and worthwhile.

Not everything is worth trying and not everything is easy to try. So what follows are some of my lessons/examples from testing SEO changes (split testing or otherwise).

What to test

How do we decide what to test? Choosing the right test is not always as simple as “which one will have the greatest impact”. Here are some considerations when choosing a test:

• Speed ​​of change – How fast/easy is it to make the change? Even if you can change the page with the test tool, do you have what you need (logic/information) to make the change?
• Who else in the company needs to sign it? If you have a significant impact on the user experience and will need the attention of other teams – such as the UX/eCommerce teams – you can rarely run these tests without getting buy-in first.
• Avoid conflict with UX testing – If other “conventional” UX tests are being run, you need to make sure you don’t make any SEO changes while other testing is going on. The two tests can contradict each other and rule out any validity of the results.
• Impact of Change – Do you think the test is worth implementing? Sometimes easy tests aren’t worth testing.
• Is the page likely to be crawled/indexed by Google? – If you have a large/complex site or JavaScript is required to render key content, Google may take too long to index the test bucket. You want your test completed in 4-6 weeks (maximum). If Google doesn’t pick up the changes within two weeks, it can invalidate the results.

With the above in mind, let’s get to the examples.

SEO Testing Case Matrix

To help you capture the considerations when running tests, the following matrix should give you an idea of ​​what to look for in your design.

Test	Test example	Type of test	Expected result	KPIs	Buy-in required from*	Potential impact
Testing the page title	Adding the date to the destination page titles for the travel stamp.	Improvements on SERPs	Increases keyword relevancy rankings and potentially improves CTR	Clicks, impressions, CTR	Brand messaging team	Low-medium
Testing the meta description	Rewrote the meta description to include the number of products available for PLP	Improvements on SERPs	Increases click-through rate based on enriched product information	CTR	Brand messaging team	Low-medium
Title structure	Labeling all product names with a label on the PLP	Markup	Incorporating title structure into your products increases relevance and therefore rankings	Clicks, impressions	None	Low-medium
Alt text/File name	Using the product name title as the alt text for the first image on the PDP	Markup	Image optimization increases rankings in both image and text searches	Clicks, impressions	None	Low-medium
Scheme	We present the product scheme	Markup/On-SERP improvements	A product scheme encourages more clicks and (potentially) rankings	Clicks, impressions, CTR	None	Low-medium
Contextual linking	Add a new inline widget to link to related categories in the blog	Internal linking	It introduces more relevant internal links to other key areas on the site	Clicks, impressions	None	Medium high
Content positioning	Moving the content area from the bottom of PLPs to the top	Content	The assumption that positioning content more prominently boosts rankings	Clicks, impressions	Brand Team, E-Commerce	Medium high
Content visibility	Exposing harmonics under load versus keeping them hidden	Content	Making “hidden” content visible on load (without a click) improves rankings	Clicks, impressions	Brand Team, E-Commerce	Medium high

This list is not exhaustive, the brilliant thing about testing is that every site, niche and technology setup will offer opportunities to test in ways that will surprise and shock you.

*The team required to implement a technical change is an assumption we will have for everything here.

Insights into different types of SEO changes/tests

Trials and changes will always produce different results depending on the location and circumstances surrounding the trial itself. In some cases, what benefits one site may actually harm another. This means that using learning from some tests on other sites is not always wise.
Even with that in mind, it’s worth sharing some aspects of testing and testing experiences, even if it helps develop your own thinking and approach to doing it yourself.

Title/meta descriptions can be fertile ground

If your titles/descriptions aren’t particularly good, but you don’t have the resources to change them all, a split test is a great opportunity.

It’s a relatively quick and easy test to use (with the right logic available) and it’s easy to see in the SERPs if Google has “seen” the test.

Trying to change your CTR can be frustrating

Changing the RPK can be challenging because you assume it will have a net benefit to the user experience on the SERPs. Because you often make these changes at scale in a test group, some people may see improvements, while others may make things worse.

A classic example is adding review ratings via a scheme or changing the title can show some products/services that people rate well. However, anything with a bad rating will also receive more attention. Putting bad reviews in SERPs often doesn’t help with clicks!

Markup changes can be quick and easy

Label changes can be relatively easy. This can be very useful for justifying changes to page templates to introduce “best practices” in headings or schema. Perhaps it can be used to justify an altogether more “radical” change without fully implementing it.

While changing the label can be a good test, the results aren’t always relevant.

Small changes often equal small improvements, so you’ll need to consider this when making your decision.

You can also hypothesize losses

Depending on the circumstances of the test, performance degradation based on the change can be predicted. If the other team wants to make a change, you’re not sure about it. You can insist on testing to confirm the hypothesis that this is a bad idea.

Testing elements of the entire site

Testing elements of the entire website (for example, the main menu or the footer) is very problematic as an A/B test. We need to ensure that we are serving two roughly equal groups of pages to Google (in terms of traffic size and user behavior) as a test and a control – but this is not possible with a persistent element. A test where the menu is only different in some cases and not in others will be bad for search engines and users.

The primary solution in this case would be to perform a time-based test – that is, make a change and then run a causal impact analysis on the data. Here you lose the benefits of an A/B test – but the alternatives are not strong enough to provide reliable conclusions.

It’s time to test

When you have strong hypothesispurchase of relevant stakeholders, ability to test/measure resultsand the means to take the test itself (if you A/B testing), you are in the best position to get some great insights and data.