Nobody deletes it, because nobody can prove it is unused

Entirely, permanently, with no editions and no licence key. Every feature on this page is in the one version there is, and there is no licensing code in the plugin to remove later.

It cannot delete anything you have not selected and submitted. Beyond that: the default is Craft’s trash rather than a permanent delete, every element is re-proved immediately before it goes, a finding whose element has been edited since the census is refused, a census older than an hour cannot be acted on at all, a permanent delete has to be armed by typing the number of rows selected, and a database backup is taken first — and if the backup fails, the delete does not happen.

The honest answer is that any tool that deletes things can be wrong. Zoo’s design goal is that being wrong requires ignoring a screen that told you exactly what it had and had not checked.

Because it is wrong on every real site, and wrong in the direction that deletes things. An image dragged into a CKEditor field creates no relation row at all — it is an <img src> inside a JSON column. A reference tag is a string. A hard-coded id in a template is in no database anywhere. A variant held by a five-year-old Commerce order is a foreign key in somebody else’s table.

Those four are invisible to a relations-only query, and they are precisely the references whose loss you notice on a published page rather than in a log.

No. Zoo makes no outbound HTTP request anywhere — not at install, not during a census, not on a schedule. Everything it knows it works out from your own database, your own templates and your own schema.

Craft’s GC removes things Craft itself created and no longer needs — expired sessions, orphaned search rows, elements past softDeleteDuration. It has no opinion about your content. Zoo audits the content: the assets, entries, categories and tags nothing points at any more.

Nuke deletes what you name — a section, a volume, a group — with its drafts, revisions and relations, and sweeps the housekeeping tables on a schedule. Zoo finds what nobody named.

Nuke’s question is “delete all of this”. Zoo’s is “what is nobody using”. They compose, and neither needs the other.

No. An entry with its own URL counts as reachable by default, because a page is reachable whether or not anything on the site links to it — bookmarks, sitemaps, campaign emails and search results all point at pages without creating a row anywhere.

You can turn that off, and then you get a genuinely useful and completely different list: pages linked from nowhere on the site. That is not a list of things that are safe to delete, and Zoo says so on the setting.

Yes, without knowing they exist. Zoo reads information_schema for every column with a foreign key into elements and asks each one, so an element held by a line item, a submission or a navigation node keeps itself alive automatically.

The one thing it will not see is a plugin storing element ids in a column with no foreign key — a JSON blob of settings, say. Check the evidence on a few findings and keep-list anything held that way.

No. Zoo does nothing during a front-end request. There is no response filter, no Twig hook and no listener on saving. It runs when you press the button, and on a large site you queue it.

Yes, and reading the census is the safe half — zoo/census/report costs nothing. Give editors “view the census” and “mark things to keep” without “move findings to the trash” and they can see what the site is carrying, and correct Zoo when it is wrong, without being able to remove anything.

Candidates are per element, not per site row, and every site’s URI is given to the probes. An entry that is an orphan in one site and linked in another is not an orphan.

Its three tables are dropped and the project-config entry goes. Nothing Zoo found or deleted is affected — the deletions were Craft’s own, and anything in the trash is still in the trash.

Craft CMS 5.3+ and PHP 8.2+, with no runtime dependencies beyond Craft’s own and no build step.