Why SEOs are going to miss the Structured Data Testing Tool

Structured Data Testing Tool was a simple yet effective tool to diagnose problems with Schema markup code snippets whether those issues were related to invalid usage, syntax, or a property that was required or recommended. We could edit our code snippets directly in the tool until we saw a list of green checks. Not only that, but it was perfect for quickly visualizing which types and properties a webpage had provided, something highly useful for harder-to-read microdata. 

I know, it’s not even dead yet and I’m already referring to it with the past tense. *sobs gently*

The SDTT strikes nostalgia in the hearts of many of those Structured Data tinkerers and it was likely one of the first touchpoints SEOs had with building and validating their own Schema markup. Google’s decision to deprecate it to make way for the recently out-of-Beta Rich Results Testing Tool, isn’t a sad choice just because of that nostalgia, but because this feels like a downgrade masked as an improvement. 

Structured Data is about so much more than just Rich Results

For me, the main problem is that both tools’ purposes are completely different. Structured Data usage gives us a clean way to provide explicit machine-understandable context to Search Engines whereas Rich Results (generated by appropriate and supported Structured Data) are a SERP enrichment. The desired effects and goals are different.

Upon validating SD in the RRTT, we are presented with a huge statement of “This page is eligible (or not eligible) for Rich Results” which is likely going to instill within digital marketers that the sole purpose of SD is for Rich Snippets, whereas its possibilities are much more powerful than that alone, such as clearer machine understanding, promoting the usage of logical data hierarchies, email marketing enrichments, and solidifying our entities and their attributes in Knowledge Graphs. 

The Rich Results Testing Tool is currently very slow and clunky 

I’ll be honest, I wasn’t an absolute power user of the RRTT so while writing up this article I did extensive tests and I soon remembered why I wasn’t incorporating it into my daily business more often. The RRTT has since evolved into something attempting to be much more than a validator – it offers added functionality for checking rendering issues and page loading problems. 

All of this is well and good but we already have existing tools for those checks (not to mention, it’s available in GSC) and the speed of RRTT has likely suffered due to all of that added functionality. For some reason, Google also believes I’m a robot because I often fall into an annoying captcha check too. 

Making live code edits is tedious

One of the things I adored about SDTT was the ease of getting my prepared code snippets validated quickly. JSON-LD is highly accessible with no coding knowledge required to work with. However, it’s often the case that you’ll come across syntax issues such as a missing colon, or a comma in the wrong place. You could quickly apply those changes and run the SDTT validation again super quickly to double-check. 

RRTT, however, makes those code amendments almost impossible. Sure, you can copy the code, make your changes, and start again, but that’s nearly not as fast or as intuitive as SDTT is (was ????).

I’m not mad, just disappointed  

We often forget Google is a normal(ish) company with budgets and development struggles just like our own businesses. Tools will naturally be deprecated over time to make way for newer features. It’s just a shame when those newer features feel like a downgrade. 

Likely we will see the rise in popularity in third party tools that help us view Structured Data mark-up but seeing as the Google Search team encourage feedback highly, maybe these improvements will be added quickly before SDTT is laid to rest for good.