After a redesign, a website may look faster and easier to use while important pages lose visibility in Google. The search result may show an old title, product links may go undiscovered, or a page may appear without its primary text.
These symptoms do not prove that JavaScript is the cause. A JavaScript SEO problem exists when an important element is available to a visitor but missing, changed, or unreliable in the version Google can process.
The quickest useful diagnosis is to compare three things: what the server returns, what appears after JavaScript runs, and what Google's rendering tools show. If the difference affects the primary content, H1, canonical, index directives, or important links, the site has a measurable technical risk. The next question is how many page types and business-critical URLs share the same defect.
JavaScript SEO checks whether a search engine receives the content and technical signals of a page that relies on JavaScript. Rendering is the step in which code runs and produces the completed page.
Using JavaScript is not a problem by itself. Google runs JavaScript, and client-side rendered sites can appear in Search. The business risk comes from dependencies that can fail or produce different output: blocked resources, API errors, session state, consent choices, routing logic, or code that does not finish correctly.
The practical question is not which framework the site uses. It is whether Google consistently receives:
A server-rendered page can still have the wrong canonical or broken links. A client-rendered page can work correctly. The output is the evidence.
Google currently describes three main phases for JavaScript pages: crawling, rendering, and indexing. Googlebot first requests the URL and receives the server response. Google can then render the page with its Web Rendering Service, analyze the resulting HTML, extract links, and use the rendered content for indexing. The full process is documented in Google's JavaScript SEO basics.
Crawling and rendering are separate steps. Google says a page that returns 200 is placed in the rendering queue unless a robots directive prevents indexing. Rendering may happen quickly, but it can take longer. If a necessary resource is blocked, an API request fails, or the code produces an error, the rendered result can be incomplete.
Google also notes that not every bot runs JavaScript. This is a practical reason to make essential content and navigation available without a fragile chain of browser actions.
A reliable test compares three states of the same URL.
| Version | What it shows | Main question |
|---|---|---|
| Source HTML | The server response before JavaScript runs | Are the primary content, links, metadata, and directives available immediately? |
| Browser DOM | The page after JavaScript runs in a particular browser session | Does the result depend on cookies, login, location, consent, cached data, or interaction? |
| Google rendered output | The rendered HTML and resources available through Google's testing tools | Does Google receive the same meaningful page and signals? |
Compare at least the primary text, H1, important links, canonical, robots directives, structured data, and error state. A difference is not automatically a defect. A form or interactive filter may reasonably appear after the initial response. The risk is material when the difference changes what the page is about, prevents discovery of an important URL, or gives Google a conflicting instruction.
Google recommends using URL Inspection or the Rich Results Test to examine rendered HTML, loaded resources, and JavaScript errors when a rendering problem is suspected. Its JavaScript troubleshooting guide also warns that a normal browser session may not reproduce Googlebot's state because storage and cookies are cleared between page loads.
The most useful signs are specific and repeat across a page type:
href;200 while JavaScript displays a not-found message;Google's crawlable link guidance says links are generally crawlable when they use an <a> element with an href that resolves to a real web address. A script event without a usable href is not a reliable substitute.
Priority depends on business impact and scope. Missing service copy, an empty product page, or an undiscoverable category is more serious than a secondary interactive element. One affected article may need a local correction. A shared template defect can affect hundreds of URLs and deserves a higher priority even when the visible symptom looks identical.
A missing page in Google does not prove a rendering problem. The cause may already be present in the server response: crawling is blocked, noindex is set, the canonical points elsewhere, the URL redirects, or the server returns the wrong status. Google may also process the page correctly and still choose not to index it.
The distinction is straightforward. If the error is already present before JavaScript runs, it did not originate during rendering. If the source HTML is correct but an important element disappears or changes after JavaScript runs, the implementation deserves closer investigation.
This boundary prevents expensive but irrelevant fixes. A platform migration will not correct an intentional noindex. Editing page copy will not help when a shared template never delivers that copy to Google. Detailed rules for duplicate and indexing signals belong to the guide on robots.txt, noindex, and canonical. Response and redirect choices belong to the guide on HTTP status codes for SEO.
No rendering model guarantees SEO. Some make essential information available earlier, while others depend more heavily on successful JavaScript execution.
| Model | Initial response | What to verify |
|---|---|---|
| CSR | Often an application shell plus JavaScript files | Content and links appear reliably without extra user action |
| SSR | HTML containing the primary content | Server and browser output remain consistent in meaning and signals |
| SSG | Pre-generated HTML | Required URLs are generated and their data updates when expected |
| Hybrid | Different methods for different page types | Products, categories, services, and articles behave consistently within their templates |
CSR can work well for Google. SSR and SSG can still produce incomplete content, stale pages, or conflicting canonicals. Hydration can also replace a correct initial page with an empty or inconsistent state if the browser-side code fails.
Google now describes dynamic rendering as a workaround, not a recommended long-term solution. Serving a separate rendered version to crawlers adds complexity and creates another place where user and crawler output can diverge. Google recommends server-side rendering, static rendering, or hydration as better long-term approaches, but the final choice still needs to be tested on the site's real page types.
Do not accept a framework name or a statement such as "Google runs JavaScript" as proof. Ask for a short evidence package based on representative URLs:
One example URL is not enough when products, categories, service pages, and language versions use different templates. The test set should cover the states that matter: logged out, mobile, different languages, valid and invalid routes, successful and failed API responses, and any consent flow that can affect primary content.
The result should identify where the difference first appears and whether it is isolated, template-wide, or platform-wide. Only then can the team choose an implementation change with a clear reason.
An internal check may be sufficient when one page is affected, the cause is obvious, and the correction can be confirmed in the server response and Google's rendered output.
A broader diagnosis is appropriate when visibility changes after a redesign, multiple templates show the same symptom, language versions behave differently, content depends on several external services, or the team is considering a new platform without proving the current defect.
SeoWebDesign's technical SEO audit can compare source and rendered output, group affected URLs by template, and separate JavaScript failures from crawling controls, HTTP responses, and content issues. The goal is a prioritized correction based on evidence, not a framework change based on suspicion.
