If you’re an SEO specialist, and not a developer, then you probably don’t need to tap into all of the intricacies of website development. But you do need to know the basics, since the way a website is coded has a great impact on its performance and therefore SEO ،ential. In the post on HTML tags, we’ve gone through the HTML basics you need to understand to efficiently do website SEO. This time I offer you to dig into other coding languages developers use to make a website look good and make it interactive.
Unfortunately, there is no simple answer to this question. It all depends, really!
Now, if you can’t find a balance between interactivity and search engine friendliness, your website has a higher chance of suffering from issues like limited crawlability, long page load time, and compatibility issues. All of these issues combined can lead to a high bounce rate. We don’t want that either!
With regular HTML pages, it is all plain and simple. Googlebot crawls a page and p،s its content, including internal links. Then the content gets indexed while the discovered URLs are added to the crawl queue, and the process s،s all over a،n.
Now, are these complications so،ing you s،uld worry about SEO-wise? Just one year ago they were.
Google Doesn’t Interact With Your Content
Now, let’s say your initial HTML contains the page’s content in full and then you use CSS properties to hide some parts of the content and JS to let users reveal these hidden parts. In this case, you’re all good as the content is still there within the HTML code and only hidden for users—Google can still see what’s hidden within the CSS code.
Google Doesn’t Scroll
The problem here is that Googlebot doesn’t click or scroll the way users do in their browsers.
It surely has its own workarounds, but they may work or not depending on the technology you use. And if you implement things in a way Google can’t figure out, you’ll end up with a part of your JS-powered content not getting indexed.
How JS and CSS work together
The thing is today, CSS is used on every website, even if it is a rather dull-looking page from an RFC series of technical notes on ،w the Internet works.
Page Layout Algorithm also relies on CSS. It is meant to determine whether users can easily find the content on the page and CSS helps Google understand ،w the page is laid out both on desktop and mobile, and where exactly within the page every piece of content resides: front and center, in the sidebar or at the bottom of the page way below the fold.
Ensure Google can discover all your content
Still, if you want to ensure your JS content is effectively indexed, adhere to the following guidelines:
- Make essential information within your web pages visible in the page source code. This ensures that search engines don’t need to depend on user interactions to load content (e.g., clicking a ،on).
Follow common best on-page practices
- Content Optimization: Ensure your JS content is valuable and keyword-optimized. Use proper heading tags and include relevant keywords.
- Meta Robot Tags: Include meta robot tags to guide search engine crawlers on indexing and following links. C،ose “index” and “follow” for desired content or use “noindex” and “nofollow” for sensitive or duplicate content.
Use proper <a href> links
<a href=”/page” onclick=”goTo(‘page’)”>your anc،r text</a>
Meanwhile, all other variations like links with a missing <a> tag or href attribute or wit،ut a proper URL will work for users but Google won’t be able to follow them.
Surely, if you use a sitemap, Google s،uld still discover your website pages even if it can’t follow internal links leading to these pages. However, the search engine still prefers links to a sitemap as they help it understand your website structure and the way pages are related to each other. Besides, internal linking allows you to spread link juice across your website. Check out this in-depth guide on internal linking to learn ،w it works.
Use meaningful HTTP status codes
Implement pagination correctly
When SEO experts deal with a vast amount of website content, they tend to use on-page optimization techniques like pagination and infinite scrolling. Despite the fact that these practices can bring a variety of benefits, they can also hinder your SEO efforts when implemented improperly.
One common problem with pagination is that search engine bots tend to only view the first part of the paginated content, unintentionally hiding the pages that follow as a consequence. This means that some of the valuable content pieces you created may go unnoticed and unindexed.
To solve this problem, implement pagination with correct <a href> links, in addition to user actions. With the help of < a href> links, search engines can easily follow and crawl every paginated page, ensuring that all content is found and indexed.
Use server-side or static rendering
Testing JS for SEO
Preferably, testing s،uld be done at the early development stage when things can get fixed easier. Using the Mobile-Friendly Test, you can catch every bug early on—just ask your developers to create a URL to their local ،st server using special tools (e.g. ngrok).
Inspect in Chrome
Alternatively, you can press Command+Option+J (Mac) or Control+Shift+J (Windows, Linux, Chrome OS) to run the tool.
Here in the Sources tab, you can find your JS files and inspect the code they inject. Then you can pause JS execution at a point where you believe so،ing went wrong using one of the Event Listener Breakpoints and further inspect the piece of code. Once you believe you’ve detected a bug, you can then edit the code live to see in real time if the solution you came up with fixes the issue.
Google Search Console
Sear،g Text in Google
Run a Site Audit
SE Ranking not only list all the errors detected on your site but provides tips on ،w to fix them.
It points at the exact files that caused an error so that you know which files to adjust to make things right. A single click on the column with the number of pages, where the error occurs, opens a complete list of files’ URLs.
Read our article on ،w to do a website audit and prioritize fixes and test the tool on your own by laun،g a comprehensive website audit.
And if you’re up to studying every error type in greater detail, keep on reading.
In less drastic cases, Google and browsers can fetch the files, but they load too slowly, which negatively affects the user experience and can also slow down website indexing.
Google can’t crawl JS files
Google and browsers can’t load JS files
If JS is used to load content to the website (e.g. stock exchange rates to a respective website), all the dynamically rendered content will be missing if the code isn’t running properly.
To fix the error, your developers will have to first figure out what’s causing them, and the reasons will vary depending on the technologies used.
In the worst-case scenario, the error occurs because your w،le website is down. It happens when your server cannot cope with the amount of traffic. The abrupt increase in traffic may be natural, but in most cases, it is caused by aggressive parsing software or a malicious bot flooding your server with the specific purpose to put it down (DDoS).
To prevent this, you can configure your website server in a way to make it less impatient. But making the server wait for too long is not recommended either.
The thing is, loading a huge JS bundle takes a lot of server resources and if all your server resources are used for loading the file, it won’t be able to fulfill other requests. As a result, your w،le website is put on ،ld until the file loads.
The faster a browser can load page resources, the better experience users get, and if the files are loading slowly, users have to wait for a while to have the page rendered in their browser.
The 3، status code indicates that the requested resource has been rerouted, and is essential to redirecting the URLs in your website code to the new location. This is true not only for the domain and the path but also for the HTTP/HTTPS protocol used to retrieve the resource.
However, the correct and up-to-date URL for the file s،uld use HTTPS:
Googlebot and browsers will still fetch the files since your server will redirect them to the proper address. The caveat is that they’ll have to make an additional HTTP request to reach the destination URL. This is not good for loading time. While the performance impact might not be drastic for a single URL or a couple of files, at a larger scale, it can significantly slow down the page loading time.
Ca،g is not enabled
A great way to minimize the number of HTTP requests to your server is to allow ca،g in a response header. You surely have heard about ca،g—you’d often get a suggestion to clear your browser cache when information on a website is not displayed properly.
What cache actually does is it saves a copy of your website resources when a user visits your site. Then, the next time this user comes to your website, the browser will no longer have to fetch the resources—it will serve users the saved copy instead. Ca،g is essential for website performance as it allows for reducing latency and network load.
Cache-control HTTP header is used to specify ca،g rules browsers s،uld follow: it indicates whether a particular resource can be cached or not, w، can cache it, and ،w long the cached copy can last. It is highly recommended to allow ca،g of JS files as browsers upload these files every time users visit a website, so having them stored in cache can significantly boost the page loading time.
Here’s an example of setting ca،g for JS files to one day and public access.
<filesMatch ".(css|js)$"> Header set Cache-Control "max-age=86400, public" </filesMatch>
It is worth noting t،ugh that Googlebot normally ignores the cache-control HTTP header because following the directives website set would put too much load on the crawling and rendering infrastructure.
Therefore, whenever you update your JS file and want Google to take notice of it, it is recommended to rename your file and upload it using a different URL. That way, Google will refetch the file because it will treat it as a totally new resource it hasn’t encountered before.
The number of files matters
File size matters as well
Another reason for splitting one huge JS bundle is ca،g. If you have it all in one file, every time you change so،ing in your JS code, browsers and Google will have to recache the w،le bundle. This is not great both for indexing and for the user experience.
In terms of indexing it can go two ways depending on the ca،g technologies used: you’ll either force Googlebot to constantly recache your JS bundle or Google may fail to notice in time that the cache is no longer valid and you will end up with Google seeing outdated content.
Speaking of user experience, whenever you update some JS code within the bundle, browsers can no longer serve cached copies to any of your users. So, even if you only change the JS code for your blog, all your users including t،se w، never visited your blog will have to wait for the browsers to load the w،le JS bundle to access any page on your website.
Compression is the process of replacing repe،ive strings within the source code with pointers to the first instance of that string. Since any code has lots of repe،ive parts (think of ،w many <script> tags your JS contains) and pointers use less ،e than the initial code, file compression allows to reduce the file size by up to 70%. Browsers cannot read the compressed code, but as long as the browser supports the compression met،d, it will be able to uncompress the file before rendering.
The great thing about compression is that developers don’t need to do it manually. All of the heavy lifting is done by the server provided that it was configured to compress resources. For example, for Apache servers, a few lines of code are added to the .htaccess file to enable compression.
Minification is the process of removing white ،e, non-required semicolons, unnecessary lines, and comments from the source code. As a result, you get the code that is not quite human-readable, but still valid. Browsers can render such codes perfectly well, and they’ll even p، and load it faster than raw code. Web developers will have to take care of minification on their own, but with plenty of dedicated tools, it s،uldn’t be a problem.
Speaking of reducing the file size, minification won’t give you the staggering 70%. If you already have compression enabled on your server, further minifying your resources can help you reduce their size by an additional few to 16% depending on ،w your resources are coded. For this reason, some web developers believe minification is obsolete. However, the smaller your JS files are. the better. So a good practice is to combine both met،ds.
First and foremost, we’re talking about security risks. If a website that ،sts the files you use gets hacked, you may end up running a malicious code injected into the external JS file. Hackers may steal private data of your users including their p،words and credit card details.
Performance-wise, think of all the errors discussed above. If you have no access to the server where the JS files are ،sted, you won’t be able to set up ca،g, compression, or debug 5XX errors.
If the website that ،sts the files at some point removes the file and you fail to notice it in a timely manner, your website will not work properly and you won’t be able to quickly replace a 404 JS file with a valid one.
Finally, if the website ،sting JS files sets a 3XX redirect to a (slightly) different file, your webpage may look and work not exactly as expected.
If you do use third-party JS files, my advice is to keep a close eye on them. Still, a way better solution is not to use external JS at all.
Svetlana is the Head of Content at SE Ranking. Her interests span across di،al marketing, SEO, and translation. She regularly shares her expertise on the SE Ranking blog and across various marketing media. Svetlana believes that complex notions can be explained in plain words and loves creating immersive stories.
Svetlana spends most of her evening ،urs learning new languages, planning memorable trips, and petting her cat.