Job seo-redirects-canonicals-sitemap-fix · revised 11 October 2026
Make one site's old and new URLs resolve cleanly: redirects, canonicals and sitemap
Up to 300 agreed URLs on one site each return the right status, one permanent redirect at most, a matching canonical tag and a correct sitemap entry, checked with a repeatable test sheet.
You might be seeing
- Old links and bookmarks return 404 or land on the home page
- A search report shows pages as duplicates, blocked or redirected when they should be indexed
- The sitemap contains addresses that redirect, are blocked or return an error
No passwords, keys, card details or admin invites needed to start.
What usually happened
The addresses people and search engines already know do not map cleanly to the addresses the site now uses. Redirects are missing, chained or temporary where they should be permanent, canonical tags disagree with the sitemap and redirects, or robots rules block pages that should be crawled. The job builds one agreed map of old to new addresses and makes redirects, canonicals, sitemap and crawl rules agree with it.
Who it’s for: A site owner or agency whose site changed address structure (a redesign, a move to a new platform, a new domain) or whose search reports show pages missing, duplicated or listed with the wrong address, and who needs a bounded, testable fix.
Usually starts when: Old pages return 404 or loop, redirects chain through several hops, the sitemap lists addresses that redirect or are blocked, or canonical tags point somewhere unexpected, usually shortly after a relaunch.
The result: Every address on an agreed list of up to 300 URLs returns the expected status in a repeatable test: old addresses make one permanent redirect to the right new page, new pages carry one self-referencing canonical tag, and the sitemap lists only the indexable, successful, canonical addresses. You receive the map, the rules and the test sheet.
Check whether this job fits
These questions check whether one agreed map and test list is possible. They need no access or code.
Checks you can run yourself
Test five old addresses by hand
Choose five old addresses that people used (home, two key pages, one deep page, one with a trailing slash). Open each in a browser and note where you end up. In the browser's developer tools Network tab, note the status code of each hop.
Look for: Which ones end on a 404, which land on a general page, which pass through more than one redirect, and whether the codes are permanent (301 or 308) or temporary (302 or 307).
What you get
- The old-to-new map, with a destination or a reason for each address
- The redirect rules and the code or template changes for canonicals, sitemap and robots, as a pull request or a ready-to-apply file
- A test sheet with status, final address, hop count, canonical and sitemap result for each URL before and after
- Reversal steps and any limits found
Included
- One site on one primary domain, up to 300 agreed URLs, taken from your sitemap, a crawl list and any list of old addresses you hold
- Build the old-to-new map with you, deciding for each old address its one right destination, a deliberate 404 or 410, or a merge
- Write the redirect rules in the form your hosting uses, avoiding chains and loops, with permanent redirects for moved pages
- Make canonical tags absolute and self-referencing on the pages in the list, and correct those that disagree
- Correct the sitemap so it lists only successful, canonical, indexable addresses, and check that robots rules do not block them
- Run the whole list before and after and record the results in a test sheet
Not included
- A guaranteed ranking, traffic or indexing outcome, or a prediction of recovered traffic
- Content rewriting, keyword research, link building or page-by-page SEO copy
- More than 300 addresses, several domains or language versions with separate maps
- Changing the domain's DNS, the hosting or the content network, which stay with your team
- Search console submissions or account access: you submit, we give you what to submit
- Production deployment, which stays with your team
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each old address on the agreed list returns a permanent redirect (301 or 308) in one hop to its agreed destination, which returns 200, or returns the agreed 404 or 410, with no chain or loop.
Evidence: The test sheet row for each address with status, hop count and final address, before and after.
Each indexable page on the list carries exactly one canonical tag with an absolute address that points to itself, or to the agreed destination where it is deliberately a duplicate.
Evidence: The test sheet canonical column for each page and a note for each deliberate exception.
The sitemap lists every indexable canonical address on the list and none that redirect, return an error, carry noindex or are blocked by robots rules.
Evidence: The sitemap comparison against the test sheet and the robots rule check.
A sample of ten addresses outside the list still returns its previous status, and the diff or rule file contains no secret.
Evidence: The sample results, the changed-file list and a secret scan.
Sign-off. You or your authorised maintainer review the test sheet, open a sample of addresses yourself, sign off in writing and apply the change. Payment follows sign-off. Search results change over weeks and are not a condition of payment.
If it fails. If the agreed test sheet does not pass, you do not pay for this fixed scope. If the platform cannot do what the map needs or the list was incomplete in a way that changes the scope, we explain what we found and stop. Wider work needs a new written agreement.
When it fits, and when we stop
It fits when
- You can give us a list of old addresses, or a crawl or sitemap export, and agree the new destinations
- Redirect rules and templates can be changed through code or settings you or your host control
- The new site is live or on a staging address that serves the same pages
- An authorised maintainer on your side reviews and applies the change
We stop and tell you if
- No one can say which new page replaces most of the old ones, so the map cannot be agreed
- The platform cannot return permanent redirects or cannot be edited
- The list is far larger than 300 addresses, so a larger scope or a rule-based approach is quoted instead
- The real problem is thin or removed content rather than addresses
What could go wrong
Before applying, nothing changes. After applying, your team can remove the redirect rules and restore the previous template and sitemap files, which we hand over unchanged for that purpose. Permanent redirects that search engines have already seen can take time to settle after reversal.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Old addresses are redirected to an unrelated page, such as the home page, to avoid 404s. | Each address gets a specific destination or a deliberate 404 or 410, and the reviewer checks the unrelated-destination count. |
| A redirect rule affects more addresses than intended. | The test sheet covers the whole list and a sample of addresses outside it, and every rule is tested before and after. |
| The map misses addresses nobody remembered. | We state that the map is only as complete as the list and suggest further sources, such as analytics landing pages, before sign-off. |
An independent reviewer repeats a sample of the address tests, checks that no old address is sent to an unrelated page and that no rule loops. You decide each ambiguous destination.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Google's site-move guidance explains how to map old addresses one to one, why to avoid chains and how long to keep redirects. A developer can follow it for a small site. developers.google.com
- Google's guidance on canonical addresses explains which signals matter and how to keep them consistent. developers.google.com
Questions
Will my rankings come back?
We make no promise. The job makes your addresses resolve cleanly and consistently; search results change over weeks for many reasons.
Can I redirect everything old to the home page?
We advise against it. Google says redirecting many old addresses to one irrelevant page can confuse users and may be treated as a soft 404. Each address gets a specific destination or a deliberate 404 or 410.
Do you need access to my search account?
No. We give you the files and what to submit, and you do it.
What if I have thousands of addresses?
A larger site needs a rule-based approach and a bigger test plan. We would quote that as a project.
Send an enquiry
Send us
- The site address, the platform it is built on and what changed (redesign, new platform, new domain)
- How many addresses are affected, roughly, and where a list of old ones could come from
- Any search report messages you have seen, copied as text
- Do not send login details, source code, an access invitation or customer data in the first enquiry
Later, once you agree
- The old-address list, a crawl or sitemap export and any analytics list of top landing pages, with personal data removed
- The redirect and template files through an agreed company-controlled route, with a branch for the pull request, or a description of the host's redirect settings
- Your decisions on the destination of each ambiguous address
- The name of the person who reviews and applies the change
You own the site, domain, hosting and search accounts. We work on a branch or staging copy through a company-controlled identity, never a personal login. We never hold your search account login. Your team applies redirect rules to production and submits the sitemap.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “seo-redirects-canonicals-sitemap-fix” as the subject.