Chapter 14 of 14

The Rhythm

The work is done. This chapter is about the three things that keep it done: showing it to somebody who does not use the tool, comparing your score against Google's own numbers, and a monthly rhythm short enough that you will actually keep it.

The problem

Thirteen chapters of improvement are invisible to everyone but you. The person who signs off the work sees a traffic graph that moves slowly and a tool they will never open. Work that cannot be shown is work that gets cut, and the monitor gets turned off the month after.

Reports somebody else can read

Export a report as PDF: the score, the categories, the findings with the values they found, dated. Add your agency name in Settings and it appears on the export.

The useful move is not sending a report. It is sending two: the first run from chapter 3 and the one from today. 61 to 89 with the individual findings resolved between them is an argument that survives a budget meeting. A single report is a document; a pair is evidence.

Measured reality

Connect Google Search Console and Sjá shows real impressions, clicks, CTR and average position beside its own analysis — measured facts next to predicted eligibility.

You connect your own OAuth client: create a Desktop app client in Google Cloud Console, enable the Search Console API, paste the id and secret into Settings, and approve the consent screen. The reason is stated plainly in the docs and worth repeating — Search Console has no API-key path, every call needs a user-consented token, and shipping our own client would put a non-confidential secret inside the binary. Since the Cloud project is yours, the “unverified app” screen is expected; approve it for your own account. The client secret goes to the Keychain, never the database.

Once connected, the two columns start a conversation:

  • High score, no impressions — the page is eligible and nobody is asking. This is a topic problem, not an optimisation problem. No amount of chapter 5 will fix it.
  • Impressions, no clicks — you rank and the result is unappealing. Title and description, which is chapter 3 with a different motive.
  • Clicks rising, score flat — something outside the page is working. Worth knowing before you credit the wrong change.

Sjá from your own assistant

Sjá exposes an MCP server, so the assistant you already code with can run an analysis, read the report and check a crawl — without you switching windows. The natural use is at the moment of writing: “analyse the staging URL for this page and tell me whether the first paragraph is quotable”, asked from inside the editor where the paragraph is.

That is where the loop finally closes. The measurement happens while the text is still soft, rather than after it is published and someone remembers to check.

The rhythm

Optimisation is not a project with an end. It is a small standing habit, and the only version of it that survives is one short enough to keep.

  • Every deploy — the gate (ch. 13). No human involved.
  • Daily — monitors on the pages that earn (ch. 12). No human involved unless an alert fires.
  • Monthly, thirty minutes — re-crawl twenty-five pages, read the issue inventory, run the citation probe on your two most important questions, glance at the crawler log for a cliff.
  • Quarterly, two hours — re-read What the model sees on your top three pages. Copy drifts. The paragraph you made quotable in chapter 4 has been edited four times by people who never read this course.

What finished means

Freddy's site: 61 to 89. Cited by three of four engines where it was cited by one. OAI-SearchBot fetching forty pages a week where it was getting 403s. Eleven internal links that were not there. An llms.txt, a publisher entity, dates that agree.

None of that is a promise of traffic, and this course has been careful not to make one. What it is: Freddy is now eligible everywhere he was disqualified, and every one of those disqualifications was invisible in March. That is the whole discipline — not tricking a ranking, but removing every reason a system had to pass you over, and then keeping them removed.

The keeping is the part that is actually hard, and it is why the last three chapters exist.

What you learned

  • Send two reports, not one. A pair is evidence; a single one is a document.
  • Search Console is measured reality beside predicted eligibility, and you connect your own OAuth client for a stated reason.
  • High score with no impressions is a topic problem, and no amount of optimisation fixes it.
  • MCP closes the loop by measuring while the text is still soft.
  • Keep a rhythm short enough to survive: gate every deploy, monitors daily, thirty minutes monthly, two hours quarterly.
  • Finished means eligible, not ranked. Remove every reason to be passed over, then keep them removed.
That is the course. The reference for everything here is the features guide; the honest limits are collected in security. If you have not taken it, Freddy the Notetaker is the course where the app itself gets built.