Member Avatar for Znojmic

Hi,

Can somebody tell me ways to use AJAX on my site without any side effects? Or should I avoid it completely?

Thanks in advance

  • 5 Contributors
  • 6 Replies
  • 111 Views
  • 3 Months Discussion Span
  • Latest Post Latest Post by stymiee

Dani AI

Generated

Short answer for : you do not have to avoid AJAX, but use it so crawlers and real users see the same important content. Building on points from , , and , the safest modern approach is to make the AJAX-driven states discoverable and testable.

Practical checklist:

  • Give every meaningful state its own URL and ensure the server returns the same content for that URL (client-side routing + server-side handling).
  • Server-side render (SSR) or pre-render critical pages so the HTML contains the core content without waiting for client scripts.
  • Put important pages in your sitemap and use canonical tags for duplicates.
  • Don’t hide essential text behind onclick-only interactions; lazy-load nonessential assets only.
  • Use structured data and static metadata in the server response so search engines can pick it up reliably.

Common implementation paths and tradeoffs:

  • Use SSR/SSG frameworks (Next.js, Nuxt, SvelteKit) or a prerender step for static pages when possible.
  • If SSR isn’t feasible, consider dynamic rendering as a temporary fallback, but avoid cloaking and follow Google’s guidance.
  • Keep render times short; long or chained client fetches sometimes fail to be seen by crawlers.

Quick test and troubleshooting tips:

  • Inspect the page with Search Console’s URL Inspection Live Test to see the rendered HTML and screenshot.
  • Confirm the server returns 200 for each state URL and that JS/CSS resources are not blocked in robots.txt.
  • Check server logs to verify crawler visits. If indexation is missing, simplify the render path or switch to prerender/SSR.

See Google’s JavaScript SEO overview for implementation notes (JavaScript SEO basics) and the guidance on dynamic rendering (). For client routing, the History API is a lightweight place to start (pushState).

// example: update URL when loading content client-side
history.pushState({}, '', '/item/123');
// ensure server serves the same content at /item/123

Recommended Answers

All 6 Replies

Member Avatar for BamaStangGuy

Just remember that search engines don't read Javascript. So any links that are generated with Javascript won't be followed by a search engine.

Member Avatar for Dani

Ajax is a great tool ... but like anything, you need to use it wisely. I guess the best advice I could give you here is use it when you think it will genuinely give an advantage / benefit to the site visitors, but not just for the sake of using it or necessarily for the "wow" factor.

Member Avatar for Dani

BamaStangGuy: that's two for two :) We're just following each other around posting in the same threads at the same time, aren't we? :)

Member Avatar for stymiee

It should also be pointed out that all content made available by Ajax should also be available through non_Ajax means. This is so people who don't have Ajax-ready browsers can still use your website. In that case you site is still SE-friendly as search engines can't use Ajax. Ajax should just be used to provide a better experience at your site. It shouldn't be used as the only way to reach your content.

Member Avatar for Candy_ME

Asynchronous changes to the document have been possible ever since the advent of DOM scripting. Approaches can include: loading new script by creating new script element, iframes, and in IE the default Download behavior.
In many cases, and for the purposes httpwebwitch outlines, the XMLHTTPObject doesn't make things necessarily any easier than they already are. Unless the SE bot actually runs the Javascript, it cannot reliably detect the instantiation of the XMLHTTPObject. If it tries to detect via the inclusion of certain strings in the script document then this can be sidestepped very easily using a little string manipulation.

Member Avatar for stymiee

Asynchronous changes to the document have been possible ever since the advent of DOM scripting. Approaches can include: loading new script by creating new script element, iframes, and in IE the default Download behavior.
In many cases, and for the purposes httpwebwitch outlines, the XMLHTTPObject doesn't make things necessarily any easier than they already are. Unless the SE bot actually runs the Javascript, it cannot reliably detect the instantiation of the XMLHTTPObject. If it tries to detect via the inclusion of certain strings in the script document then this can be sidestepped very easily using a little string manipulation.

This is not true at a right down to your explanation of how Ajax started. It started with Microsoft introducing the XMLHttpRequest object in Internet Explorer.

And no search engine can do anything with Ajax at all at any level. They don't run JavaScript which is why it is considered so bad to use for important page feature like delivering content and site navigation.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.