cd /home/onlinedentist/public_html && /usr/local/bin/php /home/onlinedentist/public_html/wp-cron.php

Step 2: The Real Culprit – AIOSEO, Polylang, and a Broken Sitemap

Step 3: Switching to Google XML Sitemaps

Step 4: The Next Problem – Double Sitemaps

“One or more plugins are affecting your site’s ability to be indexed.”

• /sitemap.xml (from the plugin, correct)
• /wp-sitemap.xml (from WordPress core, unnecessary)

Step 5: Disabling the WordPress Core Sitemap

add_filter( 'wp_sitemaps_enabled', '__return_false' );

add_action( 'init', function() {
    remove_action( 'init', 'wp_sitemaps_get_server' );
    add_filter( 'wp_sitemaps_enabled', '__return_false', 9999 );
}, 0 );

# --- Disable WordPress core sitemap ---
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-sitemap\.xml$ [OR]
RewriteCond %{REQUEST_URI} ^/wp-sitemap-index\.xml$ [OR]
RewriteCond %{REQUEST_URI} ^/wp-sitemap-posts-[0-9]+\.xml$
RewriteRule .* - [R=404,L]
</IfModule>

Step 6: Verifying the Robots.txt and Cache Integration

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap URL: https://online-dentist.hu/sitemap.xml
Update interval: 1800 seconds
Pages per interval: 10

What I Learned

• Scheduled cache preloading only works if the sitemap works.
• A broken or plugin-conflicted sitemap silently breaks the preload job.
• AIOSEO and Polylang don’t play well together.
• The sitemap index looks correct, but the sub-sitemaps are often invalid.
• Google XML Sitemaps still works best for multilingual static sitemaps.
• It doesn’t overthink language folders – it just lists every URL.
• The WordPress core sitemap must be disabled when using a custom sitemap plugin, or you’ll confuse both Google and W3TC.
• Virtual files are fine.
• You don’t need physical robots.txt or sitemap.xml – WordPress can handle them dynamically.

Final Thoughts

• One active sitemap (/sitemap.xml)
• One dynamic robots.txt
• A fully working cache preload system

The post [8] When a Scheduled Cache Task Broke My Sitemaps, and How I Rebuilt the Whole System first appeared on Digital Nomad Blog.

When you build websites for a living, you eventually face the same paradox I did: Your optimization plugin becomes the bottleneck.

That’s exactly what happened to me while optimizing my WordPress site – online-dentist.hu. This post is a deep-dive case study of how I went from “cache doesn’t work at all” to a fast, stable, and fully automated setup, combining the best of modern WordPress performance practices.

The Background

My site was running WP Rocket, one of the most popular speed optimization plugins.
However, despite correct configuration and a valid license, the cache never activated.

The response headers always returned:

# yaml

cache-control: no-cache, no-store, must-revalidate
x-powered-by: PHP/8.4.12

The WP Rocket “Cache” tab was missing, and even though the plugin created cache files under
/wp-content/cache/wp-rocket/, the server never served them.
So began a deep technical journey into headers, .htaccess rules, and server-level cache control.

Step 1: Debugging WP Rocket

Over several rounds of testing, I:

• verified headers through DevTools and WebPageTest,
• inspected .htaccess, advanced-cache.php, and wp-config.php,
• reinstalled WP Rocket cleanly,
• and even wrote a custom PHP header plugin to override Cache-Control.

Despite all this, the cache remained inactive – no x-rocket-cache: hit, no static file delivery.

The final clue came from my hosting provider’s support team:

“Your server uses Apache. LiteSpeed (Accelerate WP) is available, but the Rocket rewrite rules won’t apply here.”

In other words, WP Rocket was operating in PHP-only mode – optimizing assets, but not caching statically.

Step 2: Switching to LiteSpeed Cache

Following the provider’s advice, I activated Accelerate WP, which is essentially LiteSpeed Cache. Initially, I was optimistic – the plugin integrated well, and PageSpeed scores jumped slightly.

However, when inspecting response headers, I saw:

# yaml

x-litespeed-cache-control: no-cache
x-litespeed-server-type: NONE

That second line said it all:

The site wasn’t running on a real LiteSpeed server – it was still Apache behind the scenes. The plugin worked only as a frontend optimizer, not as a true server-level cache.

Step 3: The Aha Moment: W3 Total Cache

So I made a final switch to W3 Total Cache, a plugin I had used many years ago –
and it instantly clicked (literally).

The response headers finally looked like this:

# yaml

cache-control: max-age=3600, public
etag: "44af3fc372e6e07881169370dc86fed2"
last-modified: Wed, 15 Oct 2025 10:50:41 GMT
x-powered-by: W3 Total Cache/2.8.1

At last – proper caching, full gzip compression, and predictable static file handling.

WebPageTest confirmed it:

It wasn’t just faster – it was consistent.

Step 4: Fixing Mobile and Post Pages

After celebrating, I noticed a new issue: Blog post pages sometimes failed to load on mobile devices.

The reason?

By default, W3 Total Cache serves a single static HTML version for all devices – unless you manually enable Mobile User Agent Groups.

Solution:

• Navigate to Performance → User Agent Groups.
• Enable “Mobile” and “Create a separate cache group.”
• Purge all caches.

That fixed it instantly – mobile visitors now get their own cached version, and posts render perfectly.

Step 5: Preloading the Cache

By default, W3 builds cache files on first visit, which means the first user after a purge always triggers a slow load.

To automate this, I enabled:

• Automatic page cache priming (sitemap preload) under Performance → Page Cache
• Sitemap: https://online-dentist.hu/sitemap.xml
• Interval: every 15 minutes, 20 pages per batch

Additionally, I tested WP Warm Cache, a simple but powerful plugin that preloads all URLs in the background.

Now, the cache stays warm 24/7 – even when no one visits.

Results & Key Takeaways

After the final setup:

• TTFB: 0.4–0.6 s
• LCP: < 2.5 s
• Speed Index: ~4 s
• Mobile PageSpeed: 90+ consistently
• Server load: Stable, low CPU usage

What I Learned

• Not all cache plugins can work on every server.
  • WP Rocket expects write access and proper .htaccess rewriting – not always possible on shared Apache hosting.
• LiteSpeed Cache ≠ LiteSpeed Server.
  • Unless your host runs LSWS or OLS, the plugin can’t deliver cached HTML.
• W3 Total Cache remains a powerhouse
  • especially for Apache-based WordPress sites that need predictable caching and full control.
• Always verify with response headers, not assumptions.
  • The truth is in cache-control and x-powered-by.
• Preload is everything.
  • A cache is only useful if it’s ready before your visitors arrive.

Final Thought

It took patience, dozens of tests, and some friendly frustration, but I finally turned a stubborn WordPress install into a finely tuned, high-performing system.

The takeaway?

Speed doesn’t come from a single plugin – it comes from understanding how they interact with your server.

The post [2] From Cache Chaos to Performance Clarity first appeared on Digital Nomad Blog.