Raise the floor

2nd March, 2026

Most of us build on foundations we did not pour.

WordPress. Shopify. React. Stripe. Chromium. Schema.org. Just part of the soup of open source projects and SaaS products, standards and systems that quietly determine what our websites can and cannot do. We inherit their constraints, layer our ambitions on top, and then try to win inside the boundaries they have set.

And when those boundaries get in the way, we adapt. We override templates. We install plugins. We write shims. We create internal conventions to paper over awkward defaults. Over time, the stack becomes less a product, and more a negotiation between what the platform does and what we need it to do.

Most businesses treat that negotiation as inevitable. The platform is “just how it is”. The browser behaves “how browsers behave”. Rich results appear or do not appear according to opaque whims. We focus on optimising inside the sandbox. Shopify’s blase handling of technical SEO foundations frustrates and constrains us all.

But these systems are not weather. They are built by people, in public, with roadmaps, issue trackers and office hours.

Which means they can be influenced.

For many teams, that idea simply does not register. ‘Contributing’ sounds like something hobbyist developers do at weekends. It feels distant from commercial reality. It certainly does not feel like something a marketing director, product owner or SEO consultant should care about.

And yet, it is often the most leveraged move available.

Upstream is not just code

Contributing upstream does not always (or even often) mean writing C++ for a browser engine or shipping a major feature into a CMS.

Sometimes it looks like sponsoring an accessibility expert so that WordPress produces better semantic markup by default. That investment might mean that every image ships with more sensible alt text prompts, or that navigation components are keyboard accessible out of the box.

Sometimes it looks like funding documentation work. Clearer documentation reduces misuse, which reduces broken implementations, which reduces the kind of SEO horror shows consultants are usually paid to untangle. If you rely on a platform at scale, investing in its clarity is not charity. It is preventative maintenance.

Sometimes it is simply turning up.

Chromium, for example, has public roadmap discussions and issue trackers. You can join office hours and ask a pointed question about a specific pain point, like: “Why can’t <video> elements be lazy-loaded natively?” You may discover that the answer is rich with historical context. Or that a standards discussion is stalled for lack of real-world use cases. Or, it might turn out that a solution is already being worked on by sponsored contributors, and that a fix will land imminently (for reals). Your participation, as someone shipping high-traffic or high-prestige experiences, changes the tone of that conversation. It moves the issue from theoretical to tangible.

You do not need to be an engineer to do that. You just need to care enough to show up.

Or take Schema.org. If your business model depends on how products, events or services are represented in search, then the vocabulary underpinning those representations matters. New types and properties are proposed and debated in public forums. Working groups actively seek real-world input.

An SEO or product lead who can articulate why a particular relationship is missing, or why a property needs clearer guidance, is not dabbling in standards for fun. They are shaping the language that search engines use to understand their content. That, in turn, influences what can plausibly become a rich result.

Upstream is not a GitHub repo. It is an ecosystem of conversations.

The comfortable alternative

The default posture, however, is local optimisation.

We find the constraint and work around it. We add the performance plugin. We create the custom block. We write the middleware. We launch the workaround and move on.

There is a whole business model in staying local. Agencies sell performance retainers (again, and again, at scale, and across a breadth of similar sites) because defaults are suboptimal. SEO consultancies thrive on cleaning up canonical logic and markup that could have been sensible from day one. SaaS tools flourish by abstracting away awkward platform decisions.

None of that is illegitimate. But when you have the option to address the root cause, and you choose not to because it feels commercially inconvenient, that deserves a second look.

The usual objection, from agencies and practitioners who are incentivised to compete, is familiar: “if we fix it for everyone, our competitors benefit, too”.

Yes. They do.

But what exactly are you giving them?

You are not handing over your strategy, your editorial voice, your unique insights, or your distribution channels. You are just removing friction.

If your competitive edge depends on your rivals being slowed down by bad defaults, that is not much of an edge. It is simply a tax you have learned to pay more efficiently than they have.

And you are still paying it.

Every workaround is cognitive overhead. Every patch increases fragility. Every customisation is another thing to regression-test and document. Publishing takes longer. Upgrades are scarier. Innovation slows because the foundation is unpredictable.

Over time, that friction shapes your organisation. It normalises compromise.

Raising the floor changes the game

There is another way to frame this.

Instead of asking whether you lose an advantage if everyone gets a fix, ask what happens when the baseline improves.

If WordPress outputs cleaner, more semantic HTML by default because accessibility and documentation contributors were funded and empowered, your editors do not need a 20-point checklist to avoid harming SEO when they write. They publish, and it just works.

If a browser bug affecting layout shifts on older Android devices is fixed upstream, your site loads more smoothly for millions of users without heroic CSS contortions. You can delete code instead of adding more.

If the Schema.org roadmap expands to model your industry properly, you no longer need to stretch generic types into awkward shapes. Your content becomes more accurately understood, which increases the likelihood of an appropriate, compelling presentation in search.

These are not marginal gains.

They shorten your time to publishing. They reduce QA overhead. They lower hosting costs because you are not compensating for inefficiency with bigger infrastructure. They make migrations less terrifying because you are closer to the platform’s centre of gravity rather than orbiting it with bespoke hacks.

And when the plumbing is solid, good teams accelerate.

When you are not constantly firefighting performance regressions or patching semantic holes, you can run more experiments. You can invest more time in content quality, UX, analytics and distribution. The energy previously spent compensating for cracks in the foundation is redirected into differentiation.

Your competitors may benefit from the same improved baseline. They do not inherit your culture of execution.

In fact, once obvious technical friction disappears, differences in strategy and competence become more visible. Raising the floor often raises the ceiling for those who are ready.

Influence is not altruism

There is also a strategic dimension that rarely makes it into board slides.

When you sponsor contributors, participate in roadmap discussions, or help shape standards, you gain influence. You build relationships with maintainers. You understand the direction of travel before it is announced. You can advocate for features that matter to your commercial reality.

If you are operating at scale, that is not philanthropy. It is risk management.

Browsers evolve. Search engines reinterpret markup. CMS platforms pivot their priorities. If you are only reacting, you are always slightly behind. If you are part of the conversation, you are not merely adapting. You are steering.

And that steering is not reserved for engineers. Product managers can highlight gaps in editorial workflows. SEOs can articulate why certain properties are critical for visibility. Marketing teams can provide real data about user behaviour that informs performance priorities.

Upstream contribution is as much about insight and articulation as it is about code.

Compounding equity instead of debt

Workarounds accumulate debt. Contributions build equity.

Debt feels efficient because it delivers a local, immediate win. Equity is slower. It requires patience, negotiation, and sometimes funding efforts that do not immediately scream ‘ROI’.

But five years from now, one organisation is juggling a maze of brittle overrides, dreading the next major release. The other is running on a cleaner stack that largely behaves as intended, because they helped make it so.

From an SEO and performance perspective, that stability is invaluable. Fewer surprise regressions. Cleaner upgrades. A foundation robust enough to survive shifts in how content is rendered, parsed and summarised by increasingly impatient machines.

As the web becomes feedstock for AI systems that do not render JavaScript and do not tolerate chaos, sensible defaults are no longer aesthetic preferences. They are survival traits.