Don’t accept a janky website

Jono says: “Stop accepting technical mediocrity.”

What does mediocrity look like in the world of technical SEO?

“We all know it, and we see it all the time. We have accepted that it's normal for websites to be rubbish.

Whether they're the ones we work on, our clients’, or the ones we browse, things are slow, we hit 404 errors, there's a bunch of JavaScript loading so that when you click the thing, it doesn't respond quickly, stuff doesn't quite show on screen properly, the font's too small, things are ugly, it takes four minutes for something to add to the cart, and then the cart was empty all along.

Somehow, we're all okay with this. It's so normal for all of these interactions to be this bad that we just get on with it – and, for the most part, Google has coped with that and made the most of the web being janky, broken, and poorly built.

However, as we enter the age of AI, the rules change slightly because those systems aren't as good at unpicking that mess. They’re simply not as incentivised to. When you look at their commercial, political, and product roadmaps, and the way they interact with websites, it's a very different machine. They are much less tolerant of faults, errors, omissions, and gaps – and they won't put in the same resources that Google has to wade through that.

We all feel how janky the web is, and see it all the time, and we just kind of accept it. It's nice to take a step back and say, actually, this isn't good enough. It's not how it should be.”

You say that most SEO strategies ignore the platform itself, so what are the key aspects of the platform that need to be looked at?

“We call ourselves digital marketers, or a subset of digital marketing, and we forget that that first word means something. The canvas isn't billboards, newspapers, or shopfronts; it is the web. In order to do the web well, you need to consider its limitations, the mechanics, and the ways it works – and you need to take advantage of those and mitigate the disadvantages.

Good SEO requires that you really consider how a web page is transmitted to the user. What is it comprised of? Is it well built and managed? Is it brittle? Are things in the right order? Does it use the right ingredients? Is it using legacy code that might be slow or cumbersome? Does it crash on older mobile phones visiting from countries that don't have good network connectivity?

These are the considerations that we tend to overlook because it's perceived as developer-y, engineer-y gubbins. However, it's almost as critical as our content being relevant, and having lots of links and a great reputation.”

You say that many developers consistently choose stacks that bloat and break; are you able to name any?

“Absolutely. I think this started around 2011 with the birth of Angular, which was the first modern JavaScript stack. Overnight, we went from a web that was very web-centric – with people having servers, frameworks, and infrastructure – to a culture of app developers and software developers, who then conflated the words ‘website’ and ‘app’. Those terms started to be used interchangeably when they're actually very different things.

From there, we got the birth of React, Vue, Vercel, and a hundred variations of those. If you were launching a fancy startup today, your platform of choice would probably be something based on React, hosted on some kind of client-side infrastructure, etc.

The problem with all of that is that the world of SEO, Google, and increasingly the agents in LLMs, isn’t designed to consume and digest apps; they’re designed to browse the open web. Websites and apps are different things that should work in different ways.

We’ve normalised a culture where we use app toolkits to build websites, which is why we end up with slow, client-side rendered, JavaScript-powered sites that ship 20MB of JavaScript before they put an image on the page, and it takes a team of 28 people four weeks to change a header tag on a page.

It's all very dev-centric. Part of the reason this persists is because the developers and engineers who build using these tools prefer those tools. They prioritised their preferences over the preferences of the end users, the marketers, and the businesses – and we've normalised this.

This is why the web at large is mediocre: because we are using the wrong tools for the wrong job.”

How can a single SEO in a business battle against mediocre developers who are shipping fragile code with unnecessary complexity, as you put it?

“Taking a step back, one of the reasons this all started was because browsers were terrible to work with. Chrome was very different to Firefox, which was very different to Internet Explorer, etc. – and the JavaScript ecology allowed you to pave over a lot of that.

Now, that's not the case. Browsers are great. Chrome and the Chromium work they're doing with other browsers make support for features consistent. It makes standards universal. Now, browsers can do a lot of what JavaScript has been used to do, like transition between pages and preload stuff before it's needed. We're in a position where most websites could go back to basics and just be clean, semantic, simple HTML.

They could just use CSS animations instead of JavaScript. They could just send pages instead of fragments of applications. As an individual person, you can take a step back and say, ‘Why do we need all of this complexity when something simple would do the same job in the same way, with far less overhead?’ If you want to play the long game, at what point do you rip down all of this architecture that you spent a decade building in the wrong direction and do something that's inherently, natively much sleeker?

If you're in an organisation where you're already fighting against all of this stuff, being that voice that says, ‘At what point do we start to change direction?’ is quite important. You can start with small things, like replacing bits of JavaScript with bits of CSS, and replacing soups of divs within divs within spans in HTML with more semantic stuff. Actually use H1s on a page and use an aside to say that something is a sidebar.

Machines are reading this, Google's reading it, and LLMs are probably reading it. It makes the web an easier ecosystem to exist in and parse, so it's worth the effort.”

Is it an SEO's job to have these conversations with developers, or should they focus on how to rank in Google?

“You need to do both. Understanding and advocating for what a good website looks like technically is as important as saying, ‘Is our content good? Do we have the right links? Are we aligning with the right product market fit?’

If you ignore the website bits, what you're doing in digital marketing or SEO is just marketing. You're putting nice words and pictures on a pamphlet, but if that pamphlet is inaccessible to Google or takes six seconds to load, you are not going to be well-equipped for the future.

If we zoom out and look at what the web will look like two, three, or five years from now, we assume there'll be a rise in agentic searching – where I search for something and there's a query fan-out process and a hundred searches happen, and those searches trigger other things that trigger other things.

If even one of those interactions takes four seconds and returns a bunch of malformed JSON or hits a server error because somebody didn't configure a firewall correctly, then the whole thing comes tumbling down. Where your site might've been recommended or your content might've been extracted and cited, you're suddenly not visible at all.

It’s more critical than ever to think of the technical integrity of your site as a process of future-proofing. Google has let us be lazy. Google and Chrome's ability to ignore errors and poor performance has let us ignore this and get away with it being bad for a decade now. That's no longer the case.”

How do you articulate the value of technological improvements to stakeholders within the business?

“We've had 15 years of really good research on this. WPO Stats is a great resource that has filterable case studies on every combination of, ‘We shaved 1.4 seconds off LCP’, ‘We reduced our server response time by 20%’, and all the variations on those narratives.

You can wave those under your C-suite's nose and say, ‘Look, milliseconds do convert to money.’

There are other arms you can pull as well. You can play the eco card, because if your site is taking four seconds to load, that's because some power plant somewhere, and banks of CPUs and GPUs and undersea cables, are overheating to deliver that, just because it’s been built badly. Reducing the carbon overhead of those problems is super valuable.

In 2006, a leaked Amazon study found that every 100 milliseconds of added page load time cost them 1% in sales. Nielsen did a really good one around 2021, where they studied a few hundred sites of different niches, and they found the same kind of stats.

The other angle here, which is potentially more useful for SEO, is that nobody sets out to build a slow site. It's not a design decision; it's accidental. When you start to unpick and fix site speed, you find all the skeletons in the closets. You might discover that your CTO has outmoded opinions on how fonts should load, or your development team don't know about modern CSS standards, or you have a connection to a third-party partner that hasn’t been updated in 10 years.

The process of going through and looking at how to make this faster fixes the organisation in a hundred ways that would never have happened otherwise. You start to optimize for quality of user experience rather than just how to shave milliseconds off, because it forces those awkward conversations. That's the real impact.”

As an SEO, how do you determine which skeleton to attack first?

“That's the challenge with all of SEO: you've got finite resources and priorities, and everybody's very busy doing their day job – none of which is about focussing on quality. Nobody owns quality. You're coming in from the outside and saying, ‘Here are 38 things that nobody owns. Please, can I buy you beer and cupcakes to get you to do them?’

As always, the answer is to try and make a compelling business case. Try and get buy-in from as high up the organisation as you can. If you can get the CEO bought in and get them to put pressure downwards, that's far easier than you begging at the table to try and put pressure upwards.

It’s hard, but it’s the case for all of SEO. You are always going to be an outsider begging for crumbs of quality control, focus, and improvements. Getting good at that is probably the most important skill in the industry.”

Will AI-driven search engines struggle to handle things like JavaScript and bloat as well, and end up not featuring you in answers because of it?

“That’s what people should be really concerned about.

So much of our model for SEO mentally assumes that you can throw a million pages on the internet, drive a million visits to every single one of them, and maybe convert a few. Now, suddenly, you have these systems that are making qualitative assessments of your pages and your brand. If they don't like what they don't see, you don't get access to that audience, and you don't get the ability to drive millions of people to them.

You get one shot to prove that your content is relevant, meaningful, good, and performant. If they struggle to parse that HTML – they can't find the content on the page because it's hidden behind 20MB of JavaScript, or they can't understand it because it's buried in a trillion lines of inline CSS – you miss out on the opportunity to get in front of the audience.

Hopefully, these systems get better at parsing and understanding the kind of web that we've built, but I don't see it happening anytime soon.

You need to do a real critical evaluation. Turn off JavaScript and look at the HTML source code. Assume that you're a machine trying to pick out the gems of value. How easy is that? How clean is that? How straightforward is that? If it's like wading through soup, that’s the same experience ChatGPT and other systems have. Now is the time to be assessing that.”

Should this ideally be tackled early on in a new role, and how much time does it take before you can demonstrate the impact that you’re having?

“You're already assuming that it takes a lot of time for developers to prioritise this, get it done, and see results. That happens because the thing is already bad. That shouldn't be normal. It should be trivially easy to make changes.

XML site maps, canonical URLs, hreflang, alt tags on images – all of these things should take minutes, not months. The fact that we've normalised that they take months is because of these broken technical cultures, because we're trapped in this developer experience, and because people are comfortable in their jobs. If there are 12 developers when there might only need to be 3, it's in none of their interests to be more efficient.

Learn what good website development looks like and how those processes work. What is involved in changing that H2 to an H3 or excluding things from the XML sitemap if it's a Tuesday? Understanding how those logical structures and systems work gives you a lot of leverage to have grown-up conversations with developers and say, ‘This shouldn't take months.’

Then, on day one at a new organisation, you can say, ‘It is a problem that our site takes six seconds to load. Here are the bottlenecks. Why can't we fix that this afternoon?’”

Jono, what's the key takeaway from the tip you shared today?

“Make your websites better. Don't accept being broken and janky.”

Jono Alderson is an Independent Technical SEO Consultant. Find out more over at JonoAlderson.com.