After building Built by STS without a page builder, we started thinking about what should come next.
SEO was an obvious area to address.
Like many WordPress users, we could have installed one of the established SEO plugins, worked through its settings, disabled the features we didn’t need, and moved on.
There’s nothing inherently wrong with that approach. Full-featured SEO plugins solve real problems for millions of websites.
But Built by STS is also a place for us to ask a different question:
What does WordPress already do before we add something else?
That question eventually became STS SEO.
We Started With an Audit, Not a Plugin
Our first step wasn’t opening a code editor.
Before building anything, we audited the SEO output of BuiltBySTS.com to see what WordPress was already handling on its own.
The results changed the scope of the project.
WordPress was already doing quite a bit.
It was generating our document titles. It provided canonical URLs for singular content. It handled robots directives. It included native XML sitemap infrastructure. It also managed many of the foundational pieces around permalinks, feeds, language attributes, and other standard site output.
That meant rebuilding those systems inside our own plugin wouldn’t make STS SEO better.
It would mostly give us two systems trying to solve the same problem.
So instead of asking:
What features should an SEO plugin have?
We asked:
What is actually missing from this WordPress site?
That produced a much smaller list.
Finding the Actual Gaps
Our audit identified a few things we genuinely wanted to improve.
There were no custom meta descriptions.
There was no Open Graph metadata for sharing pages on social platforms.
There was no X/Twitter Card metadata.
And while WordPress correctly provided canonical URLs for our homepage and individual article, our News posts index didn’t have one.
Those became the initial responsibilities of STS SEO.
Not because we were trying to compete feature-for-feature with an established SEO suite, but because those were the needs we could actually demonstrate.
That distinction became important.
Add What WordPress Is Missing
A simple principle started guiding the project:
Add what WordPress is missing. Leave WordPress core alone where it already provides the functionality.
That meant STS SEO v0.1.0 would not create another title system.
It wouldn’t replace WordPress robots directives.
It wouldn’t build another XML sitemap engine.
It wouldn’t take over singular canonical URLs.
And it certainly didn’t need keyword scores, traffic lights, ranking promises, analytics, redirects, AI writing tools, or a long list of settings simply because other SEO plugins have them.
STS SEO had four initial jobs: descriptions, social metadata, social images, and the canonical coverage we were actually missing.
That was enough.
One Source of Truth
We also wanted the editing experience to stay simple.
Rather than creating separate fields for an SEO description, Facebook description, X description, Facebook image, X image, and every possible variation, STS SEO reuses information wherever it makes sense.
A custom Search Description can become the description used in search metadata, Open Graph, and Twitter Cards.
WordPress continues generating the document title.
The canonical URL becomes the social URL.
And social images follow a straightforward hierarchy.
An explicitly selected article image comes first. If there isn’t one, STS SEO can use the WordPress Featured Image. If that isn’t available, it can fall back to a site-wide social image.
If none exists, it simply doesn’t invent one.
The goal is fewer fields to manage and fewer opportunities for different pieces of metadata to contradict each other.
It Should Feel Like WordPress
The admin interface followed the same philosophy.
STS SEO doesn’t introduce a completely separate design language inside WordPress.
The controls for Search Description and Social Image use familiar WordPress patterns, and the plugin has a small settings area for the few site-wide options it actually needs.
That may sound like a small detail, but it matters to us.
A WordPress plugin doesn’t always need to feel like an application sitting on top of WordPress.
Sometimes the better experience is for it to feel like it belonged there all along.
Respecting WordPress Means Respecting Its Settings
There was another behavior we considered non-negotiable.
BuiltBySTS.com was still under development, so WordPress was configured to discourage search engines from indexing the site.
STS SEO needed to respect that.
The plugin doesn’t turn indexing back on. It doesn’t inject a competing index directive. And it doesn’t force WordPress’s sitemap infrastructure to become available while the site is intentionally set not to be indexed.
Instead, STS SEO tells the administrator that search engine visibility is currently disabled and leaves the decision with WordPress and the site owner.
That is part of what we mean when we say the plugin should complement WordPress rather than replace it.
Then We Tested the Empty State
Once STS SEO v0.1.0 was built, we didn’t immediately start filling in fields.
We activated it with zero configuration.
That let us answer an important question:
What happens when someone installs STS SEO and does nothing?
The homepage and News page correctly omitted descriptions because there wasn’t enough configured information to create one responsibly.
Our first Workshop article was able to use its existing WordPress excerpt as an automatic description fallback.
Open Graph and Twitter metadata appeared using the information WordPress already knew.
The News page received the canonical URL it had previously been missing.
WordPress remained responsible for the canonical URL on the article.
And because no social images had been selected yet, STS SEO didn’t fabricate image metadata.
That was exactly the behavior we wanted.
Then We Added Real Data
Next, we tested the other side of the system.
We added custom descriptions to the homepage, News page, and our first Workshop article.
Those descriptions correctly replaced the automatic fallbacks and were reused consistently across the appropriate metadata.
Then we configured a site-wide social image.
The homepage and News page inherited it.
Finally, we assigned a different social image specifically to our Workshop article.
The article used its own image while the rest of the site continued using the default.
That gave us an end-to-end test of the hierarchy we had designed before writing the plugin.
More importantly, the existing WordPress behavior remained intact throughout the process.
Knowing When to Stop Building
Once everything passed, we had another decision to make.
What should we add next?
Schema?
SEO title overrides?
Social previews?
More settings?
Maybe eventually.
But none of those features currently solve a demonstrated problem for us.
So we stopped.
STS SEO v0.1.0 became our functional baseline.
Now we’ll use it.
If working with the plugin reveals a limitation, that limitation can inform the next release. If client work exposes a recurring need, we can evaluate whether it belongs in STS SEO.
And if something is already handled well by WordPress, we can leave it there.
Building Smaller on Purpose
STS SEO isn’t an argument that large SEO plugins shouldn’t exist.
Different websites have different requirements, and there are projects where a comprehensive SEO platform makes perfect sense.
This project is about something else.
It’s an experiment in building software from demonstrated needs rather than feature checklists.
STS Starter began with a similar idea: provide a thoughtful WordPress foundation without deciding everything about the site that will eventually be built on top of it.
STS SEO extends that thinking into functionality.
Start with WordPress.
Understand what it already provides.
Identify the actual gap.
Build deliberately.
Test the result.
Then know when to stop.
That approach won’t always produce the product with the most features.
But we’re increasingly convinced it can produce something more important:
software with a clear reason for being.
From the Workshop
STS SEO is currently an internal Built by STS project running here on BuiltBySTS.com. We’re going to continue using it in real work before deciding what it should become next.
That’s part of the experiment.
We aren’t building a product roadmap first and searching for reasons to justify it afterward.
We’re going to let the work help shape the roadmap.
Create. Build. Grow together.