Answers
Fixing an internal link to a page that no longer exists
A 404 on an internal link is not just a technical glitch. Decide first whether the target page moved, was deleted, or was replaced, then update, remove, or repoint the link and log the decision.
Before you touch an internal link that returns a 404, work out what happened to the page it points to. That single question decides the fix. If the page moved, update the link to the new URL. If it was deleted, remove the link or replace it with a relevant reference. If it was replaced by different content, repoint the link only when the new content meets the same need for the person who clicks. Skip that distinction and updating, redirecting, and removing all blur into the same move, and the problem comes back. Take an article that links to /guide/impostazioni-api and gets a 404. The guide now lives at /guide/configurazione-api, so the link is updated and the change is logged.
A 404, a decision, and a log line
Picture an article on API limits with a link to /guide/impostazioni-api. Open the URL and you get a 404. The first check is about content, not code: does the guide still exist under a different address? If it does, the page moved and the fix is to update the link. If the guide was deleted and no page covers the same topic, remove the link or swap it for a pointer to a page that is genuinely relevant. If the old address now hosts different content, repoint the link only when that content serves the reader of the sentence that contains it.
Filled in, the log line looks like this: source URL /articoli/limiti-api; link /guide/impostazioni-api; result 404; cause: page moved; decision: update; new destination /guide/configurazione-api; status: fixed. The same line with cause "deleted" and decision "remove" describes a different case with no ambiguity.
The checklist, filled in rather than just listed
RankAI offers this working checklist as a method, not a universal standard. Filled in on the case above, it reads: (1) Was the link opened and did it return a 404? Yes. (2) Does the destination exist at another URL? Yes, /guide/configurazione-api. (3) Does the destination content meet the same need as the sentence that links to it? Yes, it covers the same settings. (4) Is the decision to update rather than redirect? Yes, because the link is internal and should be fixed at the source. (5) Does the log line record source, old URL, result, cause, decision, and new destination? Yes. (6) Was the fixed link reopened to check? Yes, it returns 200. A checklist left half done, with only the "404 resolved" box ticked, does not tell a move from a deletion and does not help the next fix.
The point worth keeping: fixing an internal link is not an isolated maintenance task. It is an editorial decision that gets recorded. Updating, removing, and repointing are three different outcomes, and the log is what makes clear which one was chosen and why. If the log only says "fixed", the next person who hits the same URL cannot tell whether the page moved or was deleted.
What we do not promise
We cannot guarantee that one fix clears every broken link on the site, or that the log stays accurate without later checks. There is one check you can verify: after the edit, the internal link opens an existing page, and the log line states the cause, the decision, and the new destination. For the wider context on recurring questions, see the FAQ page.