SEO: find out why traffic went soft, and what to fix first
Our traffic has gone soft. Why, and what do I fix first?
One question before your marketing review. Quox reads your crawl, finds the pages nothing links to, shows what changed and proves the record was not tampered with, then picks the single change worth making first and tells you exactly what it is.
What you get: a diagnosis and a first fix, from your own crawl data, in under two minutes. In this run Quox found 201 indexable pages that nothing on the site links to, ruled out accidental noindex, traced which pages lost text and when, confirmed the change history was intact across 134 crawls, and named one page to fix first with exactly what to change. It edited nothing.
The setup
Section titled “The setup”Organic traffic has gone soft and you need to know why before Monday’s marketing review. You ask Quox for the whole job in one go: the crawl, the orphans, noindex, what changed, proof the record is untampered, and the one quick win to act on first. This is the exact question from the recorded run:
Our organic traffic has gone soft and I need to work out why before Monday's marketing review. Start with my latest SEO crawl: how many URLs did it cover and how many came back OK? Then find the pages nothing else on the site links to (orphans), and tell me if anything is set to noindex. Then show me what changed between the last two crawls, from the witnessed change log. Then verify the crawl history chain so I know that record hasn't been tampered with, and give me the verdict. Finally, from our quickest SEO wins, pick the one I should act on first and tell me exactly what to change. Don't edit the site yourself and don't run any shell commands.
▤ AOCL │ L1 identity complete · allowed · 1ms
▤ AOCL │ L3 policy gate complete · proceed · 9ms
◐ SEO │ summary ✔ SEO │ summary │ 30 crawls · 5.8s
◐ SEO │ urls ✔ SEO │ urls │ 707 crawl id, 201 total, 10 urls · 8.3s
◐ SEO │ urls ✔ SEO │ urls │ 707 crawl id, 0 total, 0 urls · 9.5s
◐ SEO │ changes ✔ SEO │ changes │ 20 changes, 7 rollup · 12.2s
⛓ AEE │ envelope opened · ops.tool · quoxseo_summary ok
⛓ AEE │ envelope opened · ops.tool · quoxseo_urls ok
⛓ AEE │ envelope opened · ops.tool · quoxseo_urls ok
⛓ AEE │ envelope opened · ops.tool · quoxseo_changes ok
◐ DELEGATE │ delegate_to_agent agent_id=seer ✔ DELEGATE │ delegate_to_agent agent_id=seer │ 6 tools used, 6 tool outcomes · 65.7s
⛓ AEE │ envelope opened · ops.tool · delegate_to_agent ok
⛓ AEE │ envelope opened · stream_success
Short version: the crawl is healthy and the record is intact. The soft traffic looks like an internal-linking and thin-content problem, not a technical failure. The 201 orphan pages and a thin /security page are the likeliest causes. 1. Latest crawl (id 707, 4 Nov, 05:41 UTC) • It covered 1,152 URLs and 1,148 came back OK. Four are errors. • Search Console data matched 696 URLs: 30,137 impressions and 159 clicks over 4 Aug to 2 Nov. • One page has no canonical and one has no meta description. • 252 pages were discovered by the crawl but are not in the sitemap. 2. Orphans and noindex • Orphans: 201 pages have no internal links pointing at them, and all 201 are indexable. ◦ The ten I pulled are mostly CLI docs pages ( /cli/ , /cli/commands/ , /cli/docs/commands/... ) and one blog post. ◦ Several of these CLI pages get no search impressions at all. ◦ Only a first page of ten was returned. The other 191 aren't broken down here. • Noindex: nothing is set to noindex. That rules out accidental deindexing as a cause. 3. Changes between the last two crawls (694 to 707, from the witnessed log) • Four URLs were added: two /evidence/runs/... pages and two CLI guides ( check-quox-health , approvals/check-the-chain ). • No titles, canonicals or noindex values changed between those two crawls. • Slightly earlier, on 3 Nov, the /blog/owasp-agentic-top-10 post was added. Meta descriptions changed on /plugins/system-maintenance , /plugins/proxmox and /blog/all , and word counts shifted. • On 30 Oct, /solutions/quoxterminal was removed. The log classes that one as a regression, so it's worth checking whether it needs a redirect. • On 30 Oct and 31 Oct, several pages lost a lot of text. /docs/plugins/decision-evidence dropped from 1,536 to 868 words and its title was rewritten. /solutions/proofloop fell from 1,148 to 851 and /solutions/gripe from 962 to 709. • The decision-evidence and proofloop pages are the ones I'd look at first if rankings slipped around then. 4. Chain verification: intact • Our SEO specialist reports all 134 crawls pass the statement, content and root hash checks, with 0 failures. Nothing in that record has been tampered with. • One discrepancy: the verifier names the latest crawl as id 713, while the summary I read shows 707. The quick-wins ranking was computed from 707, so it may be a few crawls behind. I'd treat the chain verdict as sound and the ranking as slightly stale. 5. Act on this first: /security • The specialist ranked it first because it is flagged twice, as close to page one and as a thin page with traffic. It sits at position 6.7 with 1,116 impressions and only 5 clicks. • The change: expand its main content from about 104 words to a full, answer-first page of roughly 600 to 1,000 words around the head term "ai security you can verify". The 104 figure is measured. The target length and the head term are the specialist's estimate and come from a memory note dated 20 Sep, not from query data. • Check before anyone writes copy. In the orphan list, the blog post /blog/we-asked-a-rival-ai-to-tear-this-site-apart has the Security title, a canonical pointing at /security , and also 104 words. The 104-word figure may belong to that blog page and not to /security itself. Please open /security and confirm its real length first. • If /security is already long, the next candidate is /solutions/qortex . It has the highest score (position 7.2, 3,820 impressions, 10 clicks). The specialist could only suggest more internal links and depth for it, with no specific edit. • This is advice only. I haven't touched the site. For Monday's review • Lead with the 201 orphans, which are an internal-linking gap on the CLI docs. • Follow with the /security fix once its length is confirmed. • Mention the removed /solutions/quoxterminal page and the pages that lost text on 30 and 31 Oct.
110.1s · 5 tools · 0 approvals
quox.✔ Machine verified against the CLI on 4 Nov 2026 · test report mw2prx
The work
Section titled “The work”The whole job took 110 seconds and five tool calls by Quox, one of which handed work to a specialist. Nothing on the site was changed, so nothing needed your approval.
- Quox takes the request. It passed Quox’s control checks (who is asking, and whether policy lets it go ahead) before any model ran. Out of 318 tools, 16 were offered for the job.
- It reads the site itself, in parallel. Within about a second Quox started four reads at once:
quoxseo_summaryfor the crawl history (30 crawls),quoxseo_urlstwice on the latest crawl (once for orphans, which returned 201, once for noindex, which returned none), andquoxseo_changesfor the witnessed change log (20 changes, in 7 groups). - It hands off to Quox’s SEO specialist. For the two jobs that need a specialist, Quox handed off to Quox’s SEO specialist agent rather than doing them itself. The specialist ran its own checks, six tools in all: it re-verified the crawl history chain with
quoxseo_verify, and ranked the quick wins withquoxseo_opportunities. It reported back after 66 seconds. - It puts the two halves together. Quox combined its own reads with the specialist’s verdict and ranking, and flagged where they did not line up.
- It advises, and stops there. The answer ends with what to change and what to check first, and says plainly that it has not touched the site. Each tool call, the hand-off included, was written to the audit record as an evidence envelope.
The result
Section titled “The result”- The crawl: the latest crawl (4 November) covered 1,152 URLs and 1,148 came back OK, with 4 errors. Search Console matched 696 URLs: 30,137 impressions and 159 clicks over 4 August to 2 November. 252 crawled pages are missing from the sitemap.
- Orphans: 201 pages have no internal links pointing at them, and all 201 are indexable. The first ten are mostly CLI docs pages and one blog post, and several get no search impressions at all.
- Noindex: nothing is set to noindex, so accidental deindexing is ruled out.
- What changed: four URLs were added between the last two crawls, with no title, canonical or noindex changes. Earlier,
/solutions/quoxterminalwas removed on 30 October, which the log classes as a regression worth a redirect check. On 30 and 31 October several pages lost a lot of text:/docs/plugins/decision-evidencedropped from 1,536 to 868 words and had its title rewritten,/solutions/proofloopfell from 1,148 to 851 and/solutions/gripefrom 962 to 709. - Is the record intact: yes. The specialist reports all 134 crawls pass the statement, content and root hash checks, with 0 failures.
- What Quox flagged about the answer itself: the verifier names the latest crawl as 713 while the summary shows 707, so the quick-wins ranking may be a few crawls behind. Quox called the chain verdict sound and the ranking slightly stale.
- Act on this first: the /security page. It sits at position 6.7 with 1,116 impressions and only 5 clicks, and is flagged both as close to page one and as a thin page with traffic. The change: expand its main content from about 104 words to a full, answer-first page of roughly 600 to 1,000 words around the head term “ai security you can verify”. The 104 is measured; the target length and the head term are the specialist’s estimate, from a note, not from query data.
- Check before anyone writes: a blog post in the orphan list carries the Security title, points its canonical at the /security page and is also 104 words, so the 104 may belong to that post. Quox asked you to confirm the real length of the /security page first. If it is already long, the next candidate is
/solutions/qortex(position 7.2, 3,820 impressions, 10 clicks).
What that got you: an agenda for Monday, in order. Lead with the internal-linking gap, then the /security page fix once its length is confirmed, then the removed page and the pages that lost text, all from records you can re-check.
Do it yourself
Section titled “Do it yourself”The same reads from the CLI, all read-only:
quox seo statusquox seo urlsquox seo changesquox seo verifyquox seo status gives the latest crawl, quox seo urls the warehouse rows behind it, quox seo changes the witnessed change log, and quox seo verify re-checks the chain server-side. To go deeper on the verification step, see Prove your SEO history was not tampered with.
How it is checked
Section titled “How it is checked”The proof engine asked the question through chat and judged each step against the SEO records:
- the answer carried the crawled URL count from the latest crawl;
- the answer named at least one real orphan path;
- the answer reported what changed between the last two crawls, from the witnessed change log;
- the chain was verified and the answer gave its real verdict;
- the answer picked a quick win to act on first;
- no shell command ran, and the answer never claimed to have fixed, updated or changed a page.
All checks passed, in order.
Receipts
Section titled “Receipts”The run shown above is public at ev_mw2prx7v_361b02, recorded on 4 November 2026. The same Journey passed again on 5 November 2026, at ev_mw2tnux7_06c7d9. The receipts are the evidence, not this page.
The evidence bundle for the published run (ev_mw2tnux7_06c7d9) is yours to download and check: every step, check and tool with its verdict, the CLI record each step was judged against where it read one (host names replaced by their role). The transcript above is from the earlier run, so it is not part of this bundle. Save it with the verifier, index.json and index.receipt.json, then run node verify-journey-bundle.mjs ev_mw2tnux7_06c7d9.json. It passes only if the bundle is the copy we published and witnessed, unchanged.
The proof engine rates this Journey VERIFIED: it passed on two UTC days, 4 and 5 November 2026.
Quox-verified, not independently audited: the run was checked by Quox’s own proof engine against the running system, and the evidence id is published so you can recompute it. It is not a third-party audit.