With one engineering sprint a quarter for SEO, how do you choose between fixing a sitewide template bug and shipping a new page type with forecast upside?

1 reply

• 

  adminAdmin

  Original poster 19 hours ago

  Rank both on risk-adjusted value you can realise within your planning window, not on the size of the upside. A template bug that is measurably suppressing crawling, rendering, indexing or conversion almost always goes first: you are already paying its cost every day, and the fix protects every future page, including the new page type. A bug that only shows up as an audit warning, with no trend or indexing evidence behind it, usually loses to a new page type backed by first-party demand data.

  The asymmetry to keep in mind is evidence quality. The cost of a harmful template bug is usually something you can observe in your own data. The forecast for a page type you have never shipped is a hypothesis built from estimates. The two rarely deserve equal weight in a spreadsheet, even when the forecast number is much bigger.

  Sort the bug by what it breaks, not by how many pages it touches

  “Sitewide template bug” covers everything from a stray noindex to a missing alt attribute. Its class matters far more than the word “sitewide”.

  Bug class	Examples	Evidence of harm to look for	Usual priority
  Indexing and rendering blockers	noindex in the initial HTML, canonicals pointing at the wrong URL, live pages returning non-200 codes, main content only appearing after client-side JavaScript that fails	Page indexing report filtered to the template, rendered HTML in URL Inspection, a drop lining up with a deployment date	Fix first, often as an incident rather than a sprint item
  Discovery and crawl efficiency	Internal links only injected by JavaScript, broken pagination, filter parameters generating near-infinite URLs	Server logs, Crawl Stats, growth in “Discovered - currently not indexed”	High on large sites, often low on small ones
  Relevance and presentation	Duplicate titles from a broken template variable, invalid structured data, weak heading structure	CTR by template, rich result reports, query-to-page mismatch	Medium, with uncertain effect size
  Hygiene	Validator warnings, minor hreflang errors on low-value markets, HTML weight well within limits	Audit tools only, no trend movement	Low, unless it blocks something else

  A few documented mechanisms decide which row a bug belongs in. Google’s JavaScript documentation says a noindex in the original HTML can stop rendering, so removing it with JavaScript may not work, and that pages returning non-200 status codes might not be rendered. Googlebot fetches up to 2MB of an HTML file and ignores bytes beyond that, so template bloat that pushes main content or key links past that point is a blocker, not hygiene. Crawl efficiency bugs matter most where Google’s crawl budget guidance is aimed: sites with over a million pages changing roughly weekly, over 10,000 pages changing daily, or a large share of URLs sitting in “Discovered - currently not indexed”. On a 5,000-page site, the same bug may cost very little.

  Why the page type forecast needs a haircut

  Most new page type forecasts multiply keyword volume by a click-through curve by a conversion rate. Every input carries error, and the errors compound:

  • Indexing is assumed. Newly templated pages often sit in “Discovered - currently not indexed” or “Crawled - currently not indexed” for a long time, especially when each page adds little that existing pages do not already cover.
  • Ranking takes time. Value tends to arrive over months, not the week after launch, so much of a 12-month forecast may fall outside the planning window.
  • Generic CTR curves may not fit your SERPs. AI Overviews, local packs, shopping units and other features can absorb clicks on some queries.
  • Gross is not net. The new pages may take clicks from existing category or article pages rather than adding new ones.
  • Quality risk scales with the template. If each page is a template filled with thin or duplicated data, you are closer to what Google’s scaled content abuse policy describes, and the downside is no longer just “zero upside”.
  • Volume is an estimate. Third-party keyword volumes are modelled, not observed.

  None of this means forecasts are useless. It means the forecast should carry a probability based on the evidence behind it, the same way the bug fix should.

  How strong is the evidence on each side?

  Evidence for the new page type, strongest first

  1. You already earn impressions for the target queries through pages that do not match the intent (visible in Search Console).
  2. Paid search data for those queries, with real impressions and conversions.
  3. Internal site search logs showing the demand.
  4. Competitors ranking with this page type, and you have data at least as good as theirs.
  5. Third-party keyword volume only.

  Evidence that the bug causes harm, strongest first

  1. A drop on the affected template, dated to the release, with unaffected templates flat.
  2. An indexing pattern specific to the template’s URLs.
  3. Logs showing crawl wasted on, or withheld from, the affected URLs.
  4. An audit tool flag and nothing else.

  I would compare the two on the same simple sum: monthly value if it works, multiplied by the probability that it works, multiplied by the months of value that fall inside your planning window, minus any ongoing cost. The probabilities are judgement calls, not research-derived figures. Writing them down still forces the conversation onto evidence rather than onto whose number is bigger.

  A decision table for the common situations

  Condition	Lean towards the bug fix	Lean towards the new page type
  Bug blocks indexing or rendering on revenue templates	Almost always
  Bug is hygiene with no measurable trend		Usually
  New page type would reuse the buggy template or components	Fix first, because it is a prerequisite
  Forecast rests on first-party demand (Search Console impressions, paid data)		Stronger case
  Forecast rests on third-party volume only	Stronger case	Pilot before committing a sprint
  Large site with real crawl constraints	Fix crawl waste first, since new URLs compete for the same crawl
  Bug can be patched outside the sprint (edge or CDN rule, CMS setting, platform defect queue)	Patch it there	Use the sprint for growth
  Page type must be live before a seasonal peak		Timing can outweigh a modest bug
  Fix touches a shared component with a wide blast radius	Only with QA and rollback budgeted inside the sprint

  Try to make it not an either-or choice

  With one sprint a quarter, the people who get the most out of it rarely accept the binary as presented. Before choosing, I would work through these:

  1. Size both properly. If the fix is two days of work, this is not really a trade-off. Get an engineering estimate before debating value.
  2. Argue the bug into the defect queue. A template bug that breaks indexing is a product defect, not an SEO feature request. Bring the dated evidence to the platform or product owner and ask for it to be handled as a bug, keeping the SEO sprint for growth. This does not always work, but it is worth the conversation.
  3. Pilot the page type without engineering. Build a small batch through the CMS or an existing template, then measure indexing rate, impressions per indexed page and clicks over a couple of months. A pilot turns a third-party forecast into first-party evidence and makes next quarter’s decision easier.
  4. Use a stopgap. Some bugs (headers, canonicals, redirects, status codes) can be patched at the edge or CDN while the proper template fix waits. Treat these as temporary and document them, because they become invisible technical debt.

  Hypothetical example:

  A marketplace has 600,000 listing pages. After a front-end release, paginated category pages lose their crawlable links to deeper listings. Logs show Googlebot requests to deep listings falling from the release date, “Discovered - currently not indexed” grows on listing URLs, and organic clicks to listings fall while other templates stay flat. The team estimates the loss at about 30,000 clicks a month. The fix is a week of work plus QA. The competing idea is “brand in suburb” landing pages with a forecast of 90,000 clicks a month at maturity, built only on third-party volume.

  Over a 12-month window, the fix might look like 30,000 clicks, times a high probability (say 0.8, because the harm is dated to the release), times about ten months of recovered value. The page type might look like 90,000 clicks, times a low probability (say 0.3, because the evidence is weak and cannibalisation is likely), times perhaps four months at full value once ramp-up is allowed for. That is roughly 240,000 expected clicks against roughly 108,000. The fix wins, and the new pages would also depend on the same deep-link paths. If Search Console already showed impressions for “brand in suburb” queries landing on generic pages at positions 15 to 30, the probability would rise and the answer could flip, especially over a 24-month horizon. (All figures invented for illustration.)

  Watch for this:

  Bug fixes are politically weaker than new page types because they restore value rather than create visible new value. Frame the fix as revenue already being lost, with the dated evidence and a control template, rather than as “technical debt”. And do not let the new page type’s forecast go unchallenged just because it is the more exciting slide.

  Decide in advance what result would change next quarter’s choice

  Whichever you ship, set the success criteria before deployment and mark the release date with a Search Console annotation.

  • For the bug fix: compare the affected template with an unaffected control on indexed URLs, crawl requests in logs, clicks and revenue. If nothing recovers after a reasonable recrawl period, the diagnosis was probably wrong, and that is worth knowing before blaming the next bug.
  • For the page type: track indexing rate of the new URLs, impressions per indexed page, clicks, conversions, and the net change on existing pages that target overlapping queries. A strong gross number with matching losses elsewhere is a reshuffle, not growth.
  • For the backlog: record the estimates you used and compare them with what happened. After a few quarters, you learn how optimistic your forecasts tend to be, which is the most useful input for every future sprint decision.

  My working rule: if the bug is blocking indexing, rendering or discovery on templates that carry revenue, fix it, and try to get it done outside the SEO sprint if you can. If the bug only shows up in audit tools, spend the sprint on the page type, but only if its demand is visible in your own Search Console or paid data. If neither side has strong evidence, spend the quarter generating that evidence with a no-engineering pilot and a proper measurement of the bug’s impact, so the next sprint is chosen on data rather than on the more persuasive forecast.

  Need help with this on your own site?

  Niraj Raut works with businesses in Nepal, Australia, the UK, Europe and the US on technical SEO, ecommerce SEO, local SEO and AI search.

  See SEO services