Relaunching your Korean site without throwing away the search traffic

✦The call always comes after launch

Two or three weeks after a new site goes live, the message arrives. We are not showing up in search anymore. The design is much better and the people who used to visit are gone.

I talked this through with Jaeseung Pi in the second episode of my podcast, and he sees the same pattern on repeat. It would help if the call came before the relaunch. It almost always comes after something has broken.

One thing first. Relaunching is not inherently dangerous. Follow the order and rankings generally come back. The problem is that nobody writes the order into the brief.

✦A relaunch changes addresses, not design

What Google knows about your site is, in the end, a list of addresses. Which address holds which content, which address earned links from elsewhere, which address performed well for which query. That record accumulates per URL.

A relaunch replaces those addresses wholesale. /product/123 becomes /products/new-item and ?id=45 disappears. To Google the new address is a page that was born this morning. The years of history sit on the old address, and if that address returns a 404, the history goes with it.

Which is why failed relaunches nearly always have the same cause. The redirects were missing. Nobody built the bridge from the old addresses to the new ones.

301 and other permanent redirects do not cause a loss of PageRank.

That is Google's sentence, from its documentation on site moves. Turned around, it means there is nothing to lose if you set them properly. The loss happens when you do not.

For a company launching in Korea this often shows up in an unfamiliar shape. The Korean site is not a relaunch of anything, so the risk seems not to apply. It applies the moment you replace an agency built microsite, fold a campaign domain into the main site, or move from a hosted Korean builder onto your global platform. All three are address changes.

✦The order Google recommends

The same document lays out a site move in five steps. Copied across, they are these.

Google attaches two conditions. The first is to change one thing at a time. If you are moving domains, switching CMS, and redesigning the layout, do not do all three on the same day. The second is to pick a low traffic period, so that fewer people are affected if something breaks and there is server capacity left for crawling.

These two are the first to go in practice. A relaunch usually begins as let us replace everything this time, and the launch date usually lands right before the busy season.

✦Eight lines for the brief

The cheapest thing a client can do is write the following into the brief and the deliverables list. Requested after development finishes, each one becomes a change order. Written into the scope at the start, it is simply part of the job.

• A full list of existing URLs mapped to new ones

  Put it in the deliverables. Pull it from the sitemap and analytics, highest traffic first. Without this table there is no basis for setting redirects at all.

• 301 redirects named explicitly in the development scope

  Not a vague line about handling old addresses. State how many and by what rules. Google has confirmed that a 301 does not cost you PageRank, which means a proper setup loses nothing.

• A procedure for lifting the development blocks

  Staging sites are usually blocked in robots.txt and carry noindex. Write down who removes them at launch and when. Forgetting this is the most common way to lose several weeks.

• Removed pages return 404 or 410

  Throwing everything at the homepage makes the whole site look odd to Google. Send visitors to a replacement if one exists, and answer honestly that the page is gone if it does not.

• Images and PDFs migrated and redirected

  Product catalogs and images already attract search traffic of their own. Teams often cover HTML pages and forget the files.

• Search Console verification still valid on the new site

  If you verified with an HTML file or a meta tag, it has to travel to the new build. This keeps you from losing sight of your data on launch day.

• Titles, descriptions, and structured data carried over

  Sometimes only the design moves and this gets rewritten from scratch. Replacing the titles of pages that were performing well moves the rankings with them.

• Domain change and design change on different days

  Google recommends this directly. Changing one thing at a time is what lets you find the cause when something goes wrong.

Eight lines. Jaeseung Pi puts the cost of skipping them in plain arithmetic. A site that took six months to a year to plan and build, then has to be fixed again for SEO reasons, spends that period a second time.

✦Five things to watch for two weeks

Launching is not the end of it. Google needs time to work through the new addresses, so watching this window is what catches problems early.

On recovery speed, Google's guidance is that for a medium sized site most pages move across within a few weeks, and larger sites take longer. Do not decide to roll back three days after launch because rankings are moving. Moving is the normal part.

✦When traffic holds but revenue does not

Everything above is about not losing. The second episode has another stretch in it, about ranking first and still not converting.

Raising rankings is a reasonably well defined job. The hard part comes after. Why does someone leave, and is that a copy problem, a price problem, or a problem with the product itself. The very next segment in that episode is titled, in the end it turned out to be the product.

Relaunches work the same way. If you moved the addresses cleanly, held the traffic, and revenue did not move, then traffic was never the constraint. So put one question in the brief. What has to improve for this relaunch to count as a success. If the only answer is that it will look better, the effort of protecting your search assets is hard to justify too.

The mismatch between what people search for and what you sell is something I wrote about from the keyword side in the note on long tail keywords. If you have not commissioned the work yet, the note on choosing an agency pairs with this one.

✦One line on the first page

The most reliable fix is simple. Put an SEO review into the schedule at the planning stage. Before the design is signed off, before development starts, two weeks before launch. Three passes is enough.

That one line removes the months of rework that follow a bad relaunch. And if the build is already underway it is not too late. Anything caught before development ends is still cheap to fix.

How I work is on the services page, and the rest of the conversations are in the episode list.

✦Common questions