Can you warm Base44's pre-render cache? What we found, and what to do instead

No, you can’t warm Base44’s pre-render cache by requesting your pages. We tested it: pages that were serving Base44’s summary to crawlers were requested every 10 seconds for four minutes with Googlebot’s user agent, and none of them got a render. Base44 serves crawlers whatever its render cache holds, and the only refresh trigger it documents is publishing. What a script can do is monitor which pages crawlers are getting as the summary, so you know where you stand.

The mechanism is explained in how Base44 pre-rendering works.

What we tested#

• Repeated requests on summary pages. 28 pages serving the summary, each requested every 10 seconds for four minutes. None rendered.
• Fresh URLs. Twelve pages with a render, requested with a made-up content parameter (?b44check=123) so they’d be new cache entries. All stayed on the summary for three minutes of repeated requests.
• Tracking parameters. The same pages with ?utm_source=... got the render immediately, because Base44 ignores tracking parameters in its cache.
• Timing. Every response came back within a second or two, renders included. A headless browser can’t render a React app that fast, so what crawlers get is always a stored copy.

Renders do appear in the background: in our first test, 39 pages gained one between two passes minutes apart. But the timing is Base44’s, and a day later 13 of 44 rendered pages were back on the summary.

A monitoring script#

This checks every page in your sitemap, plus any extra URLs you list in extra-urls.txt (useful for record pages, which aren’t in Base44’s sitemap), and reports which ones crawlers are getting as the summary.

#!/usr/bin/env bash
# check-base44.sh: which pages serve Base44's summary to crawlers right now?
set -euo pipefail
SITE="${1:?usage: check-base44.sh https://yourdomain.com}"
UA='Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)'

urls=$(curl -s "$SITE/sitemap.xml" | grep -o '<loc>[^<]*</loc>' | sed 's/<[^>]*>//g')
[ -f extra-urls.txt ] && urls="$urls"$'\n'"$(cat extra-urls.txt)"

total=0; summary=0
for u in $urls; do
  total=$((total+1))
  if curl -s -A "$UA" "$u" | grep -q 'id="seo-snapshot"'; then
    summary=$((summary+1)); echo "SUMMARY   $u"
  else
    echo "rendered  $u"
  fi
  sleep 1
done
echo "$summary of $total pages are serving the summary to crawlers"

Run it after each publish and once a week:

chmod +x check-base44.sh
./check-base44.sh https://yourdomain.com

Every recognized crawler gets the same cached copy, so one pass with Googlebot’s user agent tells you what Bingbot, GPTBot and the rest are getting too.

What to do with the results#

• All rendered: check again after your next publish, since renders expire.
• Some pages on the summary: republish, then check again later. If the same pages keep serving the summary, confirm they load in a browser without logging in, and report them to Base44 support.
• Many pages on the summary, or record pages you care about: Base44 won’t render them on request, so the fix has to sit outside it. See the options guide.

The fixes that work#

• A pre-rendering service in front of your custom domain renders every page in your sitemap or list ahead of time and serves the finished HTML to every crawler you choose, including the ones Base44 never renders for. Encited has a documented Base44 setup and logs which crawler got which page. Prerender.io is the long-standing alternative.
• Exporting to a server-rendered framework removes the cache from the picture entirely. See pre-rendering vs server rendering.

What to do next#

1. Run the monitoring script on your site.
2. List your record page URLs in extra-urls.txt and run it again.
3. If the summary count is more than a handful, pick a fix from the options guide.