Sample deliverable
Technical issue register: findings turned into tickets a developer can close
Every row in this register is written so a developer who never read the audit can pick it up, reproduce the problem, fix it and prove it is closed. That is the difference between a report and work that actually ships.
Example, not a client's data
The setup is invented: a content heavy site on a common content management system, replatformed not long ago, one shared staging environment, and a development team that ships once a week. All URLs point at example.com. There is no real client here and no real backlog.
How a row is built
A ticket that can be argued with is a ticket that gets done. Each column exists to remove one of the reasons the work stalls between the audit and the release.
- ID: a stable label, so the same issue keeps its name in the backlog, in the release notes, and in the QA crawl afterwards.
- Severity: Critical blocks crawling, rendering or indexing. High degrades how a page is read. Medium is hygiene that can wait for a scheduled release.
- Evidence: the shortest path to seeing the problem yourself, written for someone with no audit context.
- Acceptance criteria: an observable state, not an intention. Either the criterion is met on the live site or the ticket stays open.
- Owner: who ships it. Some rows we do under scoped access, some belong to the development team, and some need both.
The register
| ID | Issue | Severity | Evidence | Acceptance criteria | Owner |
|---|---|---|---|---|---|
| T-01 | The staging directive that blocks crawling is live on the public host | Critical | Open the robots file on example.com and look for a rule that disallows the whole site | The live robots file allows the public sections, and the blocking rule exists only on staging | Us, hosting confirms |
| T-02 | Body copy on the service template appears only after hydration | Critical | Request the page with JavaScript disabled and search the raw response for the first paragraph | The first paragraph is present in the raw HTML response on every service page | Client dev, we specify |
| T-03 | A noindex tag returns to the blog index after some releases | Critical | Compare the head of the blog index across the last two deploys | Two consecutive releases pass with the tag absent, and a change detection rule watches it | Us with client dev |
| T-04 | Paginated category pages canonicalize to the first page | High | Open the second page of any category and read the canonical element | Each paginated page canonicalizes to itself, and pagination links stay crawlable | Client dev, we specify |
| T-05 | Old product URLs reach their destination through two redirect hops | High | Request an old product URL and follow the chain to the end | Every old URL reaches its destination in a single permanent redirect | Us |
| T-06 | One language is missing its return links in the hreflang set | High | Compare the hreflang block on a page pair in both languages | Every language pair references the other and itself, and the set validates | Us |
| T-07 | A removed page answers with a normal status and a styled template | High | Request a deleted product URL and read the status code | Removed URLs answer with a not found or gone status, and the template is not indexable | Client dev |
| T-08 | Filter parameters create crawlable URLs that nobody searches for | High | Crawl one category and list the parameter variants that are reachable from links | Only the combinations named in the agreed parameter policy stay crawlable and indexable | Us with client dev |
| T-09 | Breadcrumb markup is injected after the page loads | Medium | Search the raw response of a product page for the breadcrumb type | The markup is present in the raw HTML and validates without warnings | Client dev, we specify |
| T-10 | The sitemap lists URLs that redirect or are excluded from indexing | Medium | Take a sample of URLs from the sitemap and check the status of each | The sitemap is generated from the live indexable set and regenerates on publish | Client dev, we specify |
| T-11 | Crawler requests concentrate on parameter URLs rather than category pages | Medium | Read one week of access logs and group the requests by URL pattern | The parameter policy is live, and the same log window is read again afterwards to see how the distribution moved | Us |
Order of work
Order is decided by what unblocks the rest, not by how quickly a row can be closed. A fast fix that depends on an unfixed blocker is wasted twice.
- First, anything that stops a page being crawled, rendered or returned correctly. Nothing else can be measured while these are open.
- Second, the rules that decide what belongs in the index: canonicals, pagination, parameters, status codes.
- Third, markup and delivery details that change how a page is presented once it is read correctly.
- Last, the monitoring that keeps the first three from quietly coming back on a routine release.
Rules for safe implementation
- Every change lands on staging first, and staging is crawled before anyone touches the live site.
- One class of change per release. A canonical rule and a redirect map that ship together are impossible to separate when something moves.
- Each ticket carries a rollback: the previous rule, file or template, kept where your team can restore it without us.
- Changes that affect what is indexed are signed off by the client in writing, in the ticket, before the release.
- Access is scoped to what the ticket needs and revoked when the sprint closes. We do not ask for administrator rights we have no use for.
- After the release we run a QA crawl and compare it with the one taken before, so a fix that broke something adjacent is visible at once.
What we check after each release
- The ticket criterion itself, on the live site rather than on staging.
- The raw HTML of the affected templates, because a change that appears only after JavaScript runs has not really shipped.
- Status codes and redirects for the URL sets the release touched.
- Coverage and crawl signals in Search Console over the following weeks, since the platform reflects a change on its own schedule.
Synthetic example, not a client's data
- The register here is short and tidy. A real one is longer and also keeps the rows that turned out to be non issues, with a note saying why.
- Severity is assigned against the site it belongs to. The same row can be Critical on one project and Medium on another.
- Nothing in this sample is measured. On a real ticket the evidence column names files, URLs and log windows.
- The owner column follows the access model agreed at the start. Where your team ships everything, those values read differently.
A real register is delivered as a working backlog: tickets your team can import, a specification per row, and a post release crawl that closes each one against its own criterion. Sprint scope is described on the service page.
Technical SEOReady to hand the setup to us?
Tell us what you have today. We confirm the scope and the fixed price before any work starts, and every login stays yours.
Start the setupNo commitment. Response within one business day.