WEBSITE RENEWAL
The accident that happens most often in a rebuild is not a design failure but the loss of accumulated search assets. We settle the list of indexed URLs, traffic-earning pages and externally linked addresses first, pin them down as protected, and only then touch the site.
In one paragraph
The accident that commonly occurs in a website rebuild is losing the search performance built up until then. Before screen composition, we settle a list of the currently indexed URLs, the pages earning traffic and the addresses linked from outside, fix that list as protected, and only then touch the site. Addresses that work stay as they are; only addresses that must move get a one-to-one 301, and we never build chains where a redirect leads to another redirect.
The test is not "does it look better" but "is the gain from moving larger than what is lost". Tidying a path string does not itself produce ranking or citation, so a move whose gain cannot be explained is safer left undone. We declined a URL-move proposal on our own site for exactly this reason, and the reasoning is published on this page.
Last verified
WHEN YOU NEED THIS
These are the situations we hear repeatedly in consultations. If any of them apply, start by measuring.
When the whole URL scheme changed with no map between old and new addresses, a search engine treats the existing pages as gone. The pages are still there while only the indexing disappears, so looking at the screen shows nothing.
Rebuild the information architecture without an asset list and the pages generating most of the traffic quietly disappear. Recording index status, traffic-earning pages and external links before starting is what makes it possible to decide what to protect.
If the cause lies in the rendering method or the URL structure, partial edits do not solve it; conversely, if the problem is information architecture and document form, a rebuild only raises the cost. The prescriptions differ, so we judge the scope first.
For a document already earning traffic and citations, the sentences themselves are the asset. A rebuild should not be tearing up documents with existing performance but layering a direct-answer structure on top of the body that stays.
WHAT WE DO
Written as units of work rather than abstract proposals. The scope of an engagement is set from this list.
Before touching anything, we count what exists now. Index status, traffic-earning pages and external links cannot be re-established after a rebuild, so they are recorded before starting.
Every URL is judged as keep, move, consolidate or delete. Fixing the judgement table in writing before starting removes improvised URL changes mid-project.
We write down the conditions calling for a rebuild and the conditions where partial improvement suffices. The test is not preference but how the current structure looks to search engines and answer engines.
Articles with existing performance do not get rewritten wholesale. The body stays and only the structure changes, pulling the answer to the question forward.
A rebuild is the moment structured data and crawler policy break most often. We realign the machine-readable layer with the same weight as moving the screen.
Launch is not the end but the start of verification. We check item by item what the old addresses actually respond with, and whether indexing moves to the new addresses.
PROCESS
What you receive at each stage is stated alongside it. Durations are the working time Navirang controls; they are not a promise about when results appear.
We record indexed URLs, traffic-earning pages, externally linked addresses and the current technical settings. It goes first because these values cannot be recovered after the rebuild.
Current asset list
We check the rendering method, URL structure and CMS constraints, and decide with reasons whether a full rebuild or partial improvement fits.
Rebuild scope definition
Each URL is judged keep, move, consolidate or delete, and the one-to-one mapping table is built. Structured data, robots and sitemap requirements get fixed in writing at this stage too.
URL mapping table · technical requirements
The new site goes live and redirects are applied. Immediately after launch we check the response code of every item in the mapping table, and anything that disagrees is handled the same day.
Redirects applied · switch-day check results
Canonicals, sitemap, robots, structured data, 404s and index status get checked repeatedly against the same items. We look at the pre-switch top traffic pages individually rather than the aggregate.
Migration checklist · index resubmission record
DELIVERABLES
We do not do work that ends in conversation. The documents below remain, and become the baseline for the next measurement.
Indexed URLs, traffic-earning pages, external links and technical settings as of before starting. It becomes the baseline for every later comparison, so the client keeps it.
Which of full rebuild or partial improvement was chosen and the observations that decided it. The areas deliberately left untouched are stated too.
The keep, move, consolidate or delete judgement per URL and the one-to-one correspondence for moves. Final destinations are specified directly so no redirect chain forms.
Canonicals, sitemap, robots, structured data, redirect responses, 404s and index resubmission, each marked pass or fail.
The same items measured again by the same method. You get page-level observations alongside the summary figures.
That last principle is a standard we actually applied to our own site. In August 2026 an outside proposal suggested moving the URLs of five insight articles onto a series path, and we did not move them, because Naver was collecting those URLs for the first time at that moment — sequence information is carried by the index page and CollectionPage structured data, not by the path string.
HOW IT CONNECTS
Our work moves as one piece. SEO builds the foundation for being found by search engines, AEO raises the odds of that information being cited in an answer, structured data helps machines understand the facts, and content supplies the evidence there is to cite.
| Area | Relationship to this work |
|---|---|
| AEO website build | Where you go when there is little to preserve or a rebuild is judged right |
| AI crawler optimization | Securing that answer engines can actually read the newly built site |
| Indexing | Sitemap resubmission and index status checks after migration |
| Technical SEO | The foundation that decides migration quality — URL format, canonicals, rendering |
| AEO audit | Recording the answer engine citation baseline before the rebuild |
| Pricing | Where the quote changes with the rebuild scope |
FAQ
A It can wobble immediately after the switch, because a search engine has to re-read the changed addresses and the new HTML, and recrawl intervals differ per page. So rather than judging by instinct we look at four things: the trend in indexed URL counts, whether moved addresses reach their final destination in a single 301, whether new 404s appeared, and the individual trends of the top traffic pages before the switch. Looking only at the overall total tells you nothing about which page something happened to.
A It gets decided after comparing gain against loss. A path string does not itself produce ranking or citation, so we do not recommend moving addresses that have accumulated indexing and external links merely because it would look tidier. Where there is a clear reason to move, we connect one-to-one with a 301 and do not build a chain where the old address passes through another redirect first.
A By how the current structure looks to search engines and answer engines. If body text appears only after JavaScript executes, or one document opens at several URLs, or the CMS blocks redirects and schema insertion, partial edits will not solve it and a rebuild is right. If instead the problem is document form and information architecture, fixing on top of the existing site loses fewer assets.
A No. For an article already earning traffic or citations, the sentences themselves are the asset, so the body stays and we add a direct-answer paragraph at the top and tidy only the structure — subheadings, tables, FAQs. Rewrite it wholesale and the sentences a search engine was referring to disappear, taking the basis of the existing performance with them.
A Same principles, with extra procedure. Every URL is 301'd one-to-one, the address change is declared in the search consoles, and the old domain and its redirects are kept in place for a long time. The @id and sameAs in structured data, and the addresses written across every channel, also have to be aligned to the new domain so answer engines do not read the two domains as separate entities.
A It is better to do the measurement first and attach the improvement after the switch. Recording current citation status across the answer engines before starting the rebuild makes it possible to separate whether a post-switch change came from the site overhaul or from the content. Run both at once and there is no way to separate what moved what afterwards.
Indexed URLs, traffic-earning pages and external links cannot be re-established after the site changes. Send us a URL and we will record the current assets and citation status first.
We reply within one business day.