Most descriptions of Site Optimiser describe what it does — scrape competitor structure, rebuild the page around it, publish something stronger. What that summary skips is that “rewrite” and “publish” are not one step, and neither is “scrape” for that matter. The pipeline is four distinct stages, each with its own failure modes and its own point where a person can intervene before the next stage runs, and understanding where those seams are is the difference between trusting the output and treating it as a black box you re-run when rankings don’t move.
This is a walk through the actual sequence — scrape, structure selection, rewrite, publish — with the mechanics of each stage and the specific things that go wrong when someone skips the review step in the middle and just lets it run end to end.
Stage one: the scrape
The pipeline starts with a keyword, not a URL. You give Site Optimiser the query you’re trying to rank a page for, and it pulls the current top organic results for that query — generally the top eight to ten positions, filtered to exclude paid placements and results that don’t reflect deliberate editorial structure, like forum threads or raw PDF results that occasionally rank for informational queries. Each result gets fetched and parsed for its heading hierarchy and any list markup sitting directly under a heading.
This stage is intentionally narrow. It does not attempt to score the competitors, does not attempt to judge which one is “best,” and does not weight a result differently because it’s in position one versus position eight — a heading that shows up on the page in position eight gets scraped exactly as faithfully as one from position one, on the reasoning that rank position on the day of the scrape is a noisy signal and shouldn’t be treated as a proxy for structural quality. What you get out of stage one is raw material, not a recommendation.
One practical detail that trips people up: the scrape is a snapshot. If you run it today and again in six weeks, the results can differ meaningfully, because the top-ten set itself has moved and because competitors update their own pages. Site Optimiser doesn’t cache scrapes indefinitely for this reason — each run pulls fresh data, which means re-running the pipeline on a page you’ve already optimized isn’t redundant, it’s picking up whatever has shifted in the competitive set since the last pass.
Stage two: structure selection
The raw scrape gets merged into a single candidate structure — a de-duplicated list of headings and list blocks, each annotated with how many of the scraped sources contained something like it. This is where the checkbox interface sits, and it’s the one stage in the pipeline that’s manual by design rather than manual by limitation. Nothing about the scrape or the eventual rewrite requires a human in the loop here technically; the reason the step exists as a checkbox review rather than an auto-accept is that merged competitor structure is not the same thing as a good outline, and there isn’t a reliable automated signal for telling the two apart.
A person works through the candidate list and decides which headings actually belong on the page being built — keeping the ones that answer a real sub-question a reader would have, cutting the ones that are organizational filler or off-topic for this particular page’s angle. What comes out of stage two is a finished outline: an ordered list of headings, each marked either as one to keep as-is if the page already has content there, or one to newly generate in the rewrite.
This stage has no time limit and nothing downstream runs until it’s confirmed. That’s a deliberate pause point — everything before it is fetch-and-merge, which is cheap and fully reversible, and everything after it commits to generating actual page content around whatever outline gets locked in here.
Stage three: the rewrite
Once the outline is confirmed, the rewrite stage generates content for each heading that doesn’t already have it, and — depending on which mode you ran the scrape in — optionally revises existing sections to align better with what’s covered under the corresponding heading across the scraped competitors. This is not a single monolithic generation pass; it works heading by heading, generating a section, checking it against the outline position it fills, and moving to the next.
The reason it works this way rather than generating the whole page in one shot is consistency of depth. A single-pass generation across a full outline tends to front-load detail into the first couple of sections and thin out toward the end, because the model is implicitly budgeting length across the whole task at once. Generating section by section, anchored to what that specific heading is supposed to answer, produces more even coverage — the fourth section gets written with the same attention as the first, rather than as an afterthought once the “budget” for the page feels spent.
Existing content that you chose to keep in stage two isn’t silently left alone in a way that creates a stitched-together feel — the rewrite pass also lightly harmonizes transitions between kept sections and newly generated ones, so a reader doesn’t hit an obvious tonal seam where old copy meets new copy. It does not rewrite the kept sections’ substance, only the connective tissue immediately around them.
What the draft looks like before publish
The output of stage three is a draft, not a live page. It lands as a full HTML document matching the confirmed outline, with every heading from stage two represented and either the original content or newly generated content underneath it. This draft is reviewable before it goes anywhere — the pipeline doesn’t force a straight line from rewrite to publish, and treating those as the same step is one of the more common ways people end up unhappy with output that was actually fine at the outline stage but got fumbled in generation.
Specific things worth checking in the draft before moving to stage four: whether any generated section drifted from the outline heading it’s supposed to answer, whether keyword-mode entity suggestions got worked in naturally or read as forced, and whether the transition harmonization mentioned above left any sentence that reads like it’s talking to itself — an artifact that shows up occasionally when a kept section and a generated section disagree slightly on claims or framing. None of these are common, but they’re the specific things worth a human pass rather than a general “read it and see if it feels right” review.
Stage four: publish
Publishing pushes the finished draft live, converting it into both the standard block content and, on Elementor-managed sites, the native widget structure the page builder expects, so the published page is editable the same way any other page on the site is rather than existing as an opaque HTML blob bolted onto the theme. Metadata — the page’s existing title tag and any manually set meta description — is preserved through this step rather than regenerated, on the reasoning that Site Optimiser’s job is structure and body content, not search-snippet copy, which is a separate concern handled elsewhere.
Publish is also where the page re-enters whatever else your site does automatically post-publish. If Auto-Interlinking is active, it evaluates the newly published or updated content for internal link placement on its own schedule rather than as part of the Site Optimiser run itself — the two systems don’t share a single pass, which keeps interlinking logic decoupled from structure rewriting and means a page can get its structure rebuilt without also triggering a fresh interlinking pass the same minute, if that’s not what you want.
Where the pipeline can be stopped and restarted
Because the four stages are genuinely separate rather than one continuous function, you can stop after any of them and pick back up later without losing work. A confirmed outline from stage two doesn’t expire — you can lock in a structure selection today and generate the rewrite next week once you’ve had time to think about whether the deselections were right. A draft from stage three can sit unpublished indefinitely while it goes through editorial review, which matters for teams that require a second set of eyes before anything goes live regardless of how it was produced.
What you can’t do is skip backward without cost — if you publish a draft and then decide the stage-two outline was wrong, fixing that means re-running structure selection and rewrite, not patching the live page directly, since the live page’s content is downstream of decisions made two stages earlier and editing it by hand just creates drift between what’s live and what the pipeline thinks the page’s outline is.
Where this pipeline earns its keep versus where it doesn't
The full four-stage run is most worth its time on pages with real competitive pressure — queries where the current top ten has moved recently, or where your existing page has been flat for long enough that a structural rebuild is a reasonable hypothesis for why. Running it reflexively on every page on a schedule, regardless of whether anything about the competitive landscape has actually shifted, tends to produce diminishing returns and a fair amount of unnecessary editorial review overhead for pages that weren’t the problem in the first place.
It’s also worth being honest that structure is one input among several into ranking, not the whole story — a page can have an excellent, well-selected outline and still underperform for reasons the pipeline doesn’t touch, like backlink profile or page speed. Site Optimiser rebuilds structure; it doesn’t diagnose everything that could be holding a page back, and treating a structural rebuild as a universal fix for stalled rankings sets expectations the tool was never built to meet.
There’s a related question worth asking before running the full pipeline on a given page: is the problem actually structural, or is it something the scrape wouldn’t surface at all. A page that’s never been indexed properly, or one sitting behind a canonical tag pointing somewhere else, will not improve from a better outline no matter how carefully the checkboxes were selected in stage two — the pipeline assumes the page is eligible to rank and is being outcompeted on content quality, not that something upstream of content is blocking it from being evaluated in the first place. Ruling that out first, with basic index-status and technical checks, is a five-minute step that saves running four stages of work against a problem those four stages can’t fix.
Where to go next
The scrape-to-publish sequence is one piece of a broader publishing and site-health workflow that also covers how cadence, crawl behavior, and interlinking interact with pages built this way. For the full picture of how these publishing and site-health pieces fit together, see Publishing, Distribution, and Site Health: The Complete Guide.
