Home › SEO Guide › URLs, redirects and migrations without losses
URLs, redirects and migrations without losses
A page URL looks like a technical detail. In reality it is the only thing the outside world retains about your content: Google remembers it, other sites link to it, people bookmark it. Change it without leaving a trace and you erase, in one move, everything that has accumulated around it.
What a redirect is and why it matters
A redirect is an instruction the server gives instead of the requested page: what you are looking for has moved, here is where. It comes in two variants, and the difference between them is not cosmetic.
| Type | What it says | When to use it |
|---|---|---|
| 301, permanent | “Moved for good, forget the old address” | For any permanent change. Transfers the accumulated value to the new address |
| 302, temporary | “Moved for a while, but it will be back” | Maintenance, tests, promotions. Does not transfer the value, because Google waits for the return |
The frequent mistake is using a temporary redirect for a permanent move. The old address remains the one that is remembered, and the new one accumulates nothing, sometimes for years on end.
Case one: a line of code that hid 111 articles
On our own site, the blog listing pages each declared that they were in fact copies of the first page. The element that says “the official address of this content is this one” was generated by cutting off the part that indicates the page number:
real page: /blog/?page=2 it declared: /blog/ <- the address of page 1
The consequence is not obvious and it is severe. When a page declares itself a copy of another, Google devalues it, and along with it all the links on it. And the links on pages 2, 3 and 4 of the blog were the only path to most of the articles.
Out of 202 published articles, only about 47 were still one click away from the blog. 65 articles in Romanian and 46 in English sat in the “crawled, currently not indexed” state: Google had seen them, read them and decided they were not worth keeping. All of them were technically flawless.
The fix was a few lines: the declared address now includes the page number, but only that. Other parameters, such as campaign tracking ones, remain deliberately excluded; otherwise we would have ended up with dozens of official addresses for the same content, which is exactly the opposite problem.
Case two: a migration that shortened the URLs
During an earlier move, the URLs of several articles had been shortened. With good intentions, short URLs are easier to read. Except that no trace was left behind them.
old: /cum-utilizati-wordpress-rest-api-pentru-automatizare-si-integrari new: /cum-utilizati-wordpress-rest-api between: nothing
Every old link to those articles, from other sites or from Google results, led to an error page. We put in 15 permanent redirects, checking separately, for each one, that the destination actually responds.
A detail that is a matter of honesty: for one article that really no longer exists, we intentionally left the error in place. Redirecting it to something else would have been a false promise made to both the reader and the search engine. Roughly 18 of the addresses flagged as errors were in fact junk Google had picked up from old files, and those must remain errors.
Not every 404 error needs fixing. A page that no longer has a counterpart must say clearly that it no longer exists.
Automatically redirecting all errors to the homepage is one of the most widespread pieces of bad advice. It produces hundreds of pages that claim to be something they are not.
Case three: the site served from where it should not be
On classic hosting, email subdomains are often configured by default to serve the same site as the main domain. The result is a second address, one you did not create and nobody sees, that contains a complete copy of your site.
The problem becomes visible when the site's cache starts generating links based on that address. We have run into this case, and the fix was to explicitly force the correct address at the application level, so that no page can be generated from anything else.
How to move a site without losses
The order matters, and skipping a step is paid for a few months later.
- The complete inventory, before anything else. The list of all existing URLs, with the traffic of each. Without this list you have nothing to compare against afterwards.
- The old-to-new map. Every old URL gets a destination. Those that no longer have a counterpart are explicitly marked as gone, not pushed at random to the homepage.
- Redirects are prepared before launch, not after the drop is noticed.
- Checking the destinations, one by one. A redirect to a page that in turn does not respond is worse than no redirect at all.
- New sitemap, submitted immediately. You tell Google what exists now.
- Monitoring errors for a month. The URLs you did not foresee show up there, not in your plans.
It is worth saying what happens even when everything is done correctly: a temporary drop is normal. Google needs time to recrawl everything. What is not normal is a drop that does not recover after six to eight weeks.
Simple rules for URLs
- Short and readable.
/asigurare-locuinta, not/index.php?id=4127&cat=3. - No diacritics and no capital letters. They turn into unreadable code when copied.
- Words joined by hyphens, not underscores.
- No dates in the URL, if the article stays valid. A guide from 2024 looks old just because of its URL.
- Once set, it does not change. If it must be changed anyway, with a permanent redirect, on the same day.
What to check
- In Search Console, the indexing report, the errors section. How many are there, and are they real pages or junk?
- Type into the address bar an old URL of an article you know has been moved. Do you end up where you should?
- If you changed your site in the last two years, ask whoever built it whether the list of redirects exists. If it does not exist, they were probably never made.
- Check whether the site also responds on addresses other than the official one, such as the email subdomain.
- Before any future move, ask for the URL inventory and the old-to-new map. In writing, before launch.