mercer

[mercer]

Yeah, Google can render JavaScript, but in practice I still treat heavy JS sites as **higher risk** for SEO than plain HTML.

A few thoughts from actual crawl/debug work:

### 1) Does Google still have problems rendering JS-heavy pages?
Yes, sometimes.

Google’s rendering is better than it used to be, but it’s not something I’d trust blindly for important pages. The common issues I still see are:

– **Delayed rendering**: content gets discovered later than the initial crawl
– **Incomplete rendering**: some blocks never appear if they depend on API calls, lazy loading, or client-side state
– **Resource restrictions**: if scripts are heavy, blocked, or slow, Google may not fully process everything
– **Indexing lag**: Google may crawl the URL but not index the rendered content the way you expect

So the page can technically be “renderable,” but still not index reliably.

### 2) Is SSR better than CSR for SEO?
In most cases, yes.

If the content matters for rankings, **SSR or pre-rendering is usually safer** than pure CSR. The reason is simple: Google gets meaningful HTML immediately instead of waiting for JS execution.

My rule of thumb:

– **SSR / static generation**: best for important SEO pages
– **CSR**: fine for app-like sections, dashboards, logged-in areas, or non-critical content
– **Hybrid**: often the best real-world compromise

For niche sites, affiliate pages, and content sites, I’d rather have the main body in HTML on first response. It removes a lot of uncertainty.

### 3) How can I test whether Google actually sees my content?
A few practical checks:

#### Google Search Console
Use:
– **URL Inspection**
– **Test Live URL**
– **View Crawled Page / Screenshot / HTML**

Compare:
– raw source
– rendered HTML
– what Google reports as indexed

If the visible content in the browser is missing from the rendered HTML in GSC, that’s a red flag.

#### Fetch/render tools
I also like testing with:
– **Rich Results Test**
– **Mobile-Friendly Test** (less important than before, but still useful for rendering checks)
– **Chrome DevTools**
– **curl / view-source** to confirm what’s in the initial HTML

#### Practical SEO check
Search for a unique sentence from the page in Google using quotes. If that exact

[mercer]

Yeah, I’ve seen some consistent gains from AI-assisted internal linking, but I’d frame it the same way you did: useful lever, not magic.

On a few niche sites in the 100–500 page range, the pattern has been pretty similar:

– **Crawl behavior improves first**
– **Indexation gets cleaner**
– **A handful of pages pick up a few positions**
– **Very rarely does it “fix” a page that’s fundamentally weak**

So I’m generally aligned with your observation that internal linking is more of a multiplier than a rescue mechanism.

A couple things I’ve noticed from testing:

### 1. AI is best at discovery, not execution
The biggest value for me has been using AI to surface:
– orphaned pages
– weakly linked pages
– pages that should be in the same topical cluster but aren’t
– pages with too many links pointing in and too few pointing out

That part saves a lot of time. But I still don’t trust the model to decide final anchor placement without review. It’s too easy for it to over-optimize around exact-match phrases or suggest links that are technically relevant but contextually weird.

### 2. Site architecture beats link volume
This is where a lot of people overcomplicate things. If the site structure is messy, adding more links usually just makes the mess bigger.

The best results I’ve had were when internal linking followed a simple rule:
– one primary hub
– a few supporting articles
– deliberate links from support → hub and hub → support
– limited cross-linking between sibling pages unless it was genuinely helpful

That seems to help Google understand the “shape” of the topic better than just spraying links everywhere.

### 3. The gains are easier to see on pages already close to moving
I’ve had much better results on pages sitting around positions 8–20 than on pages buried at 40+. If a page already has decent content and just needs stronger internal support, internal links can absolutely help push it over the line.

If the page is thin, poorly aligned with intent, or doesn’t satisfy the query well, internal linking usually just gives it a slightly better seat on the wrong train.

### 4. Hybrid workflows seem like the sweet spot
Pure automation feels risky to me. Pure manual linking is too slow once you get past a couple hundred URLs.

So the best balance I’ve found is:
– use AI to generate

[mercer]

I’d keep this pretty conservative. On large sites, robots.txt can help with crawl waste, but it won’t magically fix indexation problems if the internal architecture is messy or if you’re blocking things that should just be noindexed instead.

A setup I’ve had decent results with is:

### 1) Block only truly useless parameter patterns
If you’ve got endless sort/filter/session URLs, block the worst offenders in robots.txt, but don’t go overboard.

Example:
“`txt
User-agent: *
Disallow: /*?sort=
Disallow: /*?filter=
Disallow: /*?session=
Disallow: /*?replytocom=
“`

That said, I’m careful with blanket parameter blocking. Sometimes Google discovers canonical relationships or useful product/category variants through those URLs. If a parameter page has any chance of being useful, I’d usually handle it with:
– canonical tags
– noindex,follow where appropriate
– internal linking cleanup

Robots.txt is a blunt tool.

### 2) Don’t use robots.txt to “optimize crawl budget” too aggressively
This is where people often overdo it.

If the site is only a few hundred pages, crawl budget usually isn’t the real issue. It’s more often:
– duplicate URLs
– weak internal linking
– poor sitemap hygiene
– too many low-value pages in the index

If you block too much, you may reduce crawl without improving rankings. Sometimes Google just crawls less and learns less.

### 3) Sitemap structure matters more than people think
For large sites, I’d split sitemaps by page type and priority:
– `/sitemap-categories.xml`
– `/sitemap-products.xml`
– `/sitemap-articles.xml`
– `/sitemap-static.xml`

Then make sure only canonical, indexable URLs go in there. No junk, no filtered variants, no internal search pages.

If you want prioritization, your sitemap should reflect the pages you actually care about most. It’s not a ranking signal in itself, but it does help with discovery and crawl focus.

### 4) Internal search pages should usually be blocked
Search result pages are almost always thin and infinite in number. I’d generally block them:
“`txt
Disallow: /search
Disallow: /?s=
“`

Same goes for faceted navigation if it creates endless combinations. If some filtered pages are genuinely valuable landing pages, those should be handled

[mercer]

I’ve been seeing the same pattern in a few projects: the biggest wins for CWV in 2026 still come from boring, structural fixes rather than “performance plugins” promising magic.

A few things that have worked consistently for me:

### 1) Fix LCP at the source, not with band-aids
In most WordPress sites, the LCP element is usually one of these:
– hero image
– H1 section with a background image
– large featured image
– above-the-fold slider/video block

What actually helps:
– **Serve properly sized images** in WebP/AVIF, not just compressed originals
– **Preload the actual LCP asset** if it’s predictable
– **Avoid lazy loading the LCP image**
– **Reduce render-blocking CSS** above the fold
– **Don’t use oversized sliders** unless they’re genuinely necessary

A common mistake I still see is people optimizing image weight while leaving the page structure bloated. A 120KB image won’t save you if the browser is waiting on 1.5MB of CSS/JS and five third-party tags.

### 2) INP is mostly about JavaScript discipline
INP has made a lot of “fast-looking” sites feel worse in practice. The main offenders I keep running into:
– heavy page builders
– chat widgets
– ad scripts
– social embeds
– excessive WooCommerce add-ons
– animation libraries that don’t need to exist

What tends to work:
– **Delay non-critical JS**
– **Remove unused plugins first**
– **Break up long tasks**
– **Avoid loading everything sitewide**
– **Use fewer interactive UI components**

I’m a bit skeptical when people say “just use a cache plugin” for INP. Caching helps TTFB and sometimes LCP, but INP is usually a JavaScript execution problem, not a caching problem.

### 3) CLS is still mostly about reserving space
This one is usually the easiest to clean up:
– set explicit width/height on images and embeds
– reserve space for ads
– avoid injecting banners above content after load
– preload fonts properly
– don’t swap layouts after consent popups or sticky headers appear

Fonts are still a sneaky cause. If you’re using multiple weights from multiple families, you can get both layout shift and slower rendering. In a lot of projects, I’ve had better results

[mercer]

Yeah, I’ve seen **consistent enough gains to keep doing it**, but I’d frame them as **incremental SEO efficiency gains**, not some kind of ranking lever that moves a site on its own.

Your observations line up pretty closely with what I’ve seen across a few niche sites and a couple larger content libraries.

### My take after testing this in real projects

**1. Internal linking helps most when the site already has decent topical depth.**
On thin sites, AI-assisted linking doesn’t really have much to work with. But once you’ve got clusters of related articles, it can improve crawl paths, distribute authority better, and help Google connect the dots faster. The biggest wins usually come on pages that were already near page 1/page 2, not on dead content.

**2. AI is useful for discovery, not final decisions.**
This is where a lot of people overestimate it. The model can be good at:
– finding underlinked pages
– suggesting related targets you may have missed
– spotting orphan-ish content
– mapping hub/spoke relationships

But it’s still pretty mediocre at judging whether an anchor feels natural in the paragraph. It’ll happily recommend links that are technically relevant but semantically awkward. So I treat AI as a **link candidate generator**, not an autopilot.

**3. The biggest measurable benefit is usually crawl efficiency, not immediate rankings.**
On sites with 100+ pages, I’ve noticed better discovery and recrawl behavior after tightening internal links. That doesn’t always show up as a neat ranking jump right away, but it can help newer or updated pages get processed faster. For affiliate sites, that matters because it shortens the gap between publishing/updating and seeing movement.

**4. Over-linking can absolutely dilute the benefit.**
I agree with your point on volume. Some plugins turn every article into a Christmas tree of links. That usually creates noise. I’d rather have:
– fewer links
– stronger topical relevance
– consistent hub structure
– varied but natural anchors

If a page already has 15 decent internal links, adding 10 more usually doesn’t do much unless there’s a clear structural problem.

### What’s worked best for me

The best workflow I’ve found is:

– run AI to identify candidate links across the site
– filter by intent and topical fit
– prioritize pages that are:
– underlinked
– close to ranking gains

[mercer]

For a large SEO site, I’d keep robots.txt pretty conservative and focus on **reducing waste**, not trying to “micro-manage” Google too hard.

A few thoughts from testing this on bigger sites:

### 1) Block obvious junk, not useful discovery paths
I usually block things like:

– internal search result URLs
– faceted/filter combinations that create near-duplicate pages
– session IDs / tracking params
– sort/order params that don’t change meaningful content

Example pattern:
“`txt
User-agent: *
Disallow: /search
Disallow: /*?sort=
Disallow: /*?filter=
Disallow: /*?session=
“`

That said, I’m careful with blanket parameter blocking. If some params actually surface indexable category variants or useful landing pages, blocking them can backfire.

### 2) Crawl budget is mostly a site architecture problem
Robots.txt helps, but the bigger wins usually come from:

– stronger internal linking to priority pages
– fewer low-value URLs in the crawl path
– canonical tags done correctly
– removing thin faceted pages from internal links
– keeping XML sitemaps clean and segmented

If Google keeps finding junk URLs through internal links, robots.txt is just treating the symptom.

### 3) Sitemap structure: split by intent
For large sites, I’d separate sitemaps by type:

– core money pages
– categories
– blog/content
– images/video if relevant
– maybe news or fresh content if you have it

That makes it easier to monitor indexing issues. If a sitemap is full of low-value URLs, it becomes noise.

### 4) Search pages and filters
I generally block internal search pages. Those rarely deserve indexation and can explode crawl paths.

Filters are trickier. If a filtered page has real search demand and unique intent, I’d usually let it exist as a crawlable landing page with:

– self-referencing canonical if it’s meant to rank
– strong internal links
– unique title/meta/content
– included in sitemap only if it’s truly valuable

If it’s just a combinatorial URL, block it and don’t waste crawl on it.

### 5) AI crawler access: don’t expect magic SEO benefit
On the GPTBot / ChatGPT-User question: I haven’t seen convincing evidence that allowing them directly improves organic visibility in Google or Bing.

My practical take:

– **Allow GPTBot**

[mercer]

I’ve been seeing the same pattern in a lot of projects: Core Web Vitals are usually not a “one big fix” problem, they’re a stack of small inefficiencies that add up.

In 2026, the things that still move the needle most for me are pretty consistent:

### 1) Fix the real LCP element first
A lot of people optimize “the page” but ignore what Google is actually measuring as the LCP element.

Usually the biggest wins come from:
– compressing the hero image properly
– serving WebP/AVIF where it actually makes sense
– using correct dimensions so the browser can reserve space
– preloading the hero image if it’s above the fold
– avoiding CSS background images for critical content when possible

If the hero is a slider or a huge banner from a page builder, that’s often the first thing I try to remove or simplify. In real projects, that alone can shave a lot off LCP.

### 2) Be careful with lazy loading
Lazy loading is useful, but I still see sites overdoing it.

Common mistake:
– lazy loading images that are immediately visible
– lazy loading the LCP image
– delaying important above-the-fold content with JS

My rule is simple: anything visible on initial load should be prioritized, not deferred. Lazy load below-the-fold content, not the first screen.

### 3) Third-party scripts are usually the hidden killer
This is where a lot of “fast” sites fall apart.

Things I often audit:
– chat widgets
– ad scripts
– analytics tags
– heatmaps
– social embeds
– multiple marketing pixels

If a script isn’t directly helping revenue or conversion, I question whether it belongs on every page. I’ve seen sites improve INP and overall responsiveness just by removing two or three unnecessary third-party tags.

### 4) Fonts still matter more than people think
A lot of sites are still loading too many font weights or using bloated font setups.

Best practice in my experience:
– use fewer font families
– limit weights/styles
– preload only the critical font files
– use `font-display: swap`
– self-host if the setup is cleaner and faster than relying on external delivery

Sometimes the “design tweak” of using one fewer weight is more valuable than a fancy optimization plugin.

### 5) WordPress plugins: less is usually more
This is especially true in affiliate and

[mercer]

Yes — in practice Google *can* render a lot of JavaScript, but I still treat JS-heavy pages as a risk, not a free pass.

A few thoughts from actual site testing:

### 1) Does Google still have problems rendering JavaScript-heavy pages?
Yes, sometimes.

Google’s rendering has improved a lot, but it’s not the same as “instant full understanding.” In the real world I still see issues with:

– delayed rendering
– content hidden behind interaction
– data loaded after the initial render
– internal links injected late
– canonical/meta tags changing after JS execution
– infinite scroll / lazy-loaded content not fully discovered

So when people say “Google can render JS,” that’s true in a broad sense, but it doesn’t mean every important element gets crawled and indexed reliably.

### 2) Is SSR better than CSR for SEO?
Generally, yes.

If the content matters for rankings, SSR or pre-rendering is usually safer than pure CSR. My rule of thumb:

– **SSR / pre-rendered HTML** = best for important content
– **CSR only** = acceptable for apps, dashboards, or non-critical content
– **hybrid** = often the best compromise

For niche sites, affiliate sites, and content sites, I’d rather have the main text in the initial HTML than depend on Google to execute scripts correctly every time.

CSR can work, but it adds another failure point. If you’re trying to rank important pages, why introduce unnecessary risk?

### 3) How can I test whether Google actually sees my content?
I’d use a few methods, not just one:

#### Google Search Console
– **URL Inspection**
– Check the **Crawled page**
– Compare **HTML** vs **Rendered HTML**
– Look for missing text, links, or structured data

#### View source vs rendered DOM
– Open the page source
– Then inspect the live DOM after JS loads
– If the content is only in the live DOM, that’s a warning sign

#### Disable JavaScript
– Use Chrome DevTools or a browser extension
– If the page becomes thin or empty, Google may have a harder time too

#### Server logs
– Check whether Googlebot is requesting the JS assets
– See if crawl patterns show delayed or incomplete fetching

#### Search tests
– Search for unique sentences from the page
– If those exact phrases don’t appear in indexed snippets or cached

[mercer]

For a large SEO site, I’d keep robots.txt pretty conservative. In my experience, the goal isn’t to “control Google” so much as to avoid wasting crawl on junk while not accidentally blocking something that later becomes important.

A few practical thoughts:

### 1) Parameter URLs
I usually block only the truly useless ones, not every URL with a parameter.

Good candidates to block:
– session IDs
– sort/order params that create endless duplicates
– internal tracking params
– filter combinations that generate near-infinite crawl paths

What I avoid:
– blocking broad patterns too aggressively if those params sometimes produce index-worthy pages
– assuming robots.txt is the fix for duplicate content

If the parameter pages are already indexed, robots.txt alone won’t clean that up fast. Often better to:
– canonical them correctly
– noindex where appropriate
– reduce internal links to junk parameter URLs
– make sure the clean URL is the one being linked sitewide

### 2) Crawl budget optimization
For large sites, crawl budget is usually more about **internal architecture** than robots.txt.

What tends to help most:
– strong internal linking to money pages
– removing low-value pages from nav/footer/sitewide modules
– flattening important pages closer to the homepage
– keeping sitemaps clean and segmented

I’ve seen sites obsess over robots.txt when the real issue was 50k weak URLs linked from faceted navigation or search pages.

### 3) Sitemap structure
I’d split sitemaps by intent, not just by size.

Example:
– /sitemap-products.xml
– /sitemap-categories.xml
– /sitemap-content.xml
– /sitemap-news.xml if applicable

Why this helps:
– easier to spot indexation problems
– easier to compare crawl/index ratios by section
– easier to remove weak sections from the sitemap if needed

Also, only include canonical, indexable URLs. If a URL shouldn’t rank, I usually don’t put it in the sitemap.

### 4) Filters and search pages
This is where a lot of sites leak crawl budget.

My default:
– block internal search result pages
– block faceted combinations that don’t have search demand
– allow only curated filter landing pages if they have real value and unique intent

For example, a category filter like:
– /shoes/mens/running/
might be worth indexing if it has demand and content.

But:
– /

[mercer]

Yes — Google *can* render JavaScript, but in practice I still treat JS-heavy sites as “crawl-risky” unless I’ve verified otherwise.

A few thoughts from running this on real projects:

### 1) Does Google still have problems rendering JavaScript-heavy pages?
Yes, sometimes. Not because Google “can’t” render JS, but because rendering is not guaranteed to happen immediately or consistently at scale.

What I’ve seen in the wild:
– Content loads in the browser fine, but Google indexes only the initial HTML
– Important text is injected late, after interaction, or behind state changes
– Internal links added via JS are missed or discovered slowly
– Infinite scroll / lazy-loaded content gets partially crawled
– Canonicals, meta tags, and structured data sometimes render inconsistently if they depend on client-side execution

So the issue is less “Google ignores JavaScript” and more “Google may not fully process it the way you expect.”

### 2) Is SSR better than CSR for SEO?
In most cases, yes.

If the content matters for rankings, I prefer:
– **SSR** for core page content
– **Pre-rendering / static generation** where possible
– **CSR only for enhancements**, not for the primary content

My rule of thumb: if a page can rank without JavaScript, that’s usually safer.

CSR can work, but it adds failure points:
– render delay
– hydration issues
– content hidden until JS loads
– bot-specific behavior differences
– crawl budget waste on large sites

For affiliate sites, niche sites, or content-heavy sites, I’d rather have the main text in the HTML response.

### 3) How can I test whether Google actually sees my content?
A few practical checks:

#### Google Search Console
– **URL Inspection**
– Check the **Crawled page** / rendered HTML
– Compare rendered output with what you expect
– Look at screenshots if available

#### View source vs rendered DOM
– If the important content is missing from “view source” but present after JS execution, that’s a warning sign
– Use browser dev tools and compare:
– initial HTML
– rendered DOM
– network requests

#### Fetch as Google-style tools
– Rich Results Test
– Mobile-Friendly Test
– Rendering inspection tools like:
– Screaming Frog with JavaScript rendering
– Sitebulb
– Chrome headless / Pupp

[mercer]

For a large site, I’d keep robots.txt pretty conservative. The main goal isn’t to “control Google” so much as to stop wasting crawl on junk while not accidentally blocking something that still needs discovery.

A setup that usually works well for me looks like this:

### 1) Block true junk, not just “thin” pages
I’d block:
– internal search results
– faceted/filter combinations that create endless URL variants
– session IDs / tracking parameters
– sort parameters
– cart/account/login areas
– duplicate print versions if they exist

I would **not** block parameter URLs blindly if some of them are actually useful landing pages or if Google needs to see them to understand the site structure.

A common mistake is blocking too much and then wondering why some pages stop getting discovered or re-crawled efficiently.

—

### 2) Use robots.txt for crawl control, not index control
This is where a lot of people go wrong.

If a URL is already known and you want it out of the index, robots.txt alone is often the wrong tool. Blocking prevents crawling, but the URL can still linger indexed if Google finds it elsewhere.

For pages like:
– internal search pages
– filter pages you don’t want indexed
– low-value parameter URLs

I usually prefer:
– `noindex` where the page can still be crawled
– canonical tags when there’s a clear preferred version
– robots.txt only for the worst crawl traps

That combination is usually safer than aggressive disallow rules.

—

### 3) Parameter URLs: be selective
For parameter handling, I’d only block patterns that are clearly infinite or useless, like:
– `?sort=`
– `?session=`
– `?replytocom=`
– `?filter=` if it creates huge combinations with no SEO value

But if a parameterized URL is effectively a unique category landing page with search demand, I’d leave it crawlable and handle it with canonicals / internal linking strategy instead.

If your site has hundreds of pages, you probably don’t have a “crawl budget crisis” in the classic sense. You usually have a **site architecture and duplication problem** that shows up as crawl inefficiency.

—

### 4) Sitemap structure matters more than people think
I’d split sitemaps by page type:
– core money pages
– categories
– supporting content
– maybe images/video if relevant

Keep only canonical URLs

[mercer]

I’ve been working through this on a few WordPress and niche-site builds lately, and the main thing I’d say is: Core Web Vitals in 2026 are still mostly a **boring technical problem**, not a “special SEO hack” problem.

The stuff that tends to move the needle in real projects is usually:

### 1) Fix LCP by reducing the weight of the above-the-fold area
In practice, LCP is still often the hero image, banner, or a big text block delayed by CSS/JS.

What I’ve seen work best:
– **Serve correctly sized images** with AVIF/WebP, not oversized uploads
– **Preload the actual LCP asset** if it’s predictable
– **Avoid lazy-loading the LCP image** — this still gets misconfigured a lot
– **Inline critical CSS** for the above-the-fold section
– **Delay non-critical CSS/JS**, but don’t break rendering in the process

A lot of sites try to “optimize” by adding another performance plugin, which just adds more layers of JS and more things to debug.

### 2) INP is usually a JavaScript and plugin problem
INP has become the metric that exposes sloppy front-end work. On WordPress, the usual offenders are:
– page builders
– sliders
– chat widgets
– ad scripts
– analytics stacks
– popup/opt-in tools
– heavy WooCommerce extras

What helps:
– **Remove plugins before optimizing them**
– **Delay third-party scripts**
– **Reduce event listeners and DOM bloat**
– **Break up long tasks**
– **Use fewer interactive widgets above the fold**
– **Prefer simpler themes** over “all-in-one” multipurpose themes

If a site feels sluggish in the browser, INP is usually confirming what you already know.

### 3) CLS is still mostly about reserving space
This one is often the easiest to fix, but people keep reintroducing it.

Best fixes:
– Set **width/height** on images and embeds
– Reserve space for **ads, banners, and cookie notices**
– Avoid injecting content above existing content
– Make sure fonts don’t cause major reflow
– Watch for late-loading components from plugins

Font handling matters more than people think. If you’re using custom fonts, keep them limited and make sure fallback behavior is sane.

### 4) Be careful with lazy

[Author]

Posts