How do you redesign an aviation website without losing your search visibility?
Short answer: Decide first whether your URLs will change. If they won't, the risk is small. If they will, map every old URL to a new one, use permanent server-side redirects, carry over the content that earns enquiries, remove launch-time blocks, and watch Search Console. Some fluctuation is normal, and no one can guarantee an outcome.
Does your redesign change your URLs?
This one question sets how risky the project is. Google has a separate guide for moving a site with URL changes and another for changing your hosting without changing URLs. Neither is about "redesigns" as such, so treat them as the closest official guidance.
For a charter operator, management company or FBO, a common version is a new look on the same domain, with page addresses such as /fleet/, /charter-quote/ or /bases/camarillo/ that the new platform names differently. Any change of address, even a small one, puts you in the first category. If you can keep the addresses identical, keep them. It removes most of the work below.
Step 1: Which pages bring you enquiries today?
Before anyone designs anything, list every URL on the current site. Include fleet pages, base-airport pages, quote and contact forms, old news posts and PDFs. Mark the pages that bring enquiries or that other sites link to. Google says it's important to map your old site's URLs to the URLs for the new site, and you can't map what you haven't listed.
Smaller sites can often do this in a spreadsheet. Google's Page indexing report in Search Console shows which pages Google has found and indexed, and that report also notes that sites with fewer than 500 pages probably don't need it, so a simple site: search can be enough to start.
Step 2: How do you redirect old URLs to new ones?
Google recommends server-side permanent redirects from the old URLs to the new URLs. Its redirects documentation says permanent redirects tell Google the new address should show in results, and that server-side redirects are the most reliable kind. It treats JavaScript redirects as a last resort when you can't use a server-side one.
Two details matter in practice:
- Use a 301 for permanent moves. Google's network and HTTP error documentation describes a 301 as a strong signal that the target should be the canonical page and a 302 as a weak one. Ask your developer which type each redirect is.
- Redirect each page to its closest match. Send an old fleet page to the new fleet page, not everything to the home page. For pages that no longer exist, Google says to return a real 404 or 410 rather than a normal page that says "not found", which it flags as a soft 404 (site-move guide).
Keep the redirects in place. Google's site-move guide says to keep them for as long as possible, generally at least one year. If you also change domains, the Change of Address tool is for moving from one domain or subdomain to another, and its page says to maintain redirects for at least 180 days. It is not for http-to-https, www changes or page moves inside one site.
Step 3: What should you carry over to the new site?
Redirects get visitors and Google to the right place. The page they land on still has to answer the same questions. Carry over the text that earns enquiries, not just the layout.
- Titles and headings. Google's title link guidance says to write a unique, descriptive title for each page and to avoid vague titles such as "Home". A template that gives every page the same title throws that away.
- Crawlable links. Google can only follow a link that is an
<a>element with anhref, according to its crawlable links guide. Menu items without a realhrefcan hide pages from it. - Content that Google can read. Google's JavaScript basics say pages that rely on JavaScript can wait in a rendering queue, and that server-side or pre-rendering is still a great idea. Ask a designer how your fleet and base pages will be delivered.
- Business facts and markup. Base airport, fleet, certificate and contact details should match the old site and your listings. If the old site had Organization structured data, keep it. Google lists no required properties and does not promise display, so it is a consistency step, not a lever. See schema.org's Organization type for the fields.
For a longer list of what an operator site should say, see our operator website checklist.
Step 4: What should you check before launch?
Staging sites are usually hidden on purpose, and that is where launches go wrong. Google's site-move guide says to remove any noindex or robots.txt blocks that were only needed for the migration. Two points from Google's own pages explain why both matter:
- robots.txt is not a mechanism for keeping a page out of Google. It manages crawler traffic.
- A noindex rule works only if the page is not blocked by robots.txt, and Google needs to recrawl the page to see a change. For less important pages that can take months.
So a block left on at launch can linger after you remove it, as Google's noindex documentation describes. Check the live site's robots.txt and page source on launch day, not after the first quiet week. If you keep your domain and hosting, Google's hosting guide also covers keeping your Search Console verification in the new copy and making sure a firewall isn't blocking Googlebot.
Step 5: What do you do after launch, and what is normal?
Submit the new sitemap in Search Console, as the site-move guide says. Treat a sitemap as a hint: Google's sitemap overview says it does not guarantee crawling or indexing. Make sure your internal links point at the new canonical addresses, since Google's duplicate URL guidance lists redirects and rel=canonical as strong signals and a sitemap as a weak one.
Then watch. Google says it can take a few weeks or more for it to start showing the new URLs, and that temporary fluctuation is expected. The Page indexing report lists "Page with redirect", "Not found (404)" and noindex statuses, and says validation of a fix typically takes up to about two weeks. Google gives no figure for how much traffic a redesign costs, so be wary of anyone who does.
If your site publishes updates often, IndexNow lets you tell participating search engines about added, updated or deleted URLs. A successful response only means the engine received your URL, not that it indexed it.
What should you ask a website designer?
These questions work whoever you hire. They don't depend on a promise about results:
- Will any URLs change? If so, can I see the old-to-new map before launch?
- Which redirects are 301s, and how long will they stay in place?
- How will titles, headings and structured data carry over?
- How are pages delivered to crawlers, and are menu links real links?
- Who checks robots.txt and noindex on launch day, and who watches Search Console afterward?
Sightline Aviation builds websites plus search and AI-answer visibility for charter operators, aircraft management companies and aviation businesses, and we don't guarantee rankings or AI mentions. If you're planning a redesign, you can read about our aviation SEO work or book a 20-minute call.
Frequently asked questions
Will a redesign hurt my Google rankings?
It can cause temporary fluctuation, and Google says it can take a few weeks or more to show new URLs after a move (Google's site-move guide). Keeping URLs, redirecting changed ones one-to-one and avoiding leftover blocks reduces avoidable problems. No one can promise a result.
How long should I keep redirects after a redesign?
Google's site-move guide says to keep redirects as long as possible, generally at least one year. Its Change of Address page gives at least 180 days for a domain move (Google's Change of Address help). The longer figure is the safer plan.
Do I need the Change of Address tool?
Only if you move to a different domain or subdomain. Google's help page says it isn't for http-to-https, www changes or page moves within a site (Change of Address help).
Want to see how your operation shows up?
On a 20-minute call we'll run a few of your customers' questions and look at the results together.
