To say my relationship with JavaScript is antagonistic would be an understatement.

I have a long and colourful history of ranting about the dangers of JavaScript in the context of SEO, which I will not repeat here. If you’re interested and have some time to spare, these two talks I gave in 2018 and 2019 respectively will serve to set the context:

Technical SEO in the Wild - Real World Issues and Fixes

JavaScript is Ruining the Web

I’m far from alone in pointing out the issues with JavaScript and SEO. The folks are Onely are among the best when it comes to R&D in this area, and they’re generous with their knowledge. Here’s a great resource from them that highlights the most common issues JavaScript can cause for SEO:

» 10 Most Common SEO JavaScript Issues and How to Fix Them

In the context of news websites, JavaScript poses additional challenges. News moves fast and fresh articles are published at an astounding rate. Google is constantly crawling news sites to find newly published URLs and index them rapidly.

When you have critical page content relying on client-side JavaScript, Google will need to render the page to index that content. This introduces a delay in Google’s indexing process, because rendering is far from rapid.

In fact, research from those same folks at Onely showed that JavaScript pages are crawled (and subsequently indexed) nine times slower than pages that contain all their content and links in the raw HTML.

Considering the speed with which news moves, I’m not sure a publisher can afford to be nine times slower than their competitors to get their stories crawled by Google.

In fact, this is a quote from Google’s technical guidelines for news publishers:

“Your articles’ pages should use HTML format and the body text isn't embedded in JavaScript.”

The message is clear: don’t use JavaScript to load article content.

But these recommendations are based on extreme scenarios where the page’s content is entirely loaded with client-side JavaScript. Fortunately for news publishers this is exceedingly rare.

There are, however, plenty of other implementations of JavaScript that don’t directly interfere with Google’s ability to index article content, but still cause issues with the site’s SEO.

Here are the most common JavaScript-related problems I see on publishing sites:

Navigation Menu

Top navigation menus often have a fold-out feature to show more links. Especially on mobile resolutions, fold-out hamburger menus are a common practice.

In and of itself, this doesn’t have to be an issue - as long as the links contained in the menu are already present in the HTML source. Their presence in the HTML means Google can see the navigation links there and crawl them without issue. It also tells Google what your main news categories are, which will help your site’s topic authority for those categories.

When fold-out menus use JavaScript to load links into the DOM, that’s when we start having problems. I see this with some regularity; the HTML only contains top-level navigation links, and the subcategory links are only loaded into the webpage when the menu is clicked.

The root of the issue is that Google doesn’t click. When rendering webpages for indexing, Google doesn’t perform any actions. No clicking, no scrolling, nothing.

So any content - links, text, or images - that relies on a user-action to be loaded into the webpage’s DOM are effectively invisible to Google. That includes navigation links.

By hiding these navigation links from Google you’re presenting a much shallower site to the search engine, restricting Googlebot’s access to your (sub)sections. This results in less effective crawling, and weaker topic authority signals.

Always make sure all your navigation links are present in the HTML and don’t require a client-side script action.

Pagination

A common way to implement pagination - i.e. showing more articles on a section page beyond just the first list of articles - is with Load More buttons or infinite scroll auto-loading.

If you’ve paid attention so far, you’ll see the issue here. Google doesn’t scroll, and Google doesn’t click.

If your site’s pagination uses JavaScript with either infinite scroll or a Load More button, chances are Google doesn’t see these additional articles on your section page. Effectively, you’re showing just a single list of articles to Google, with old stories dropping off rapidly as new articles take their place.

The impact on SEO is that, as far as Google is concerned, you have a short list of articles associated with any section page. This negatively impacts on topic authority.

Additionally, once articles drop off the first page of a section they lose internal link value in Google’s calculations, and their rankings will suffer accodingly (which is especially harsh for evergreen content).

You’ll want your pagination to be easily crawlable and indexable for Googlebot. This means old-fashioned pagination links with unique crawlable and indexable URLs. I’ve written about optimal pagination for news publishers before.

Comments & UGC

In a recent newsletter I spoke about the potential risks and benefits of allowing Google to index your reader comments and other user-generated content.

Usually comment functionality is implemented with client-side JavaScript, which means Google will have trouble indexing it unless you make specific allowances.

I won’t repeat my recommendations - if you’re interested, here’s the newsletter where I explore this issue in detail:

The Impact of Article Comments on SEO Barry Adams · November 7, 2023 Read full story

Recommended/Related/Trending Articles

Another common practice on news sites is to load related and recommended article blocks with client-side JavaScript.

Often, when such a block of additional content is provided within or underneath an article, it uses client-side JS to ensure the recommended articles are relevant to the story and/or align with currently trending articles.

This doesn’t have to be an issue, if you’re okay with Google not seeing these articles in the first instance.

If you’re diligent about internal linking to related stories directly from within an article’s content, then using client-side JS for blocks of related articles is fine. These extra article links are just a sprinkling of engagement bait and not really relevant for SEO.

However, if you do want Google to see those related article blocks, then you’d best load them directly in the HTML and not with client-side JavaScript.

Google may eventually render the page and see those related article blocks, but that rendering may happen days after initial indexing. At that stage those recommended articles could be very different and less relevant. If the recommended articles block uses personalisation, Google may even see something very different than your users.

SGE Doesn’t Render?

Now there’s a whole debate to be had about how SGE could impact news publishers’ Google traffic, but let’s park that for now (well, until May 29th when I’ll be speaking on exactly that topic at the WAN-IFRA World News Media Congress - more on that below).

In the context of this newsletter, it’s relevant to know that SGE primarily bases its responses on content found in a webpage’s HTML.

Again, the Onely folks have done the research to show that the vast majority of SGE answers are extracted from the HTML. JavaScript-dependent content is not surfaced in SGE at a similar rate.

If you care about showing up as an answer in Google’s SGE, you’ll want to load all your content in the raw HTML as well.

Advertising

I can’t talk about JavaScript and news websites without mentioning the elephant in the room: advertising.

Pretty much all online advertising uses JavaScript. Every bit of ad targeting, user tracking, personalisation, ad bidding, ad serving, etc. is done with JavaScript.

Publishers that rely on advertising as their primary monetisation channel will often find themselves at the mercy of their ad platforms when it comes to the amount and effectiveness of JavaScript loaded onto a typical article page.

Over the years I’ve seen some pretty egregious advertising payloads on article pages. The worst was a single article page that used over 1100 HTTP requests to load 240+ JavaScript files, clocking in at a whopping 10 megabytes of data (compressed; well over 24 MB uncompressed).

All that, just to load a single article for a single user.

Suffice to say, that website’s core web vitals scores were pretty disastrous. Moreover, loading that much JavaScript on an article betrays a deeper issue: an utter lack of respect for your readers.

Imagine if you’re a user on a data-restricted mobile contract. Loading 10 MB of data for a single news story is a significant and costly chunk of mobile data.

Additionally, many ad networks are known to collect user data on an industrial scale. Legalities aside, do you want your news website to serve as a privacy-invading data-harvesting platform? For me, that doesn’t align with what journalism’s fundamental principles should be.

Realistically, we need advertising to fund journalism. But there’s a balance to be found, and it should always start from the premise of treating your readers with respect. Overloading their browsers with advertising junk is not a sign of respect.

JavaScript and News Summarised

By now it should be abundantly clear: My recommendation is to use as little JavaScript as possible. JavaScript may not be evil, but it sure is evil-adjacent.

Upcoming Events

I’m speaking at and/or attending quite a few events in the next few weeks. In chronological order:

8 May - Webinar: From Crawling to Content, SEO for News & Publishing Sites
I’m doing a webinar with Sitebulb where I’m joined by Emina Demiri-Watson and Caitlin Hathaway to talk about SEO issues specific to news publishers.

20 May - New York: SEO for News Meetup
I’m trying to make the stars align for a short trip to New York City to join this event, organised by NewzDash and hosted by Wix. I can’t 100% say I’ll be there but I’m hopeful!

28-29 May - Copenhagen: WAN-IFRA World News Media Congress 2024
I’m delighted to be part of this event, where I’m part of a session with Condé Nast’s Sarah Marshall and Reach’s Dan Russell. I’ll be talking about the expected impact of Google’s SGE on publishers.

31 May - Eindhoven: Digital Olympus
I was born and raised in Eindhoven, so when an SEO event is taking place there I simply have to attend to soak up the knowledge shared by an awesome roster of speakers.

11 June - Online Masterclass: Google Search Console Deep Dive
Once again I’m joining Jessie and Shelby from WTF is SEO? for an online masterclass. In this one we’ll be digging into the intricacies of Google Search Console and show how to get the best data out of it.

19 June - Dublin: SEO Vibes on Tour
The folks at Whitepress are organising one-day SEO events all around the world, and in June they’re hitting the ground in Dublin. As part of a pretty packed speaker lineup, I’ll be closing the day with a rant about all the BS the SEO industry has endured the last quarter of a century.

I hope to see some of you at one or more of these events. If you spot me, please do come and say hi!

NESS 2024

We’ve nailed down our speaker roster early for the 2024 edition of the News and Editorial SEO Summit! On 29 and 30 October this year, the 4th NESS event will feature the following speakers:

• Rand Fishkin - Sparktoro

• Martin Splitt - Google

• Lily Ray - Amsive

• Claudio Cabrera - The Athletic

• Glenn Gabe - G-Squared

• Olaf Seydel - Zeit Online

• Ryan Kellett - Axios Media

• Andrea Volpini - Wordlift

• Ed Hyatt - The Wall Street Journal

• Vivienne Goizet - Bild

• Brendan O’Connell - The New York Post

I’m really excited about this amazing lineup. Early bird tickets are available until May 31st, so grab yours soon on the NESS website!

Miscellanea

There’s loads of interesting content to share with you all since the last newsletter:

Official Google Docs:

• Improving Search Console ownership token management

• Debugging drops in Google Search traffic [Updated]

• Understanding page experience in Google Search results [Updated]

Interesting Articles:

• The Man Who Killed Google Search - Ed Zitron

• Where Web Users Spend Time vs. Where Traffic Referrals Originate - Sparktoro

• Global audience insights from the first quarter of 2024 - Chartbeat

• Google Fined €250 Million in French Clash With News Outlets - Bloomberg

• OpenAI resorts to scraping YouTube as AI careens towards model collapse - Future Media

• How Tech Giants Cut Corners to Harvest Data for A.I. - New York Times

• Discovering and Diagnosing a Google AdSense Rendering Bug - Merj

Latest in SEO:

• Breaking: SEO for Live News - WTF is SEO?

• Technical SEO Considerations for News Publishers - Sitebulb

• Google's March 2024 Core Update, Full Review, Analysis and Recovery - On-page.ai

• Google Will Fight Site Reputation Abuse Spam Both With Manual Actions & Algorithms - Search Engine Roundtable

That’s it for another edition, hope you enjoyed it. Thanks for reading and subscribing, and I’ll see you at the next one!

P.S. I hope you’re all ready for the May 5th deadline to get your act together for Google’s Site Reputation Abuse policies coming into effect. I’ve seen some publishers deindex content that would fit the profile, but many others seem to be calling Google’s bluff. Risky move.