diff --git a/content/(publish)/wordpress-data-sources.mdx b/content/(publish)/wordpress-data-sources.mdx
index e4e7a511..22e05a89 100644
--- a/content/(publish)/wordpress-data-sources.mdx
+++ b/content/(publish)/wordpress-data-sources.mdx
@@ -122,4 +122,23 @@ With no argument it reads `WORDPRESS_URL`, falling back to the default entry in
 
 The URL has to serve the standard WordPress REST API at `/wp-json/` with pretty permalinks on. The content the build reads is whatever that API returns to an anonymous caller, so anything private stays private.
 
-A source is only read while a build runs. When published content changes, a new build is what picks it up. Open **Builds** and use **Build now** for an immediate refresh, or push to the production branch.
+## Rebuild when content changes
+
+A source is only read while a build runs. When published content changes, a new build is what picks it up. Let WordPress start it.
+
+<Steps>
+  <Step title="Install the plugin">
+    Download [`spacefast-wordpress.zip`](https://github.com/spacefast/wordpress/releases/latest/download/spacefast-wordpress.zip), install it in WordPress, and activate it. It needs WordPress 6.5 and PHP 8.1 or newer.
+  </Step>
+  <Step title="Connect it">
+    Open **Settings → Spacefast** and expand **Use WordPress as a CMS for a repository site**. Sign in to Spacefast, authorize one team, and pick the Space whose repository reads this site.
+  </Step>
+</Steps>
+
+Picking a Space acts right away. The plugin copies the site's title, description, and search visibility onto the Space, saves this site as the default source under the name `wordpress`, replacing any source already called that, and starts a production build. The **WordPress sync** switches that turn each of those off appear only after the first sync, so pick an existing Space only if you want it to match this site. Connecting this way also means you can skip [Add a source](#add-a-source).
+
+Any change to published content the REST API serves schedules a production build of the connected repository: publishing it, updating it, moving it out of published, or deleting it. So do media, taxonomy term, menu, and user changes. Saving a draft, or a revision WordPress keeps on its own, doesn't. Each change restarts a 60-second quiet window, so a batch of edits becomes one build. **Build now**, in WordPress or on the Space's **Builds** page, skips the wait.
+
+The plugin sends builds from WP-Cron, which only runs when the site gets a request. On a quiet headless site, a change can wait for the next visit. If `DISABLE_WP_CRON` is set, have the server request `wp-cron.php` on a schedule. **Tools → Site Health** flags a disabled or stuck delivery.
+
+The plugin asks for `teams:read`, `spaces:read`, `spaces:write`, `builds:trigger`, and `offline_access`, which keeps it signed in with a refresh token. A build it triggers always runs the Space's saved production branch, build settings, and live target. It can't pick its own.