Digital Vikingz
The pass runs once the rollout is complete and two weeks of post-update data exist, and otherwise every 90 days. The pass reads query count, impressions, clicks and the lists of new, lost and shared queries per cluster, not the site total. Each page receives one of four decisions: keep, reconfigure, consolidate or remove, and every decision is logged with the metric that will confirm or reverse the decision at the next pass. A configuration pass is not a recovery project; a site with no traffic drop runs the same pass on the same schedule.
Entity card
Field | Value |
Term | Content configuration pass |
Also called | Configuration pass, 90-day configuration, post-update configuration |
Part of | Semantic Content Audit, run on a live site at a fixed interval |
Depends on | Search Console with at least 16 months of history, a cluster map of the site, and the publication log |
Produces | One decision per page, one batch of changes, and a dated configuration log |
Measured by | Query count and clicks per cluster at the next core update |
Not the same as | A content refresh, a rewrite, or a traffic drop recovery |
What is a content configuration pass?
A content configuration pass is a re-engineering of live pages after a ranking state change, decided per cluster from Search Console and applied as one batch.
The word configuration is used on purpose. A refresh adds new paragraphs. A rewrite replaces the page. A configuration changes the arrangement of what exists: which heading comes first, which sentence defines the entity, which page links to which, how much depth each section carries. The facts stay. The structure moves to match what the query network now asks for.
The concept comes from Koray Tuğberk Gübür's framework, which treats every core update as a recalculation of how Google weights definitions, section order and topical borders, and prescribes a reconfiguration pass after each one. Holistic SEO holds his original writing on content configuration. We apply the pass as a fixed procedure on every site we run.
A configuration pass has one input and one output. The input is the per-cluster ranking state read from Search Console. The output is a dated log of decisions and the batch of changes made. Everything between the two is the procedure, and the procedure starts with timing.
When does a content configuration pass run?
A content configuration pass runs after a core update rollout is complete and two weeks of post-update data exist, and otherwise every 90 days.
Google announces each core update on the Search Status Dashboard and marks the rollout complete on the same page. Data read during the rollout is unreliable, because positions move day to day until the update settles. The pass waits for the completion notice, then waits a further 14 days so the comparison window holds a full fortnight of settled data.
The 90-day interval covers quiet periods. Query networks move without an announced update: new phrasings appear, a competitor publishes, a definition shifts in the authoritative sources. A quarter is long enough for those shifts to show in the query lists and short enough that the site does not fall a full season behind.
Two timings are avoided. A pass never runs during a rollout, because the changes land on unsettled data and the next read is contaminated. A pass never runs twice inside one month, because the previous batch of changes has not yet been crawled and re-ranked, and a second batch hides the effect of the first.
Once the window is fixed, the pass reads a defined set of data and nothing else.
Which data does a content configuration pass read?
A content configuration pass reads Search Console performance per page cluster, compared across the pre-update and post-update windows, plus the crawl and index state of each cluster.
The data a configuration pass reads is listed below:
Query count per cluster. The number of distinct queries that produced an impression for the cluster's pages. A falling query count on a cluster says the cluster lost topical reach, which clicks alone do not show.
Impressions and clicks per cluster. Read as a pair, because impressions that rise while clicks fall mean the cluster now ranks for queries the pages do not answer.
New queries. Queries that produced impressions in the post-update window and none before. The new queries show where Google now places the cluster.
Lost queries. Queries that produced impressions before and none after. The lost queries show which attributes the cluster no longer holds.
Shared queries. Queries for which two or more of the site's own URLs received impressions in the same window. Shared queries are cannibalisation candidates.
Average position per query, not per page. Page-level position averages across queries hide the queries that matter; the pass reads position on the top queries of each cluster.
Crawl stats and index coverage. Crawl requests per day and the count of pages excluded from the index, read from the Search Console reports, so a ranking change is not misread when the cause is access.
Search Console holds 16 months of performance data, so the pass compares the post-update fortnight with the same fortnight before the rollout and with the same period a year earlier where seasonality applies. The site total is never the unit of reading. A site that is flat in total is usually one cluster up and one cluster down, and the pass exists to find which.
Once the data is in hand, the pass runs as eight steps.
How do you run a content configuration pass?
A content configuration pass runs in eight steps, from fixing the comparison window to publishing one batch of changes with a dated log.
The steps of a content configuration pass are listed below:
Fix the two windows. Post-update: the 14 days after the completion notice. Pre-update: the 14 days before the rollout began. Record both dates in the log.
Export Search Console performance by page and by query for both windows. Map every URL to its cluster using the cluster column in the topical map. Pages without a cluster are logged as a map fault before anything else.
Classify each cluster into one of three states: gained, held or lost, on query count and clicks together. A cluster with rising clicks and falling query count is logged as narrowing, not gained.
Read the lost queries for each lost or narrowing cluster. Group the lost queries by the attribute they name. The attribute that lost the most queries is the section to reconfigure first.
Read the new queries for each cluster. A new query that the cluster answers in a sentence is a heading candidate. A new query the cluster does not answer at all is a page candidate, passed to the topical map and not built inside the pass.
Read the shared queries. Two URLs receiving impressions for one query is a consolidation decision: one URL keeps the query, the other links to that URL or is merged into that URL.
Give every page one decision: keep, reconfigure, consolidate or remove. Write the decision, the reason and the metric that will confirm the decision next to the URL.
Apply all changes in one batch, update the internal links that the changes affect, and close the log with the date and the next pass date.
We run step 7 on paper before any page is opened. A page edited before its decision is written becomes a refresh, and the next pass has nothing to measure against.
The eight steps produce a short list of change types, and the list is the same on every site.
What changes in a content configuration pass?
A content configuration pass changes heading order, definition sentences, internal links and anchors, section depth, dated figures and the closing questions, and leaves the entity and the predicate untouched.
The changes a configuration pass makes are listed below:
Heading order. The attribute that gained queries moves up; the attribute that lost queries is checked for a weak opener before the attribute is moved. The first H2 after the summary carries the attribute the query network now weights most.
Definition sentences. The sentence after "is" is checked against the current authoritative sources. A definition that has shifted in the consensus is restated, in the same place on every page that carries the definition.
Internal links and anchors. Links are added from the pages that gained to the pages that lost, inside the same cluster. Anchors keep the target's entity words and vary the surrounding phrase.
Section depth. A section whose queries rose receives more depth. A section whose queries vanished is shortened or merged, so the page's weight concentrates on the attributes the network still asks for.
Dated figures. Every figure with a date is checked and re-dated, with the source re-read.
Closing questions. New queries phrased as questions enter the closing questions when no heading answers them.
Meta description. Rewritten only when the heading order changed, because the description follows the heading order.
Two things never change inside a pass. The central entity of the page stays. The predicate in the H1 stays. A page whose entity or predicate needs to change is not configured; the page is sent back to the topical map as a new node decision.
The list is short by design. Depth is added where demand moved and nothing is added where demand did not. The restraint is what separates a configuration pass from the usual response to a core update.
What does a content configuration pass not do?
A content configuration pass does not rewrite pages wholesale, publish new pages in reaction to the update, chase the update's reported theme, or touch pages whose clusters held.
The actions a configuration pass excludes are listed below:
Wholesale rewriting. A rewrite destroys the historical data attached to the page and resets its ranking state. The pass changes structure and keeps the text that earned the history.
Reactive publishing. New pages built during the post-update fortnight take crawl attention from the pages being re-read. Page candidates go to the map and publish in the normal rhythm.
Theme chasing. Commentary on each update names a theme. The pass reads the site's own clusters and ignores the commentary, because the clusters say what moved on this site.
Editing held clusters. A cluster that held is left alone. Changes to a stable cluster create a new variable the next pass has to explain.
Link acquisition and disavowal. Off-site signals are a separate track with a separate schedule. The pass is an on-page procedure.
Google's own guidance on core updates says that pages which drop may have nothing specific to fix and that recovery, where the content is sound, may not show until the next core update. The pass is built around that statement: one careful batch, then a wait, then a read.
The pass and a recovery share the same data and differ in the question they ask.
How does a configuration pass differ from a traffic drop recovery?
A configuration pass runs on every site on a schedule, and a traffic drop recovery runs once on a site whose clusters lost, with diagnosis before configuration.
A recovery starts from a symptom and works back to a cause: access, index, cannibalisation, dilution or lost topical reach. Only after the cause is named does the recovery apply the configuration steps above, often together with consolidation across many URLs. Traffic dropped after a core update sets out that diagnosis in order.
A configuration pass starts from a schedule and asks a narrower question: what did the query network move on this site since the last read, and where does the structure follow. A site that runs the pass every quarter rarely needs the recovery, because the drift is corrected in small batches before an update turns the drift into a drop.
The pass is also the procedure inside the Semantic Content Audit when the audit is run on a site that has been live through one or more core updates. The audit reads the same per-cluster states and returns the same four decisions per page, with the log as the written deliverable.
How is a content configuration pass recorded?
A content configuration pass is recorded in a log with one row per page: the date, the cluster state, the decision, the change made, the reason and the metric that confirms the decision at the next pass.
The log is the memory of the site. A site without a log reads a change in a cluster at the next pass and has no way to tell whether the change came from the update or from the last batch of edits. A site with a log matches every movement to a dated change or leaves the movement unexplained on purpose.
The log also feeds the client report. Each pass ends with a one-page summary: clusters gained, held and lost; decisions taken; and the Search Console panel per cluster for the two windows, in the format shown on Results, measured in Google Search Console. The next pass date is the last line.
Questions about the content configuration pass
Does a configuration pass run when the site gained in the update?
Yes. A gain is read the same way as a loss. The new queries show where the site is now placed, and the pass adds depth there before a competitor does.
How long does a configuration pass take?
The reading takes one working session per cluster group. The batch of changes is sized by the decisions, not by a time budget, and publishes on one day.
Is a configuration pass the same as a content refresh?
No. A refresh adds or updates text on a page chosen by age or traffic. A configuration pass changes structure on pages chosen by their cluster's ranking state, and leaves the text where the state held.
What happens to pages marked remove?
Removed pages are redirected to the URL that now owns their query, when one exists, and returned as gone when none does. The internal links that pointed to the removed page are updated in the same batch.
Does the pass need a topical map?
Yes, for the cluster column. A site without a map is clustered once from its URL structure and Search Console query overlap before the first pass, and that clustering becomes the first version of the map.
Can the pass run on Search Console data alone?
Yes, for the decisions. The crawl stats and index coverage reports add the access check, and an analytics property adds conversion per cluster, but the four decisions come from the performance data.
How many pages change in a typical pass?
A minority. Most clusters hold, and held clusters are not edited. A pass that changes most of the site is a rebuild wearing the wrong name.
Should the pass wait for a second core update before judging a change?
Yes, for the final judgment. Google states that recovery may not appear until the next core update. The pass records the expected metric and reads that metric at the next pass, and reverses the change only when two reads agree.
Who runs the configuration pass?
The person who owns the topical map, because the decisions change the map. A writer applies the changes to the pages; the map owner decides them.
Does a configuration pass change title tags?
Only when the heading order changed enough to move the main attribute. A title tag is changed with the H1 and the meta description together, never alone.
How is a configuration pass different from an SEO audit?
An audit is a one-time read of a site from the outside, covering access, structure and content together. A configuration pass is the recurring content part of that read, run from the inside on a schedule, with the previous pass's log as its starting point.
Read your clusters before the next update
On a 30-minute call we open your Search Console, group your pages into clusters, and show you which cluster gained, held or lost in the last core update. You leave with that reading with or without an engagement.
Book a strategy call · Request the audit
