Yoast keeps its own table describing every URL on your site. On a small blog you never see it. At forty thousand posts it is the thing that times out.
Everything below follows from Yoast maintaining a derived table that has to stay accurate as content changes.
Rebuilding after an upgrade or a bulk edit means writing a row for every post, term and author on the site. It runs as a resumable batch, so a large archive finishes rather than stopping at whatever the timeout allowed.
An XML sitemap index over tens of thousands of URLs is a real query every time a crawler asks. Generation is given room and the output cached, so Googlebot is not the thing making the site slow.
Changing a category across five thousand posts triggers five thousand indexable updates. Those are queued behind the front end rather than run inline while an editor waits.
Yoast's own tables are queried on every page render for the title, description and canonical. Those lookups get indexes rather than being left to scan.
A find-and-replace across meta descriptions is fast to run and slow to undo by hand. Daily backups make it a restore.
Nothing about Yoast is slow on a normal site. The problems all start at the point where a maintenance task can no longer complete inside one request.
Title, description and canonical come from the indexable table on every single render, so a slow lookup there is a slow lookup everywhere.
The plugin maintains a derived index of your site, and every row here is about keeping that index correct without blocking anything.
| Setting | What we do | Why |
|---|---|---|
| Indexable rebuilds | Resumable batches rather than one long run | A rebuild writes a row for every post, term and author, which on a large archive cannot complete inside any request timeout and silently stops part way. |
| Sitemap generation | Cached output with headroom for the first build | A sitemap index over tens of thousands of URLs is a genuine query, and crawlers request it often enough to become a load source of their own. |
| Bulk edit handling | Indexable updates queued off the request | Reassigning a category across thousands of posts triggers an update per post, and doing that inline leaves an editor watching a spinner for minutes. |
| Indexable table | Indexed for the per-render lookups | Title, description and canonical are read from that table on every page view, so an unindexed lookup there is a cost paid site-wide. |
| Orphaned indexables | Cleaned on a schedule, not on request | Deleted content leaves rows behind, and the cleanup task is large enough that it belongs on a schedule rather than in front of a visitor. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Move the archive across — migration is free, indexables included.