Why Your SEO Fixes Never Ship

The audit is almost never the problem. Most are accurate, a good number are thorough...and a year later the site looks the way it did when the deck arrived.

Nothing was rejected and nobody argued with a single finding. The items went into a backlog, sat underneath work with a release date attached, and aged out while the site shipped other things.

That is a delivery failure...what fixes it is a sorting pass and a rewrite, and most of that happens before any code changes.

Nobody Rejected The List

Rejection would have been better, because a rejected item at least produces an argument ending in a decision. Agreement produces nothing at all...saying yes costs a marketing lead four seconds, and putting the item into a release costs a developer a week already promised elsewhere.

Volume is the other half, because buyers read length as thoroughness and auditors get paid to show it. So the deliverable keeps growing until it covers everything the crawler noticed...doing none of it is a defensible response to a document that size.

Severity Without An Effort Column

High, medium and low describe the size of the problem...they say nothing about the size of the job, which is the number a person building a schedule needs.

A high severity item can be one line in a shared template, and a low severity item can mean rewriting a few thousand pages by hand. With no hours next to either one they look identical on paper, and the cheap fix stays buried.

Findings Are Not Work Orders

"Title tags are not optimized" is a finding. It is accurate and nobody can act on it...there is no file to open, no text to paste, no way to tell whether it is done.

A developer who reads that has to book a meeting to find out what it means...and the meeting is where it stops.

Five Owners, Not One Queue

A single ranked list hides the thing that matters more than the rank...the work is not one kind of work, and it has to be split by who can make the change.

• Content: Anything an editor can change in the CMS this afternoon.
• Template: Code that changes many pages at once on one deploy.
• Infrastructure: Redirects, headers, robots rules and anything living on the server.
• Vendor: Work owned by a platform, a host or an outside agency.
• Blocked: Items waiting on budget, a legal review or a decision.

On a small site those five owners may be two people and a plugin vendor...the split still pays. Some of what looked like developer work turns out to be content an editor could have changed months ago, stacked behind template items for no reason except document order.

Scoring Borrowed From Product Teams

None of this scoring is new. Product teams have ranked backlogs on reach, impact, confidence and effort for years, and this is that idea with one column added.

• Reach: How many pages a single change touches when it ships.
• Demand: Whether real buyers land on those pages, by data or judgement.
• Effort: Hours quoted by the person who will do the work.
• Risk: What breaks if the change is wrong, and how fast.
• Proof: Whether anyone can tell it worked without starting an argument.

Proof is the column worth adding, because it decides whether you get to do this again next quarter. Effort has to come from whoever will type the change...and if that person will not quote it, size it yourself in three rough buckets and let the first shipped ticket correct you.

A Cap On The Quarter

Twelve is a reasonable ceiling for a small team, and the number matters less than the fact that one exists. So everything under the line goes into a separate file that is explicitly not the backlog...a queue stuffed with work nobody intends to reach informs nothing.

Six Fields, Then It Ships

There are six fields, and the item is ready when all six are filled in.

1. Location: The exact URL, template file or CMS field that changes.
2. Current State: What sits there now, quoted rather than described.
3. Target State: The replacement text or markup, written out in full and ready to paste, with nothing left for the reader to invent.
4. Acceptance Test: The check a person runs to confirm it shipped.
5. Effort: Hours from the implementer, plus review and deploy time.
6. Rollback: How to put it back, and who makes that call.

Target state is the field I would keep if only one of the six survived. Describing a change makes the developer invent the wording, and inventing means asking...supplying the wording means the ticket closes in the time it takes to paste.

Same Finding, Rewritten

Take the title tag line from earlier. Suppose the crawl found that every product page renders the same title, the site name and nothing else...written as a work order it reads like this.

• Location: The product detail template, the single file rendering every product URL.
• Current State: Each product page outputs the site name as its whole title.
• Target State: Product name, then a comma, then the category, then the site name.
• Acceptance Test: Load three product pages, view source, confirm three different titles.
• Effort: One template edit plus a deploy, quoted by that file's owner.
• Rollback: Revert the single commit, a call the developer makes alone.

It can be built by somebody who never read the audit...nobody has to work out what optimized meant.

The Acceptance Test Comes First

Write the acceptance test before anything else in the ticket. If you cannot say how a person would confirm the change happened, the item is not ready.

Good tests are mechanical and dull. View source and confirm the string is present, or request the old address and confirm one hop to the new one. A test that reads "rankings improve" gives nobody a way to close the ticket.

One Ticket, One Deploy

Tickets spanning two owners tend to stall...each owner has a fair reason to wait for the other. So split anything that crosses a boundary, even when it feels like one job.

A template change covering every page it touches is one ticket. The same change applied by hand, page by page, is a content ticket for a different person in a different week. Bundled together the two look efficient on the plan...the result can never honestly be marked done.

Hours, Dates And A Named Person

An item with an owner and no date is not scheduled...it needs the treatment any other work on the roadmap gets. That means one human per ticket instead of a team, a specific deploy the change will ride, somebody named to approve copy and/or sign off the release, and freeze weeks marked in advance.

Two hours a week, held every week, moves more of an audit than a full day set aside next month. The day gets cancelled...the standing block survives because it is small enough that nothing important has to lose to it.

The Week One Dry Run

Pick the smallest genuine fix on the list and run it all the way through in week one. The point is not the fix...it is finding out where the work stalls before a whole quarter rides on it.

1. Choose one item a single person can finish without any help.
2. Walk it through approval, build, review and deploy without taking shortcuts.
3. Run the acceptance test on production and write down the result.
4. Note every place the ticket waited, and how long.
5. Ask the person who waited what they were waiting for.
6. Fix the slowest wait before the second item goes in.

Expect the delay to turn out to be something other than development. In my experience it is a review step nobody owns, a deploy window that opens twice a month, or a vendor login somebody requests each time...none of which appears in the audit.

When Advice Is Not Enough

If a full quarter goes by and nothing has shipped, you are short of capacity rather than knowledge...a second audit buys a longer description of the same untouched list.

Full disclosure, and it belongs in the sentence rather than a footnote...Vizmeta is mine. It is my done-for-you SEO studio for local businesses, and it exists because handing an owner a correct list and watching it sit for a year stopped being useful.

Findings and hands are two different purchases...buying the first when you are short of the second is how this budget usually disappears.

What To Do This Week

Open the audit you already paid for and run the sorting pass. Split it by owner, cut every item that cannot name a page or a template, and stop at twelve...the rest is not lost, just not this quarter.

Then rewrite three of those twelve into real work orders, with the target state written out and a test attached, and hand them to whoever does the work. Ask for hours back, not opinions.

Ship one of them before the month ends. One change in production tells you more about your process than a document that found everything and moved none of it.