# Raise a WordPress site's PageSpeed score with ChatGPT dots

> Raising a WordPress PageSpeed score with ChatGPT dots means letting an always-on dot watch your stored scores through xSpeed Hub, then reviewing the optimization preview it brings you and approving the pass yourself.

Page: https://xspeedcache.com/agent/chatgpt-dots/optimize-site/
Last updated: October 2026

A dot is good at noticing. You ask it once for a Friday check of every site's stored PageSpeed history, and it reads get_score_history through the xspeedhub app it shares with your ChatGPT chats. get_score_history starts nothing and spends no speed-test allowance, so the check is cheap to repeat. This Friday the report says the mobile score on shop fell nine points since last week, and you reply in the same conversation: preview what xSpeed would change.

The dot calls optimize_site with dry_run on. The preview lists the settings xSpeed would turn on at the standard level and changes nothing on the site. You read it and say yes. The real pass then measures the site, applies each setting one at a time, checks that the page still renders after each, and undoes anything that breaks it, which takes up to about two minutes. The result comes back in the conversation as three lists: applied, undone with the reason, and unfixable, which names what caching cannot reach, such as oversized images or a heavy embed.

After a run that changed something, the Hub hands the dot verify_urls and tells it to check that the pages render and the console is clean, or to tell you which pages to check. Ask the dot for the list and open those pages yourself with the browser console visible. The plugin checks HTML only and cannot run JavaScript, so a page can pass its checks and still break in a browser. Keep the unfixable list too: it is the to-do for whoever edits the theme or the content.

## Set up ChatGPT dots once

### 1. Put your sites in xSpeed Hub

Sign in at app.xspeedcache.com with Google or email; the Hub is free and has no site cap. Then connect each WordPress site from its own dashboard: click Connect Hub in the xSpeed Cache top bar, then Connect via xSpeed Hub. Each site needs the free xSpeed Cache plugin.

### 2. Create the xspeedhub app in ChatGPT

In ChatGPT on the web, turn on Developer mode under Settings, Security and login. Open Plugins, select the plus button and create a developer-mode app named xspeedhub with this URL and OAuth. Click Scan Tools, approve access on the xSpeed Hub page that opens, then click Create. If ChatGPT already has the app, skip this step. On a Business workspace only an admin or owner can turn on developer mode and publish the app.

```
https://app.xspeedcache.com/xspeed/mcp
```

### 3. Check that your dot can see it

OpenAI says plugin permissions are shared across dots and ChatGPT. Open your dot's profile, then Customize and Plugins, and check that xspeedhub is there. That screen uses the shared ChatGPT settings, and OpenAI notes the apps available to a dot may differ, so confirm it before you hand over a task.

```
Dot profile  >  Customize  >  Plugins  >  xspeedhub
```

### 4. Add a custom rule for site changes

Under Customize, Custom rules, describe the action and pick a behavior: Take action without asking, Take action if pre-approved, Ask before taking action, or Hand off to you. Add a rule that covers purging a cache, changing settings or running a speed test through xSpeed Hub, and choose Ask before taking action.

```
Customize  >  Custom rules  >  xSpeed Hub changes: Ask before taking action
```

Full setup: https://xspeedcache.com/agent/chatgpt-dots/

### Before you send a prompt that changes something

Reads change nothing on your sites, though contact_support emails xSpeed support. Writes run once your connection allows them, so your client's approval prompt and a read-only connection (the token's Read-only everywhere switch, or a Viewer sign-in) are the gates that matter. In a ChatGPT chat, write actions from a developer-mode app need your confirmation by default, and ChatGPT treats a tool without a read-only annotation as a write. xSpeed Hub's tools carry no such annotation. A dot comes with OpenAI's defaults for which actions need approval, and Custom rules let you set, for an action you describe, Take action without asking, Take action if pre-approved, Ask before taking action or Hand off to you. xSpeed Hub has no confirmation step of its own, so a rule that lets your dot act without asking runs a purge or a settings change as soon as your connection allows writes. Keep xSpeed Hub changes on Ask before taking action. For read-only access, sign in as a Viewer member of the workspace; the connection token's Read-only everywhere switch does not apply, because the app signs in with OAuth.

## Prompts

- Every Friday, use xSpeed Hub to read the stored PageSpeed history for every site and tell me which mobile scores dropped. Report only.
- With xSpeed Hub, preview an optimization for shop at the standard level and wait for my yes before applying it.
- Using xSpeed Hub, list the verify URLs from the last run on shop and what a broken page would look like.

## Example session

```
You: Use xSpeed Hub to look at why shop dropped in this week's score check, and preview a fix. Do not apply anything yet.
  → get_score_history(site: shop) [read-only]: mobile score 71, down 9 points since last week
  → optimize_site(site: shop, aggressiveness: standard, dry_run: true) [dry run]: plan: 3 settings to apply (defer JS, lazy-load images, browser cache), nothing changed
Agent: Mobile fell from 80 to 71 this week. A standard pass would defer scripts, lazy-load images and set browser caching. Nothing has changed. Apply it to shop?
You: Yes, apply it.
  → optimize_site(site: shop, aggressiveness: standard) [changes site]: applied 2, undone 1 (defer JS broke the mini cart), unfixable: 2 oversized banner images
Agent: Two settings are on, and script deferral was undone because it broke the mini cart. The banner images are what caching cannot shrink. Open the home page and a product page with the console visible and tell me if anything logs an error.
```

## How it works

1. **See where the site stands**: The agent reads get_score_history for the last stored scores and list_modules for which modules exist on that site and what state they are in. Neither changes anything.
2. **Preview with dry_run**: optimize_site with dry_run: true returns the plan: each change and its tier, what would be skipped (already on, or needing a higher aggressiveness) and what it cannot fix. Nothing is applied. The tool description tells the agent to prefer this before the first real run on a site you have not optimized before.
3. **Apply it**: optimize_site without dry_run applies the plan. aggressiveness is safe (removals and server-side changes only), standard (the default) or aggressive, which includes settings known to break some themes and should be opted into deliberately. A run can take up to about 2 minutes per site.
4. **Look at the site afterwards**: When changes were applied, the result carries verify_urls and a note. The site checks its own HTML and reverts anything that breaks it, but it cannot run JavaScript, so verified: true does not prove the page works in a browser. The Hub tells the agent to open those URLs and check the page renders and the console is clean, or to tell you which URLs to check.
5. **Reach for a number only if you named one**: target_score (1 to 100, Pro sites only) turns one pass into repeated rounds toward that score, up to max_rounds, with 3 as the most per site. Each round is a real PageSpeed measurement and up to about 2 minutes. The result says why it stopped, and diminishing returns means what is left is outside what caching can reach.
6. **Critical CSS on Pro sites**: generate_critical_css generates above-the-fold CSS so the first screen can paint without waiting for the full stylesheets. It needs the Pro Critical CSS module on that site, and the site answers with an unknown-tool error without it. Pages are rebuilt with it on their next build, so the agent purges the cache afterwards.

## Reference

| | |
| --- | --- |
| Main tool | optimize_site (write): measure, apply one setting at a time, verify, undo what breaks, re-measure |
| Preview | dry_run: true returns the plan and changes nothing |
| aggressiveness | safe, standard (default) or aggressive |
| Every site at once | site: "all" or a list of handles, one result per site, sites run one after another; the Hub's confirm-once instruction does not name optimize_site, so your client's prompt is the gate |
| Time | Up to about 2 minutes per site |
| target_score | 1 to 100; needs Pro on the site; without it the site runs one pass and says so |
| max_rounds | Up to 3 per site; only sent along with target_score; 12 rounds in total per call |
| Wide fan-out with a target | Each site gets fewer rounds, and the result carries a note saying so |
| Result fields | applied, skipped, reverted, unfixable, score, verified, rounds; verify_urls after a run that changed something |
| Already tuned site | Returns "everything is already on" plus what it cannot fix; that is an answer, not a failure |
| Critical CSS | generate_critical_css (write), Pro Critical CSS module required; purge_cache afterwards |
| Read-only connection | optimize_site and generate_critical_css are refused; dry_run is still a write call, so it is refused too. Applies to the connection token with Read-only everywhere on and to a Viewer sign-in, not to other OAuth sign-ins |

## Rules

- Run dry_run first. optimize_site changes live site settings as soon as your connection allows writes. The tool description tells the agent to preview first on a site that has not been optimized, but that is guidance, so your client's approval prompt and a read-only connection (the connection token with Read-only everywhere on, or a Viewer sign-in) are the real gates.
- Keep aggressive for a deliberate choice. It includes settings known to break some themes, and the agent should say so before using it.
- After a run that changed something, open the pages in verify_urls. The HTML checks cannot run JavaScript, so a page can pass them and still be broken in a browser. Do not call a run safe because verified is true.
- Relay the unfixable list. When a site is already tuned, the honest answer is that caching is done and the rest is page weight, hotlinked images or DOM size. The agent should not retry the tool or claim a gain it did not make.
- Only ask for target_score when you want the site driven to a number. Each round costs a real PageSpeed measurement, and a plain "make it faster" is one pass.

## Good to know with ChatGPT dots

Keep the scheduled part of this job to reads. A dot's scheduled task runs with nobody watching, and if a Custom rule lets it take xSpeed Hub actions without asking, a scheduled run could call optimize_site and change a live site unattended, because xSpeed Hub has no confirmation step of its own. Write a Custom rule that sets optimizing or changing site settings through xSpeed Hub to Ask before taking action, and word the Friday check as report only. The preview and the real pass are the same tool, so a rule loose enough to let the dry run through on its own also lets the real pass through. A Viewer sign-in refuses both, because the Hub counts optimize_site as a write even with dry_run on. To stop every scheduled check at once, pause the dot from the menu in its profile.

## More prompts for this job

They work in any client connected to xSpeed Hub.

- Ask xSpeed Hub to preview what optimize_site would change on shop with a safe pass. Do not apply anything.
- Use xSpeed Hub to optimize the blog site with the standard pass, then give me the pages to check by hand.
- With xSpeed Hub, get docs to a mobile PageSpeed score of 90 if you can, and tell me why it stopped if it does not get there.
- Use xSpeed Hub to show me what optimize_site would do on every site, as a dry run, and list which sites have the most left to change.
- Use xSpeed Hub to generate critical CSS for shop, then purge the cache so the pages are rebuilt with it.
- With xSpeed Hub, optimize shop, then compare the new PageSpeed score with the last stored one.
- Using xSpeed Hub, what could optimize_site not fix on the shop site?

## Frequently asked questions

### Can my ChatGPT dot optimize a site on a schedule?

It can if your rules allow it, but it should not. A scheduled run has nobody to read the preview or open the pages afterward. Schedule a report-only read of the stored scores, and run the optimization in the conversation when you are there to approve it.

### Why did my dot not manage to preview the optimization?

If you signed in as a Viewer member, the Hub refuses optimize_site entirely, including the dry run, because it counts the tool as a write. Sign in with a member account that can write, and keep a Custom rule on Ask before taking action for the real pass.

### What does optimize_site actually do?

It measures the site, applies the recommended xSpeed settings one at a time, checks that the page still renders after each change, and undoes any change that breaks it. It then reports what was applied, skipped and reverted, and what it could not fix. It reaches caching and asset delivery only.

### Should I run a dry run first?

Yes, especially on a site you have not optimized before. dry_run: true returns the plan, what would be skipped and what cannot be fixed, and changes nothing. The tool description tells the agent to prefer it, but nothing forces it, so say so in your prompt if you want a preview.

### Can I tell it to get my site to a score of 90?

Yes, with target_score, on a site that has xSpeed Pro. It repeats measure, apply and re-measure for up to 3 rounds per site and stops early when rounds stop helping, saying why. On a Free site the score target is ignored and you get a single pass with a note that no iterative tuner is installed.

### Why did it say everything is already on?

That is a real answer. The settings it can apply were already enabled, so there was nothing to change. The result also lists what it could not fix, such as page weight, images hosted on another domain or DOM size, and those need changes outside a caching plugin.

### Does the agent check that my pages still work?

The site checks its own HTML after each change and reverts anything that breaks it, but it cannot run JavaScript. After a run that changed something, the Hub tells the agent to open the returned verify_urls and check the page renders and the console is clean, or to give you the URLs to check yourself.

### Does generate_critical_css work on a Free site?

No. It needs the Pro Critical CSS module on that site, and without it the site answers with an unknown-tool error. On a Pro site, purge the cache afterwards, because pages already cached were built without the critical CSS.

## Raise the PageSpeed score with other agents

[Claude Code](https://xspeedcache.com/agent/claude-code/optimize-site/) · [Claude](https://xspeedcache.com/agent/claude/optimize-site/) · [Claude Cowork](https://xspeedcache.com/agent/claude-cowork/optimize-site/) · [ChatGPT](https://xspeedcache.com/agent/chatgpt/optimize-site/) · [Codex](https://xspeedcache.com/agent/codex/optimize-site/) · [Cursor](https://xspeedcache.com/agent/cursor/optimize-site/) · [GitHub Copilot in VS Code](https://xspeedcache.com/agent/github-copilot/optimize-site/) · [Windsurf](https://xspeedcache.com/agent/windsurf/optimize-site/) · [Gemini CLI](https://xspeedcache.com/agent/gemini-cli/optimize-site/) · [Antigravity](https://xspeedcache.com/agent/antigravity/optimize-site/) · [Zed](https://xspeedcache.com/agent/zed/optimize-site/) · [Kiro](https://xspeedcache.com/agent/kiro/optimize-site/) · [OpenCode](https://xspeedcache.com/agent/opencode/optimize-site/) · [OpenClaw](https://xspeedcache.com/agent/openclaw/optimize-site/) · [Hermes Agent](https://xspeedcache.com/agent/hermes-agent/optimize-site/) · [Grok Build](https://xspeedcache.com/agent/grok-build/optimize-site/) · [Grok](https://xspeedcache.com/agent/grok/optimize-site/) · [Grok Bot](https://xspeedcache.com/agent/grok-bot/optimize-site/) · [Muse](https://xspeedcache.com/agent/muse/optimize-site/) · [Manus](https://xspeedcache.com/agent/manus/optimize-site/) · [Kimi Code](https://xspeedcache.com/agent/kimi/optimize-site/) · [Paperclip](https://xspeedcache.com/agent/paperclip/optimize-site/) · [NanoClaw](https://xspeedcache.com/agent/nanoclaw/optimize-site/)

## More with ChatGPT dots

- [Purge the WordPress cache with ChatGPT dots](https://xspeedcache.com/agent/chatgpt-dots/purge-cache/)
- [Find out why WordPress pages are not cached with ChatGPT dots](https://xspeedcache.com/agent/chatgpt-dots/troubleshoot-cache/)
- [Scan a website for speed problems with ChatGPT dots](https://xspeedcache.com/agent/chatgpt-dots/speed-scan/)
- [Run and track PageSpeed tests with ChatGPT dots](https://xspeedcache.com/agent/chatgpt-dots/pagespeed-tests/)
- [Tune WordPress cache settings with ChatGPT dots](https://xspeedcache.com/agent/chatgpt-dots/cache-settings/)
- [Warm the WordPress cache with ChatGPT dots](https://xspeedcache.com/agent/chatgpt-dots/preload-cache/)
- [Set up the Redis object cache with ChatGPT dots](https://xspeedcache.com/agent/chatgpt-dots/object-cache/)
- [Manage Cloudflare caching with ChatGPT dots](https://xspeedcache.com/agent/chatgpt-dots/cloudflare/)
- [Manage every WordPress site at once with ChatGPT dots](https://xspeedcache.com/agent/chatgpt-dots/fleet/)

## Documentation

- How to generate Critical CSS: https://xspeedcache.com/docs/critical-css/
- Performance recommendations: https://xspeedcache.com/docs/performance-recommendations/
- How to run a speed test: https://xspeedcache.com/docs/external-score/
- Free vs Pro: what is included: https://xspeedcache.com/docs/free-vs-pro/