The road to internal linking suggestions in Yoast SEO 4.0

Today, we are releasing a new Premium feature for doing internal linking suggestions. Last week, I wrote a post on the SEO blog explaining how we can do this fast and without using up a lot of resources on the server side. Building this would not have been possible without much of the work we did in the past year. In this post, I will describe the steps that led to the creation of this new feature.

The move towards JavaScript: Yoast SEO 3.0

In November 2015, we released Yoast SEO 3.0, which moved our content analysis from the server to the client side and made it real time. Users did not have to save their post anymore before they could get feedback. The PHP code used to analyze the content before was quite old and resource heavy on the server side. It was hard to extend and add new checks. In addition to that, it was also hard to improve the user interface and overall user experience of the content analysis. YoastSEO.js changed all of this.

In the past year, we’ve been able to expand the content analysis with specific readability checks and make it available for more languages than just English. When adding new analysis functionality, it’s now easy to reuse JavaScript modules we’ve written for word and sentence segmentation, counting words and syllables. A major takeaway in the context of the internal linking feature we are releasing today is that we learned we could leverage the browser to do complex operations, like content analysis and calculating an SEO score.

We learned we could leverage the browser to do complex operations, like analyzing content and calculating an SEO score.

Rethinking the content analysis

In Yoast SEO Premium 3.7, we added an insights box that shows a list of prominent words in a text. The idea for this feature was conceived more than a year earlier. At that time, we were in the process of rewriting the content analysis in JavaScript. The focus on our content analysis tool inspired me to reflect a bit on the actual tool. I noticed that all of our analysis was normative. We didn’t provide the user with any descriptive data about the text.

The issue on GitHub discussing the possibility of descriptive analysis dates back to June 4th, 2015. A day later the idea was born to use a post’s prominent words as an index to query related content. Apparently, revisiting existing functionality can lead to fresh, new ideas for other useful features.

Apparently, revisiting existing functionality can lead to fresh, new ideas for other useful features.

Today, one and a half years later, this functionality makes it into Yoast SEO Premium.

So, what took us so long?

Probably a big reason this took some time to ship is simply that we focused on other features first. But the truth is that this feature builds upon a lot of functionality we added in the past year. Now, we can build internal linking suggestions,

• because we’ve moved our content analysis to JavaScript (since 3.0).
• because we’ve written more advanced text segmentation and tokenization code that we can now easily reuse (since 3.1).
• because we’are able to collect insights about the most prominent words in a text (since 3.7).

Leveraging the WordPress Content API

Another thing that helped is a WordPress feature that shipped with the latest 4.7 version of WordPress. This version includes the Content API endpoints for the WordPress REST API. With those, we can more easily store prominent words as terms that we use to query for related content. WordPress shipping with a Content API makes it easier to build these kinds of JavaScript-based features.

Conclusion

It can take quite a few steps to get to a new feature. I think the story about this particular feature is interesting because it shows how many separate building blocks can make up a new feature. New ideas can grow from reviewing existing functionality. Lessons can be learned from practice, and some features require other functionality to be in place before they can be built.