How do I do an SEO-friendly migration from an old domain to a new domain?

Short answer

The old domain name continues to point to the IP of the vService in DNS, and the certificate of the old name continues to stay in the Certificate field of the vService; the Location Redirection action redirects every request arriving with the old name (HTTP Header Host) with the 301 code to the same path on the new domain name. The new domain name and the Path + query of the request variable are written in Redirect Location; this way, each page goes to its own counterpart. If the URL structure has also changed, page-based redirects are placed above the general domain name rule in the Actions list.

Problem: Search Rankings Can Be Lost When the Domain Name Changes

When an organization moves to a new domain name, the links given to the old address, bookmarks and search engine records continue to point to the old name. For the ranking and the traffic to be carried over to the new address, each old page is redirected permanently (301) to its counterpart on the new domain name; sending all the old addresses to the home page loses the page-level value.

Solution: Four Methods

Whichever method is chosen, the following prerequisites are maintained throughout the migration: the old name and its www form point to the IP of the vService in DNS; for old links that come in over HTTPS, a certificate covering the old names is present in the Certificate field of the vService (if not, it is uploaded first: How do I upload my certificate to TR7; which formats are supported?); for old http:// links, the vService has a frontend row with port 80.

Your situation	Suitable method
The URL structure is the same; only the domain name changed	Method 1: Single rule, keep the path
The URL structure also changed	Method 2: Page-based redirects + general rule
The old name will be served on a separate vService	Method 3: Separate vService + Always
From the command line	Method 4: WEB-CLI

Method 1: Single Rule: Change the Domain Name, Keep the Path Recommended

• How it works Every request arriving with the old name goes to the new domain name with the same path and query via 301; a request arriving over HTTP also reaches the https:// destination with a single response.
• Where it is openedLoad Balancer → Conditions · Load Balancer → Actions · vService → Details → Actions
• Requirement The old name points to the IP of the vService in DNS; the certificate of the old name is on the vService
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the condition form

Load Balancer → Conditions → Add is clicked (how to add).

2

Adım 2 Define the old name condition

Criteria = HTTP Header, Header Name = Request Host, Exact match, Case Insensitive checked, value eski.com.

3

Adım 3 Save the condition

Add is clicked. Steps 1–3 are repeated for www.eski.com.

4

Adım 4 Open the action form

Load Balancer → Actions → Add is clicked.

5

Adım 5 Enter the action name and type

Action Name is entered, and Action Type = Location Redirection is selected.

6

Adım 6 Enter the target and the conditions

Redirect Code = 301: Moved Permanently (308 if the POST needs to be carried over with its method); Redirect Location = https://www.yeni.com, followed by Path + query of the request with fx; in the Conditions field, the two conditions are selected and the operator between them is set to or. For monitoring, Hit Counter is turned on.

7

Adım 7 Save the action

Add is clicked.

8

Adım 8 Edit the vService

On the Load Balancer → Load Balancer vService List screen, the HTTP vService that serves the old name is selected and Edit is clicked.

9

Adım 9 Add the action to the Actions field

The action is selected in the Details → Actions field.

10

Adım 10 Save

Save is clicked. The change is applied without dropping open connections; in a cluster, it is also sent to the peer device with the default auto-sync (if Manual Sync Mode is on, with Synchronize).

Verification

1Four variantsClient side

curl -sI "http://eski.com/urun/5?x=1"; the same is repeated for https://eski.com, http://www.eski.com and https://www.eski.com.

ExpectedA single 301 for each + Location: https://www.yeni.com/urun/5?x=1

2Monitoring the migrationTR7 side

The rate of the action is monitored on the Action Hits tab of the vService dashboard; as search engines index the new addresses, the requests arriving at the old name decrease.

ExpectedThe number of redirects drops over time

Method 2: Page-Based Redirects + General Rule

• How it works Separate redirects are defined for the pages whose path changed and are placed above the general domain name rule in the Actions list; the actions are processed from top to bottom, and the first redirect that is triggered ends the request.
• Where it is opened vService → Details → Actions (order)
• Requirement The general rule in Method 1
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Create the page-based redirects

For each page whose path changed, a Location redirection that works with the old name condition and a Path condition is defined; for a large number of pages, a single action with the Mapping function is defined instead (How do I redirect a specific URL to another URL with a 301/302?). The destinations are written as full addresses in the form https://www.yeni.com/….

2

Adım 2 Edit the vService

The vService is opened with Edit, and the Details → Actions field is displayed.

3

Adım 3 Reorder

The cards of the page-based actions are dragged above the general domain name rule (In what order do Actions run; how do I change the order?).

4

Adım 4 Save

Save is clicked.

Verification

1ResponseClient side

A page whose structure changed (curl -sI https://eski.com/urun.php?id=5) and a page whose structure did not change are tried.

ExpectedCustom destination (https://www.yeni.com/urunler/5) · the others to the same path

Method 3: Separate vService + Always

• How it works The old name is moved, with Virtual Hosting, to a separate vService that shares the same IP and port; all requests arriving at this vService are redirected to the new domain name with the ready-made Always condition.
• Where it is opened vService → Virtual Hosting · Load Balancer → Actions
• Requirement The Virtual hosting list is filled in on all vServices that share the same IP and port
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Edit the existing vService

The existing vService that uses the same IP and port is opened with Edit.

2

Adım 2 Fill in Virtual hosting on the existing vService

Only the new names are written in the Virtual Hosting list (Can I publish more than one website behind a single public IP?).

3

Adım 3 Save the existing vService

Save is clicked.

4

Adım 4 Open the action form

Load Balancer → Actions → Add is clicked.

5

Adım 5 Define the redirect action

Action Name is entered, and Action Type = Location Redirection is selected; Redirect Code = 301: Moved Permanently, Redirect Location = https://www.yeni.com + Path + query of the request, Conditions = the ready-made Always condition.

6

Adım 6 Save the action

Add is clicked.

7

Adım 7 Open the vService form for the old name

Load Balancer → Load Balancer vService List → Add is clicked; the HTTP vService form opens (how to add).

8

Adım 8 Define the vService

The following are set: in the frontend row, the same IP and port as the existing vService and a protocol in the same encryption class; in the Certificate field, the certificate of the old names; in the Virtual Hosting list, eski.com and www.eski.com; in the Details → Actions field, the action from step 5.

9

Adım 9 Save the new vService

Save is clicked.

Verification

1ResponseClient side

curl -sI https://www.eski.com/hakkimizda

Expected301 + Location: https://www.yeni.com/hakkimizda

Method 4: WEB-CLI

• How it works The old names are captured with a regex in a single URL condition; the Location redirection action and the vService binding are created with WEB-CLI commands.
• Where it is opened TR7 WEB-CLI → lb condition · lb action · lb service
• Requirement WEB-CLI access; the condition ID
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Add the condition that captures the old names

The value of the URL condition is in the form https://eski.com/urun/5?x=1 (scheme, Host and path together). The pattern captures both the eski.com and the www.eski.com name, and both HTTP and HTTPS:

lb condition add criteria url query "^https?://(www\.)?eski\.com/" --content_placement regex --caseInsensitive true --name eski-alan

URL	Result
http://eski.com/urun/5?x=1, https://www.eski.com/a, HTTPS://WWW.ESKI.COM/A	Matches
https://eski.com.tr/a, https://www.eski.community/, https://api.eski.com/a, https://www.yeni.com/a	Does not match
https://eski.com:8443/a	Does not match (on a non-standard port, Host also carries the port)

2

Adım 2 Get the condition ID

The action binds the condition by its ID, not by its name. lb condition add gives no output when it succeeds; the ID is seen in the id column of the condition list:

lb condition list

3

Adım 3 Add the redirect action

%PATHQ is the Path + query of the request variable; --redirectCode is always written (if it is not written, the command line default of 300 is saved):

lb action add type req_redirect_location name eski-alandan-yeniye redirectLoc "https://www.yeni.com%PATHQ" --redirectCode 301 --cond <condition-id>

4

Adım 4 Check the existing actions on the vService

lb service show <vService>

The rules.0, rules.1 … lines in the output show the actions on the vService in order. --rules.N replaces the action at that position; the new action is written to the first empty position.

5

Adım 5 Add the action to the vService

If the vService has two actions (0 and 1), the new action is written to position 2; if it has no actions, --rules.0 is used:

lb service update id <vService> --rules.2 eski-alandan-yeniye

Verification

1ResponseClient side

curl -sI "http://www.eski.com/urun/5?x=1"

Expected301 + Location: https://www.yeni.com/urun/5?x=1

Common Mistakes

• Using 302. A temporary redirect does not tell search engines to carry over the ranking; for a permanent migration, 301 (308 if POST is to be preserved) is selected.
• Redirecting everything to the home page. If Path + query of the request is not added, the counterparts of the pages are lost and search engines may treat the old pages as "not found".
• Removing the old certificate early. Old links that come in over HTTPS complete the TLS handshake before receiving the redirect; the certificate of the old names stays on the vService throughout the migration.
• Setting up a redirect chain. Instead of steps such as http://eski.com → https://eski.com → https://www.yeni.com, the destination is written directly as https://www.yeni.com; since Location redirection is evaluated before the HTTP → HTTPS redirect in the frontend row, the client receives a single response.
• Writing a broad condition while the new name is on the same vService. A condition such as Host Includes .com also captures the name yeni.com, and a loop occurs; Exact match is used.
• Turning off the redirect early. For search engines and old links, the redirect is kept on for a long time (usually at least one year); the traffic arriving at the old name is monitored with Action Hits.

How it is done in the documentation

• Location Redirection · Scenario 6: Transition from the Old Subdomain to the New Subdomain
• Location Redirection · Redirect Code
• HTTP vService · Certificate
• URL condition · URL Structure

Related questions

• How do I redirect a specific URL to another URL with a 301/302?
• How do I set up a redirect that adds or removes www?
• In what order do Actions run; how do I change the order?
• After switching to HTTPS, pages show a "mixed content" warning; how do I fix it?