Lesson 8 · 20 min
Agents fail in predictable ways: they claim without checking, add up wrong, break what was working, use the key they found. Each real failure in INEMA's SEO project became one line in the failure log and one rule in AGENTS.md. This lesson shows the failures, the smallest fix for each, and closes the course with your plan.
Start the lesson
Goal: recognize the real failures of agents in SEO and apply the rules: only authorized APIs, secrets outside the repo, check before claiming.
Tap each block.
One line per failure: date, what broke, smallest fix, prompt or infra.
Tap each step. All of them are in the project's FALHAS.md.
A plan made by an agent said the site had no Search Console: it looked only in the code. The fix was to check the DNS TXT record before claiming it was missing.
The same day, the agent suggested installing a package for a different processor than the machine's. Rule: check the architecture before suggesting a package.
The weekly export added up the brand's impressions by the query + page combination, and the part became larger than the total. The fix was to add up by query only.
Another script counted as enriched every listing page present in the file, without reading the field that said whether it was. In both cases: an impossible number that a simple check would catch.
A visual change left the course index as "search only," and the 310 listing pages lost their only internal link in the server HTML. The fix was a collapsed index, with no visual change.
Regenerating an area of the site with an old generator would undo a canonical fix made by hand. The rule was written down: don't regenerate over it.
The first IndexNow submission with a newly published key came back 403; resubmitting a few minutes later fixed it (infra). The IndexNow key is public by design; the Bing Webmaster one is a secret.
The method's rule: paid API only with explicit authorization for that purpose, and notifying search engines only with URLs that return 200.
Copy FALHAS.md to the project root. Run the scan before every push.
# FALHAS | date | what broke | smallest fix | prompt \| infra | |---|---|---|---| | 2026-10-02 | IndexNow returned 403 SiteVerificationNotCompleted on the 1st submission (key just published) | resubmit after ~4 min | infra | | 2026-10-02 | /cursos/ became "search only" and the listing pages lost the only internal link rendered on the server | collapsed index (details) with plain links below the search | prompt | | 2026-09-24 | weekly export summed branded impressions by query+page (part larger than the total) | sums by the query dimension only | prompt | | 2026-09-23 | plan said "no Search Console" (only looked in the code) | check DNS TXT before claiming it's absent | prompt |
echo ".env" >> .gitignore git check-ignore -v .env # confirms that .env is ignored git grep -niIE "(api[_-]?key|apikey|secret|token)[[:space:]]*[:=]" # looks for a key value in what goes to the repo
$ git check-ignore -v .env .gitignore:1:.env .env $ git grep -niIE "(api[_-]?key|apikey|secret|token)[[:space:]]*[:=]" avisar.sh:1:curl "https://ssl.bing.com/webmaster/api.svc/json/SubmitUrlBatch?apikey=$BING_API_KEY" rodar.sh:2:export BING_API_KEY=9f3a1c0000000000000000000000beef
Test repository built for the lesson; the key is fake.
$BING_API_KEY, a reference to the variable. That's correct.You're the one answering the agent. The conversation is fiction; the rules come from the inemaSEO method.
Choose your answer. The feedback appears right after, and the conversation continues based on your choice.
In the SEO project from the previous lessons.
Create FALHAS.md at the root and record 3 failures you've already seen an agent make (in this course or before), each with the smallest fix and whether it was prompt or infra. Bring the rule from each one into AGENTS.md.
Done when: FALHAS.md has 3 lines in the format date | what broke | smallest fix | prompt or infra, and AGENTS.md gained at least one new rule coming from them.
Run the scan on the project and on every repository where an agent has worked. Check the .gitignore.
Done when: git check-ignore -v .env shows the .gitignore rule, and the scan finds no key value written out (only references to variables).
The explanation appears after your answer.
Question 1 of 4
The agent says the site "has no Search Console" because it found nothing in the code. What should you ask for?skill
Question 2 of 4
The brand total came out larger than the total impressions. What's the smallest fix?
Question 3 of 4
Which of these keys can safely stay visible on the site?
Question 4 of 4
The scan found a key's value written in a script that was already committed. What should you do?
Choose an option. The explanation appears after your attempt.
Four steps and the exercises for each one. Tap an exercise to see its "done when".
line, gates, and AGENTS.md
2 exercises
AGENTS.md at the root and one pass of the machine on paper.
See the lessonauditor and extraction (lessons 2 and 3)
2 exercises
A list of findings with evidence and an extraction with a check.
See the lessonbatch and goal (lessons 4 and 5)
2 exercises
A batch with dry-run and marker; a page through the loop and the gate.
See the lessonreport, tools, and rules (lessons 6 to 8)
2 exercises
A weekly report with approved proposals and a living FALHAS.md.
See the lessonThe groundwork: without written gates, automating SEO is just publishing wrong things faster.
Requires AGENTS.md. Agents that only read come before the ones that write; the map shows lesson 2, the plan below lists them all.
Requires the previous steps. Write to the site only with a dry-run, a level 3 goal, and a gate before the push.
The observer closes out the whole machine every week, and every new failure becomes a rule.
Machine, read, write, and routine. Only move up a step when the "done when" of the previous one is true.
After this course comes course 6: the method as a service for clients.
Pick the start date and how much time you have per week.