---
title: 'We just redesigned our own website. Here is the SEO and AI-visibility plan we ran.'
url: 'https://mountainairweb.com/blog/we-redesigned-our-own-website'
markdown: 'https://mountainairweb.com/blog/we-redesigned-our-own-website.md'
date: '2026-10-18'
description: 'Short answer: a website redesign is an SEO risk even when the domain and most URLs stay put, because the things Google and the AI answer engines actually read (HTML, headings, schema, internal links) all change at once. We just did it to ourselves: the old Mountain Air Web site was a custom WordPre…'
taxonomy:
  category:
    - Migrations
  tag:
    - 'website redesign'
    - seo
    - 'case study'
---

[Migrations](https://mountainairweb.com/blog/category:Migrations) October 18, 2026 10 min read 

# We just redesigned our own website. Here is the SEO and AI-visibility plan we ran.

The top result for "website redesign SEO" is a Reddit thread asking for real accounts instead of checklists. This is one, from the inside, with the parts we got nervous about.

  Nicholas Murray Author  

**Short answer:** a website redesign is an SEO risk even when the domain and most URLs stay put, because the things Google and the AI answer engines actually read (HTML, headings, schema, internal links) all change at once. We just did it to ourselves: the old Mountain Air Web site was a custom WordPress theme we built; the new one is a flat-file Grav site on our own kit, with new positioning, a new services structure and a new journal. The plan was the one we run for clients, plus three additions that matter more every month: an explicit AI-crawler policy in `robots.txt`, an `llms.txt` pointing at a Markdown version of every page, and a way to measure which AI crawlers actually turn up. This is the story of that project, including the parts we cannot judge yet. The generic list lives in our [website migration SEO checklist](https://mountainairweb.com/blog/website-migration-seo-checklist) and the reasoning in [how to migrate a website without losing your rankings](https://mountainairweb.com/blog/migrate-a-website-without-losing-rankings); we will not repeat them here.

## What changed, and why we did it anyway

The honest reason for the rebuild was positioning. For years the site said "custom WordPress developer", which was true but attracted the wrong enquiries. The studio now works mostly for agencies and in-house marketing teams, and the work had spread well beyond WordPress: flat-file Grav builds, [MawGeo](https://mountainairweb.com/services/mawgeo) (our AI search visibility product), Granite (research-driven blog writing), AI integrations, migrations, care and hosting, and the Apex tools. The old site could not say that without rewriting every page, and rewriting every page on an old theme is the worst of both worlds.

So we changed the platform too. The old site ran on MawX, a custom WordPress theme we built ourselves. The new site is Grav 2.1, flat files, no database, on our own kit: block-based pages, a visual builder in the admin, content in git, and every page also served as Markdown by appending `.md` to the route. It runs on a small VPS behind Caddy with a PHP pool per site.

This is the riskier kind of project. Google has no rule that a revamped site must lose rankings; when a site owner reported three revamps that all tanked, John Mueller's answer was that it "sounds like maybe you're doing something unique with the revamp processes" ([Search Engine Journal](https://www.searchenginejournal.com/revamping-website-search-impact/413039/)). Reassuring and damning at once: the losses are self-inflicted, so they are avoidable, so there is no excuse. Google's guide to moving a site to new infrastructure says to expect "a temporary drop in Googlebot's crawl rate immediately after the launch" and to lower DNS TTL "at least a week in advance" ([Google Search Central](https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes)). For the AI side, Google states that "there are no additional requirements to appear in AI Overviews or AI Mode" and no special files or schema are needed ([Google](https://developers.google.com/search/docs/appearance/ai-features)), which we read as: the ordinary technical SEO has to survive the redesign, because no separate AI layer rescues you if it does not.

## What we did before touching DNS

The inventory and benchmark work is in the checklist; these are the decisions specific to this site.

**URLs.** The blog route stayed at `/blog`, and the post slugs that carried over kept their paths. The old portfolio lived at `/portfolio`; the new section is `/work`, so `/portfolio` is an alias of it. That section is currently unpublished while we wait for client approvals on the case studies: a short gap with no work section beats publishing work a client has not signed off. The old AI Content Program page is aliased to the new `/services/granite`, the same offer under its real name. The sitemap plugin excludes the utility pages. The thank-you page was noindexed first and then unpublished once we removed the forms (more below).

**Journal.** Fourteen posts at launch: seven that existed in spirit on the old site and were re-researched and rewritten, seven new. The listing is typographic with no images, with categories and a filter bar; every post opens with a "Short answer" paragraph, most carry a comparison table, and the cadence is one a week. Short answer first is deliberate: the paragraph a model is most likely to quote is the first one.

**Per-page descriptions and schema.** Every page has its own meta description. JSON-LD comes from a single template in the site layer rather than a plugin: Organization on the home page, Service on each service page, SoftwareApplication on MawGeo, FAQPage generated from any FAQ block, and BreadcrumbList everywhere. One template reading the page's own fields cannot drift out of sync with the visible text, which is the structured-data rule Google keeps repeating.

**Accessibility and performance.** Built to WCAG 2.2 AA from the start: keyboard-tested navigation with a proper close state, muted text lifted to AA contrast. No database and no plugin stack means most of the usual WordPress performance work does not exist. System fonts plus three web fonts, SVG logos, WebP backgrounds, and no forms: contact is a `mailto:` link and a booking embed. That last decision removed a form plugin, a spam problem, a thank-you page and a chunk of JavaScript in one go.

**`robots.txt` and `llms.txt`.** Written before launch, not on launch day. `robots.txt` explicitly allows GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, Claude-User, PerplexityBot, Perplexity-User and Google-Extended, with a comment explaining that every page has a Markdown version. `llms.txt` lists every page's `.md` route. The Google-Extended line is the one people ask about: Google's crawler documentation says it "does not impact a site's inclusion in Google Search nor is it used as a ranking signal", and it has no user agent of its own ([Google](https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers)), so allowing it is a statement about Gemini training and grounding, not about Search. We want to be cited; we allowed it.

### Old site vs new site

|  | Old site | New site |
|---|---|---|
| Platform | WordPress, custom theme (MawX) | Grav 2.1 on our own kit, block-based pages |
| Database | MySQL | None; content is Markdown in git |
| Pages served as Markdown | No | Every page, by appending `.md`; listed in `llms.txt` |
| Schema coverage | Patchy, not planned per page type | Organization, Service, SoftwareApplication, FAQPage, BreadcrumbList from one site-layer template |
| AI crawler policy | Default `robots.txt`, nothing said about AI agents | Nine AI agents explicitly allowed, including Google-Extended |
| Forms | Contact form with a thank-you page | None: `mailto:` and a booking embed |
| Fonts and assets | Theme-loaded fonts and image backgrounds | System fonts plus three web fonts, SVG logos, WebP backgrounds |
| Hosting | WordPress hosting behind the Cloudflare proxy | Small VPS, Caddy with on-demand TLS, one PHP pool per site, Cloudflare for DNS only |

## The AI-visibility layer

If you have read our piece on [writing an llms.txt](https://mountainairweb.com/blog/how-to-write-an-llms-txt), you know we think the file is cheap and mostly symbolic. We shipped one anyway, but the layer that matters is underneath it.

First, the Markdown routes. An answer engine fetching `/services/granite.md` gets the page with the chrome stripped: headings, paragraphs, tables, links, nothing else. `llms.txt` is just the index of those routes. A crawler that ignores the index (most do) still gets clean HTML with the content inside `<main>` and the navigation inside `<nav>`, which is what the Markdown output is derived from.

Second, the policy. Allowing an agent in `robots.txt` is not the same as being fetched by it, and being fetched is not the same as being cited. That gap is the reason MawGeo exists, and why we are using our own site as the first test subject rather than quoting a vendor benchmark.

## Launch day

The sequence was the one we use for clients, with one wrinkle.

1. **Preview hostname first.** The new site ran on a preview hostname on the VPS, with the admin account created there and every page checked at the real route and at `/<route>.md`.
2. **Pull before push.** Our deploy script pulls content from production back into git before each deploy, and a deploy guard refuses to overwrite production edits that are not in git. On a client site that protects their admin edits; on ours it protected the copy fixes made directly on the preview.
3. **Cloudflare proxy off.** The old site sat behind the Cloudflare proxy. For the switch we turned it off and used Cloudflare for DNS only: Caddy's on-demand TLS issues the certificate on the first real handshake, and we want the server logs to see real crawler IP addresses rather than Cloudflare's. A crawler log that shows every AI bot arriving from the same proxy range is useless to MawGeo.
4. **Canonical host unchanged.** The apex domain stays canonical with `www` redirecting to it, exactly as before. A redesign is not the moment to also change your host preference.
5. **DNS.** Then the record change, then the launch-day checks from the checklist.

The analytics tag went in **after** launch. GA4 is guarded so it loads only on the production hosts; local development and the preview hostname never register as visits. Launching without analytics for a few hours felt wrong and was fine; a tag that counted our own test traffic for a week would have been worse.

## What we will measure, and when

It is too early for ranking data and we will not pretend otherwise. Our own checklist sets a 90-day watch, so that is the window we are holding ourselves to:

- **Search Console, weekly:** page indexing, the old-versus-new sitemap crossover, and the top queries from the pre-launch baseline.
- **Server log, weekly:** which AI user agents fetched which pages, and whether they fetched the `.md` routes or only the HTML. This is MawGeo's crawler log, running against our own domain.
- **Referrer tracking:** click-throughs from ChatGPT, Perplexity, Claude and Google's AI surfaces, as distinct from ordinary organic.
- **Day 90:** the manual check. Ask the answer engines the questions we rank for and see whether the citations use the new pages.

We will publish the follow-up at 90 days with the numbers, including the ones that go the wrong way.

## What we would tell a client

1. **Separate the positioning change from the platform change in your head, even if you ship them together.** Rankings move because the content and structure changed, not because the CMS did. Know which decisions were which, so you can read Search Console honestly afterwards.
2. **Keep every URL you can and alias the ones you cannot.** We kept `/blog`, aliased `/portfolio` and the old program page, and that was the whole redirect story. The less heroic the redirect map, the better the launch.
3. **Write `robots.txt` and `llms.txt` as part of the build, with a decision per AI agent, and carry them to the new host unchanged.** A policy that silently reverts at launch is a bug.
4. **Put schema in one template that reads the page's own fields.** Plugin-generated schema is what most often vanishes in a redesign, and nobody checks until a rich result disappears.
5. **Decide what you will measure before launch, and give it 90 days.** The first week tells you whether something broke. Only the third month tells you whether the redesign worked.

## What to do next

If you are planning a redesign, the two posts linked at the top are the checklist and the reasoning; this one is the evidence that we follow them. If you would rather have someone look at your plan, or at a site that has already lost traffic after a relaunch, the [free site audit](https://mountainairweb.com/free-audit) runs it through Apex Scout and comes back with the three fixes that matter most, written by a person.

## More from the journal

 [See all posts](https://mountainairweb.com/blog) 

MigrationsSep 2, 2026

### The website migration SEO checklist: before, launch day, and the 90 days after

A working SEO website migration checklist in three phases: what to capture before the build, what to verify…

[The website migration SEO checklist: before, launch day, and the 90 days after](https://mountainairweb.com/blog/website-migration-seo-checklist)

MigrationsAug 12, 2026

### How to migrate a website without losing your rankings

Most migrations lose traffic for a few weeks. Some never get it back. The difference is a redirect…

[How to migrate a website without losing your rankings](https://mountainairweb.com/blog/migrate-a-website-without-losing-rankings)

Flat-fileOct 14, 2026

### Payload CMS vs Grav: when a marketing site needs a database, and when it doesn’t

Payload is the best code-first headless CMS and we run it for clients. For most marketing sites it…

[Payload CMS vs Grav: when a marketing site needs a database, and when it doesn’t](https://mountainairweb.com/blog/payload-cms-vs-grav)

---

## Navigation

- Parent: [Blog](https://mountainairweb.com/blog.md)
- Next: [Payload CMS vs Grav: when a marketing site needs a database, and when it doesn’t](https://mountainairweb.com/blog/payload-cms-vs-grav.md)