SEO Interview Questions and Answers for Experienced (3–7 Years) — 2026

First I check whether it is a real constraint. On a 40,000-URL site it usually is not, and the real problem is quality or internal linking. On a large catalogue site I pull server logs for 30 days and segment bot hits by directory and status code. On one marketplace I found roughly 60% of Googlebot requests going to parameter URLs from sort and filter combinations, and important category pages being crawled once every few weeks. The fix was in order: stop generating the combinatorial URLs in the front end, disallow the remaining parameter patterns, tighten the sitemap to indexable canonical URLs only, and add internal links from high-crawl-frequency hubs to the neglected categories. Within six weeks bot hits on money pages roughly tripled and the average time from publish to indexation dropped from about eleven days to under two.

I compare the raw HTML response with the rendered DOM. If the content is missing from view-source but present in the URL Inspection live test's rendered HTML, rendering works but is delayed, so the question becomes indexation latency and whether critical content should be server-rendered. If it is missing from the rendered HTML too, I look for blocked resources, client-side routing that requires interaction, a failed API call under Googlebot's conditions, or content behind an event. On one React catalogue, product specifications loaded from an API that failed without a cookie Googlebot never set, so the rendered page had empty spec tables. We moved specs into the server-rendered payload and the affected templates recovered their long-tail rankings within about a month. What I ask engineering for is specific: server-render or pre-render the content that must rank, and keep it in the initial HTML payload rather than behind an interaction.

I would export indexed URLs and group them by pattern — parameters, internal search results, thin tag pages, paginated archives, staging or test URLs. Each group gets a different control. URLs with no reason to exist get removed at source and returned as 410 so they drop quickly. Facet and sort parameters that have no search demand get prevented at the link level so they are never crawled, and the existing ones get noindex until they fall out, then disallow. Near-duplicate variants that do have value get canonicalised to the primary. Internal search results get noindexed permanently. The sequencing matters: I never disallow a URL that still needs to be recrawled to see a noindex or a redirect, which is the single most common mistake I see on this job.

I start with keyword research on facet combinations. If people search 'running shoes size 10' or 'blue cotton kurta', those combinations deserve a real indexable landing page with unique title, intro copy and a stable URL. Everything beyond that — three or more stacked facets, sort orders, view toggles, price sliders — should not be crawlable at all. Practically that means the allowed set is a whitelist generated from a demand list, those pages get clean static-style URLs and internal links, and everything else is rendered without crawlable links, blocked at the parameter level and canonicalised. I also cap it: on one fashion catalogue we allowed around 900 combinations out of a theoretical several hundred thousand, and those pages went on to produce roughly a quarter of non-brand organic revenue.

Engineering owns the implementation, I own the business case and the measurement. I never bring a Lighthouse score to a planning meeting. I bring field data from CrUX or our own RUM, segmented by template, and pair it with conversion rate by that segment — for example, that mobile product pages in the poor INP bucket converted noticeably below the ones in the good bucket. Then I bring a shortlist of three specific changes with an engineering estimate attached rather than 'improve performance'. On the last site that got us LCP work into a sprint within two weeks, after six months of it sitting untouched in the backlog as a generic ticket.

Logs are the only first-party record of what bots actually requested, as opposed to what tools estimate. I segment verified Googlebot hits by directory, template, status code and response time, then compare that against the list of URLs I want crawled. The most valuable thing I have found this way was a legacy directory of expired listings, still linked from a footer element, absorbing a large share of daily bot requests while new listings were taking over a week to be indexed. We removed the links, returned 410s and re-pointed internal linking, and indexation latency for new listings dropped to about a day. I also use logs to confirm that redirects after a migration are actually being followed rather than hitting chains.

A 301 when the URL is permanently gone and there is a genuine equivalent. A 302 when the change is genuinely temporary and I want the original to keep being indexed — for example a product out of stock for three weeks, or a country page temporarily pointed elsewhere during a promotion. A canonical when both URLs must remain reachable for users but only one should be indexed, such as a product reachable from two categories. Noindex when a page must exist for users but never appear in results, like internal search or account pages. The two things I stress in a team are that canonicals are a hint that gets ignored when the pages differ meaningfully, and that noindex plus disallow together is a bug, because the crawler cannot see the noindex.

For a large multi-country setup I keep hreflang in XML sitemaps rather than in the head, because it is generated from one source of truth and does not bloat every page. The rules I enforce are that every annotation is reciprocal, every cluster includes a self-reference, the language-region codes are valid, an x-default exists for the global or selector page, and hreflang always points at canonical, indexable URLs. The failure mode I have seen most is hreflang pointing to a URL that is itself canonicalised elsewhere, which silently invalidates the cluster. Governance is the real answer: I set up an automated weekly crawl that validates reciprocity and flags clusters that break when a market retires a page, because manual checking of 15 markets does not survive contact with a release cycle.

It means Google fetched the page, evaluated it and chose not to index it, so there is no technical blocker to fix — it is a selection decision. In practice there are three causes. The first is near-duplicate or thin content, where the page adds nothing beyond an existing page, and the fix is consolidation rather than more pages. The second is low discovery value, where the page is barely internally linked and sits deep in the architecture, and the fix is internal linking from real hub pages. The third is site-level quality drag, where thousands of low-value URLs make the engine conservative about the whole domain, and the fix is pruning. I treat a rising count here as a leading indicator that we are publishing faster than we are earning quality.

I treat it as a system with three layers. The structural layer is navigation and hub pages, where I make sure every money page is within three clicks of the home page and that hubs exist for each topic cluster. The programmatic layer generates related links from structured relationships — same category, same entity, complementary intent — with rules limiting the number of links per page and preventing orphaning. The editorial layer is manual links from the highest-authority pages to the pages I am actively pushing, which is where I get the fastest movement. To measure it I take a cohort of target URLs, record their average position and impressions before, apply links only to that cohort, and compare against a matched control cohort over the following six to eight weeks.

Four phases. Pre-launch: a full crawl of the current site, a baseline of rankings, traffic and revenue by template, a list of the top URLs by traffic, revenue, backlinks and conversions, and an inventory of every tracking and verification property. Mapping: a one-to-one redirect map from old to new covering every indexable URL, built from the crawl plus Search Console and log data so nothing that receives clicks or links is missed, with a real equivalent for each rather than a lazy fallback to the home page. Staging QA: crawl staging behind auth, verify redirects, canonicals, titles, structured data, internal links, robots.txt and sitemaps, and confirm the noindex used on staging is definitely removed for launch. Launch and monitor: go live at a low-traffic hour, immediately crawl and spot-check the top 200 URLs, submit new sitemaps, watch server logs for 404s and chains hourly for the first day, then daily comparison of indexation, impressions and revenue for 30 days. My rollback trigger is agreed in writing before launch — for the last one it was a sustained drop beyond a defined threshold in revenue-bearing traffic over 72 hours that was not explained by tracking.

First I confirm it is real: compare GA4 against Search Console clicks and against server logs, because a broken tag after a migration looks exactly like a ranking collapse. If impressions are down too, it is real. Then I go in order — is the drop sitewide or concentrated in one template or directory, which usually points straight at the cause. I check robots.txt and a sample of pages for a staging noindex that survived launch, which is the single most common cause of exactly this. Then redirect integrity on the top 200 URLs, then canonical correctness, then whether internal linking to key sections was lost in the new navigation, then whether a core update landed in the same window. In the first hour I want the segment identified and the top two hypotheses tested, plus a message to stakeholders that says what I have ruled out and when they will get the next update.

Three tests. Timing: does the drop start on a confirmed update date, and is it a step change or a gradual decline? Deployment drops usually align to a release, not to an update window. Shape: an update typically moves a whole class of queries or intent type, while a technical fault usually hits one template, one directory or one device. Scope: if competitors in the same visibility index moved in the opposite direction on the same day, it is an update; if only we moved, it is us. I also always pull the release log for the two weeks before the drop, because in my experience the majority of 'algorithm update' drops turn out to be a deployment. I state the conclusion with the evidence and say what would make me change my mind.

The URL list is a union of a full crawl, Search Console pages with impressions over 16 months, analytics landing pages, top linked pages from a backlink tool and server logs, deduplicated. Matching happens in tiers: exact slug matches and rule-based pattern rewrites handle the bulk, similarity matching on title and content handles the next layer, and then I manually review the top few hundred by revenue, traffic and links, because those are the ones that cannot be wrong. Anything without a genuine equivalent goes to the closest relevant category, never the home page, and truly obsolete URLs get 410. Validation is a script that requests every old URL and asserts a single 301 to a 200 destination — no chains, no loops, no redirect to a noindexed or canonicalised URL. I run it against staging, then again against production within minutes of launch.

Generally I support the move, because a subfolder consolidates signals into one host and in practice content on the main path tends to benefit from the domain's overall strength. But it is a real migration with real risk, and the reverse-proxy work is an engineering commitment, not a DNS change, so it needs their buy-in before I recommend it. I would size the prize first: how much traffic and revenue the subdomain currently produces and what a realistic uplift would be, against the cost and the risk of a bad execution. If we proceed I run it as a full migration with a baseline and rollback plan, and I measure success as combined traffic across both properties versus the pre-move baseline, not just the new folder's numbers.

At minimum a year, but I do not remove them on a calendar date — I remove them on evidence. Before retiring any redirect I check server logs and Search Console for whether that old URL is still being requested by crawlers or users, and whether it still holds external links. URLs with live inbound links stay redirected indefinitely, because that is free equity and the cost of keeping a rule is close to zero. What I do clean up aggressively is chains, because those accumulate across successive migrations and eventually break.

I agree it before launch and put it in writing: a defined percentage drop in revenue-bearing organic sessions sustained over a set number of hours, verified against server logs so we know it is not tracking, with the decision made jointly by me and the engineering lead rather than escalated upward in a panic. I have come close once, on a platform replatform where a caching layer served a noindex header to bots for about nine hours. We caught it in the launch-day log monitoring rather than waiting for a traffic drop, fixed the header and did not need to roll back. That is the actual point of the criteria — it forces you to instrument the launch well enough to know within hours instead of within weeks.

I define it as the engine being unsure which of our URLs to rank for an intent, so the ranking URL alternates. I find it by exporting the Search Console query-page report and looking for queries where more than one URL has received impressions, then filtering to queries where the ranking URL has changed over time and where average position is stuck outside the top five. Keyword overlap alone is not cannibalisation — a category page and a guide can legitimately target the same term for different intents. When it is real, I choose from four fixes: consolidate the weaker page into the stronger with a 301 if they serve the same intent; differentiate the intent if both deserve to exist, rewriting titles, headings and internal links; canonicalise if the duplication is structural; or fix internal linking, which is often the actual cause because the site links to the wrong URL with the target anchor text. On a B2B site consolidating nine overlapping posts into two guides moved the primary term from around position eleven to the top three within two months.

For every URL I pull organic sessions, impressions, conversions or assisted conversions, inbound links, internal links, last update date and whether it is indexed. Then it is a decision tree rather than a threshold. Pages with impressions but no clicks get improved, because demand exists and we are losing the click. Pages that overlap another page get consolidated and redirected. Pages with links but no traffic get redirected to the closest relevant page so the equity is kept. Pages with nothing at all — no traffic, no impressions, no links, no strategic purpose — get removed. The safeguard is that I never prune in one big bang: I do it in cohorts, keep the list, and measure the cohort against a control over eight weeks before continuing. I have seen a mass delete take out pages that were quietly assisting conversions.

It is not a metric you can optimise directly — it is a description of the evidence a page and a site provide. On a finance site the practical work was: real author profiles with credentials and links to their professional presence, a named reviewer with a qualification and a review date on every money page, sources cited inline to primary documents, a visible editorial policy explaining how content is produced and corrected, business details and registration information available, and first-party data or original calculations on pages that would otherwise repeat what fifty other sites say. The last one matters most. Adding an author box to a page that says nothing original changes nothing.

I map the topic as entities and the questions a buyer asks across the journey, then group them into clusters with one hub and a set of supporting pages per cluster. Sequencing is by winnability: I start with the clusters where our existing authority already gives us page-two impressions, because those convert into rankings in weeks and buy credibility for the rest of the plan, then move outward to harder clusters. Architecture is decided up front — hub URLs, internal linking rules, and how a new page gets linked from day one rather than being orphaned. Then a refresh loop, where every cluster gets reviewed quarterly against what is actually ranking. Twelve months of that on a mid-size SaaS site took non-brand organic from a small fraction of pipeline to the largest single source, mostly from clusters we did not touch in the first quarter.

The diagnostic is what the SERP is doing versus what the page is doing. If the page is declining while the SERP intent has stayed the same, it usually needs a factual and depth refresh — updated data, more complete coverage, better internal links. If the SERP intent has shifted, for example from informational articles to comparison pages or tools, a refresh is pointless and it needs a rewrite as a different content type. If the page is stable and converting, I leave it alone except for factual accuracy, because I have watched people rewrite a top-three page into position nine chasing a template. Every change gets a date annotation so I can attribute the movement, and I roll out refreshes in batches so I can tell whether the approach is working before applying it to a hundred pages.

The bar is that each page must contain data or utility that genuinely differs and that a user would want — real inventory, real prices, real comparisons, real availability. If the only thing that changes between pages is the city name in the heading, it is a doorway and it will eventually be treated as one. Before building I validate demand for the pattern by sampling: does 'X in Y' actually get searched across the set, and is there a real result variety in the SERP? Then I roll out in tranches — a few hundred pages first, watch indexation and engagement, and only scale the pattern if those pages get indexed and earn clicks. Pages in the set that stay unindexed after a fair window get removed rather than left to drag on site quality.

AI is good at structure, first drafts, summarising research and generating variations. It is bad at the things that make a page worth ranking — original data, first-hand experience, a real opinion and accurate specifics. So the brief carries the parts a model cannot supply: the target intent and who the reader is, the original data or example we are contributing, the internal links and the entity coverage, and the point of view. QA is a gate, not a vibe check: every factual claim must be traceable to a named source, every statistic must be verified in the primary source rather than a secondary blog, no fabricated quotes or case studies, and a subject expert signs off on anything with commercial or regulatory consequence. I also track a simple quality signal — the proportion of published pages that earn impressions within eight weeks. When that ratio falls, the workflow is producing filler.

I pull the actual SERP and walk through it with them — who ranks, what content type ranks, and what those pages have that we do not. If the first page is entirely marketplaces and our page would be a blog post, the argument makes itself without me being the person saying no. Then I offer the alternative: the adjacent term where the SERP does support our content type, or the different asset we would need to compete for their term. If they still want to try, I agree a bounded test with a defined check-in and a definition of failure, because being right is less useful than keeping the relationship and the roadmap intact.

First I decide which pages the links are for. Usually that is a short list of commercial pages that are ranking in positions five to fifteen where competitors have a clear referring-domain gap, plus the hub pages that distribute authority internally. Then I split: roughly half on digital PR or data-led assets that earn links at scale, a quarter on relationship-based placements and partnerships in the niche, and a quarter on reclamation and fixes, which is the cheapest link source almost every site ignores — unlinked brand mentions, broken inbound links pointing at 404s, and links lost during past migrations. I measure by referring domains gained to target URLs and by movement of that cohort against a control, not by total link count.

Topical relevance first — would a real reader of that page plausibly be interested in ours? Then placement: an editorial in-content link on a page that gets real traffic beats a sitewide footer link every time. Then whether the site itself receives search traffic, which I check quickly in a visibility tool, because a high authority score with no traffic usually means a network or an expired domain. Then linking-page context: is it a genuine article or a list of outbound links? Third-party authority scores come last, as a sanity filter rather than a decision. The simplest test I apply is whether I would want that link if search engines did not exist.

My default is not to use it. Google ignores the vast majority of spam links algorithmically, and disavowing at scale can remove links that were actually helping. I would use it in two situations: an active manual action for unnatural links, where the disavow is part of the reconsideration process, or a documented negative-SEO pattern where a large volume of clearly manipulative links appeared in a short window and correlates with a demonstrable problem. Otherwise I document the profile, monitor it, and put the effort into earning links instead. I have inherited accounts with tens of thousands of disavowed domains added out of caution, which is a liability nobody wants to audit.

Nobody links to a page selling industrial valves, so I stop trying. The linkable assets are the ones that give journalists, trade publications and practitioners something to cite: original survey or proprietary data from the business, a genuinely useful calculator or specification tool, a standards or compliance explainer maintained better than anyone else's, and the founders' expertise offered as commentary through expert-source platforms and trade press. Those earn the links, and then internal linking moves the authority to the commercial pages. That last step is where most link campaigns quietly waste their budget — they earn links to a blog post that links to nothing important.

I insist on approval before placement, not a report afterwards, with the target URL and anchor specified by me. I set the metrics as referring domains to specified target pages, with relevance and traffic criteria written into the contract, and I audit a sample of placements each month for whether they are genuine editorial content or a paid-post farm. Things I do not accept: guaranteed rankings, guaranteed link counts at implausible prices, undisclosed paid placements without appropriate attributes, or link networks where the same set of sites appears across every client. If a vendor cannot tell me who the audience of a placement site is, I do not buy from them.

They still matter, but less as a standalone lever and more as a threshold. In competitive commercial SERPs I still see a clear relationship between referring-domain strength on the specific URL and whether it can break into the top five, so a page with no links usually cannot compete no matter how good it is. But links no longer rescue a page that does not match intent or comes from a site with a weak quality profile, which is why link-first campaigns produce so little now. Practically I allocate the majority of effort to intent match, internal architecture and content quality, and use links deliberately on the small set of pages where a gap analysis says we are otherwise competitive.

I build it bottom-up per cluster. For each target keyword group: search volume, an assumed achievable position with a timeline, a CTR curve for that position and SERP type, our measured conversion rate for that page type, and average order value or lead value. Multiply through, sum by cluster, and add the baseline from existing pages with a trend applied. Then I make the assumptions visible, because the CTR assumption is where most forecasts break — SERP features and AI Overviews have compressed informational CTR meaningfully, so I use our own Search Console CTR by position rather than a generic table. I always present three scenarios — conservative, expected and stretch — with the specific conditions each requires, such as engineering delivering a template fix by a certain quarter. A forecast that is a single number with no stated conditions is a promise you will be held to.

They will never match, because Search Console counts clicks on a result at the search engine, while GA4 counts sessions from a tag firing in the browser. The gap comes from users who bounce before the tag loads, consent choices that block measurement, ad or tracking blockers, redirects that lose the referrer, session timeouts splitting or merging visits, and different date handling and time zones. I explain it once in those terms and then set the convention: Search Console is the source of truth for how search sees us — impressions, clicks, queries and positions — and GA4 is the source of truth for what happens on the site — engagement, conversions and revenue. Trends in both should move together; if they diverge, that divergence is itself the diagnostic signal.

Last-click will always undercount SEO in a six-month cycle, so I stop arguing about it and change the measurement. I capture first-touch channel and landing page on the lead record and pass it into the CRM, so we can report pipeline and closed revenue by first-touch as well as last-touch. I add self-reported attribution on the form, which is crude but catches the dark-social and AI-assistant journeys nothing else sees. Then, for the strongest evidence, I run holdout or phased tests where possible — launching a cluster in one market or one product line before another and comparing pipeline development. I report a range rather than a false precision, and I am explicit that the honest answer is a band, not a decimal.

Search Console and GA4 feeding a Looker Studio or BI dashboard, with a rank tracker for a curated set and crawl data for technical health. The monthly report has three layers. The top is one page for leadership: organic revenue or pipeline versus target, the trend, and the two things that drove the change. The middle is for marketing peers: performance by cluster and page type, wins, losses and what we are testing. The bottom is the working log for me and engineering: what shipped, what is blocked and what is next. What I deliberately leave out of the leadership page is ranking screenshots and vanity keyword lists, because they invite discussion about positions instead of about revenue and resourcing.

For a commercial site, non-brand organic revenue, or non-brand organic pipeline for B2B. Non-brand matters because branded traffic mostly reflects other channels' work, and including it lets an SEO team take credit for a TV campaign. Revenue rather than sessions because it stops the team optimising for cheap informational traffic that never converts. Then guardrails so the single metric does not get gamed: indexed-page quality ratio, Core Web Vitals field data, and share of revenue concentrated in the top ten URLs, because a number that grows while dependency concentrates is fragile. I would review the guardrails monthly and the north star quarterly.

Wherever the change applies to a set of pages, I split them into a treatment cohort and a matched control cohort with similar traffic and page type, apply the change only to the treatment group, and compare impressions, clicks and position over six to eight weeks. That handles template changes, internal linking and title rewrites well. Sitewide changes cannot be tested that way, so there I rely on tight annotation — every deployment, content release and known update logged on the same timeline — plus a pre-post comparison against a competitor visibility index to control for market movement. And I am upfront when something is unattributable, because claiming causality you cannot evidence is how teams lose credibility after the first bad quarter.

Four plausible causes. We started ranking for a broader set of queries at low positions, which adds impressions without clicks. SERP features or AI Overviews expanded on our queries, pushing the organic result down or answering it outright. Our titles and descriptions are no longer matching intent after a rewrite. Or the query mix shifted towards informational terms with naturally lower CTR. I distinguish them by segmenting the report: compare CTR by position band, and compare query sets period over period rather than looking at the aggregate. If CTR at a fixed position has fallen, it is a SERP or snippet problem and I test titles on a cohort. If position has fallen while impressions rose, it is query expansion and the aggregate number is simply misleading, which is worth explaining before someone reports it as a win.

The observable effect is that purely informational queries with a simple answer lose clicks, while queries requiring comparison, personal judgement, tools, pricing or recency still send traffic. So the shift is about which intents we invest in. I stop writing definitional posts that an overview answers in a sentence, and shift budget towards pages with something an overview cannot replace — original data, calculators, real inventory or pricing, opinionated comparison and first-hand experience. For the informational pages we keep, I structure them for extraction and citation: a direct answer near the top, clear subheadings matching real questions, structured data, and unambiguous entity and source attribution. I measure it by tracking CTR at fixed positions over time for the query sets where overviews appear, because average CTR sitewide hides the effect.

It is optimising to be the source an answer engine extracts and cites, rather than the link a user clicks. What genuinely differs is the unit of optimisation: the extractable passage rather than the page, and being attributable rather than merely ranking. In practice that means self-contained answers that make sense lifted out of context, consistent entity naming so a model can connect us to the topic, structured data and clean semantic HTML, corroboration of our facts across other sources the model trusts, and machine-readable summaries of the site. What does not change is the foundation — the page still has to be crawlable, fast, accurate and genuinely useful, and most of what is sold as GEO is standard content quality work with a new label.

Some of it arrives as identifiable referrals, so the first step is a GA4 exploration or channel group that isolates known AI assistant referrers, tracked over time as a share of sessions rather than an absolute. But a large share is invisible, because users read the answer and later arrive direct or via a branded search, so I also watch branded search volume and direct traffic for correlated growth. The qualitative signal that matters most is self-reported attribution on forms, which is the only place I have seen users say plainly that an assistant recommended us. And I periodically test the queries we care about in the main assistants to see whether we are cited at all, which is a crude but honest visibility check. I present all of it as directional, because pretending to precise measurement here is not credible.

Yes, because the cost is close to zero and it is a clean, machine-readable summary of what the site is and where the important pages are. I would include what the organisation does, the key pages with a one-line description each, the core products or services, key facts a model would need to describe us accurately, and contact details. I would keep it truthful and current, because the risk is a stale file misrepresenting the business. What I would not do is present it as a ranking tactic — adoption across engines is uneven and it is a supporting signal, not a lever. I would pair it with the things that genuinely help extraction: structured data, consistent entity naming and clear on-page answers.

The failure modes are fabricated facts, invented sources, generic content that adds nothing, and duplicated angles across pages. The gates are: a brief that specifies the original contribution before writing starts, a fact-check step where every statistic is traced to a primary source, a subject-expert sign-off on anything with commercial or regulatory consequence, and a cannibalisation check against existing pages before publishing. The measurable signal I track is the proportion of newly published pages that earn impressions within eight weeks and clicks within twelve. When that ratio starts falling, we are producing volume without value, and I slow publishing down rather than defend the number.

The change is real for informational traffic, and I would not pretend otherwise in a board conversation. But the objective was never clicks, it was being present and trusted at the moment someone decides. Search engines and answer engines both need sources, and both preferentially use content that is well-structured, corroborated and demonstrably authoritative — which is the same work. So the investment case shifts from traffic volume to two things: owning the commercial and comparison intents where users still click because they need to evaluate and buy, and being the cited source on the informational intents so we shape the answer even when there is no click. Practically that means less thin informational publishing, more original data, tools, and product and category pages that actually deserve to rank.

I start with the commercial target and the constraints, because a roadmap that assumes unlimited engineering time is fiction. Quarter one is foundations and fast wins: fix what is actively costing us — indexation, template issues, cannibalisation — and ship the changes that can be done without engineering, mainly internal linking and on-page. Quarter two is the growth engine: the priority content clusters and the template improvements that needed engineering time secured in quarter one. Quarter three scales what worked and adds links and digital PR to the pages that a gap analysis says are close. Quarter four consolidates, prunes and plans the next year. Every item carries an owner, an estimate and an expected impact range, and the whole plan gets re-forecast quarterly, because a roadmap that has not changed in nine months is not being managed.

Three things have worked consistently. First, I write tickets in their language with the acceptance criteria, the affected templates and the expected effort, not 'fix crawl budget'. Second, I attach a quantified outcome — 'this template accounts for 30% of organic revenue and this change addresses the reason it converts below the rest' — so it competes on the same terms as everything else in the backlog. Third, I get into the planning process rather than sending requests at it: attending refinement, having a standing small allocation for SEO work, and building one relationship with a senior engineer who will tell me honestly what is cheap and what is not. That last one changed more outcomes than any document. On my last team, reframing a technical fix as a conversion problem got a six-month-old ticket delivered in one sprint.

I try to understand the objective behind the request first, because usually the goal is reasonable and only the tactic is wrong, and once I know the goal I can propose a route that achieves it without the damage. Then I make the risk concrete — which pages, how much traffic and revenue, over what timeframe — rather than saying it is bad for SEO. If they still want it, I ask for a bounded version: one section rather than the whole site, with a defined review point and an agreed measure of failure, and I make sure we have a rollback path. If I am overruled entirely, I document the risk once, calmly and without drama, commit to the decision, and instrument the measurement so we can see quickly whether I was right. Being unmanageably right is worse for the site than being wrong occasionally.

I delegate whole outcomes rather than isolated tasks — 'own the cannibalisation programme for this section' rather than 'export this report' — because ownership is where judgement develops. I review the reasoning, not just the deliverable: I ask what they ruled out and why, which surfaces gaps a corrected spreadsheet never would. Development is structured around a simple skills map covering technical, content, analytics and stakeholder skills, with one deliberate stretch area per quarter and a real project attached to it. And I make them present their own work to stakeholders, because at 3–7 years the ceiling is almost never technical skill, it is the ability to make a case to someone who does not care about SEO.

I do not open with an argument for keeping the budget. I open with what the current spend produces — revenue or pipeline from non-brand organic, and the cost per acquisition compared with paid — because if that comparison is favourable the conversation usually changes on its own. Then I present the cut as a set of trade-offs rather than a single number: at the reduced budget, here is what we stop, what it costs in forecast revenue, and when that shows up, since SEO losses arrive quarters later, which is exactly why it gets cut first. And I make clear what I would protect above everything else: technical health and the existing top revenue pages, because losing those is expensive and slow to reverse, while pausing new content is recoverable.

I ran a large content refresh on a site where around 200 posts were rewritten in one release. Traffic to that cohort dropped roughly a fifth and took months to recover. The failure was mine in two ways: I changed too many variables at once, so I could not tell which change caused what, and I did not run a control cohort, so I could not even prove the loss was the refresh rather than a broader movement. What changed afterwards is now a rule I bring to any team: content changes ship in cohorts with a matched control, and no more than a defined batch size in a single release. The next programme on that site, run that way, produced a measurable gain and I could actually attribute it.

I want to move further into owning outcomes rather than executing channels — a role where I set the organic strategy, forecast it, and work directly with product and engineering on what gets built, with a small team I develop. What appeals here is that the role sits close to the product decisions rather than sitting downstream of them, which is where SEO either works or does not. What I would want to understand is how the roadmap is owned and how much engineering capacity organic realistically gets, because that determines whether the role is strategic in practice or only on paper.