What I check before calling a site search-ready

When I rebuilt Transit Education from WordPress to Next.js, I caught titles that repeated the brand name and a sitemap that had lost pages. Neither problem looked dramatic. Both changed what I meant by finished.

I added a small script to check the SEO basics on a running build. The list below grows out of that work. Some items describe what I implemented at Transit; others describe how I would review a site before handing it over. It is a readiness checklist, not a promise of indexing, rankings or AI citations.

Old addresses must land somewhere sensible

My first pass is through the routes people might already have. Transit’s old WordPress links now go to their new pages in a single hop. I want to open the old address and see the intended destination, not just find a redirect rule in a configuration file.

Google’s migration guidance recommends redirecting to the final destination directly and warns against sending unrelated old URLs to the homepage. It also says removed content that is not being moved should return an appropriate missing-page response. That is more precise than making every old URL appear to work (Google Search Central, Site moves, 2026).

I would keep a small mapping of representative old and new URLs, including country guides and posts, and inspect the responses after a release. If the content has genuinely gone away, I would make that explicit rather than use the homepage as a place to hide the decision.

I also chose one canonical host for Transit. In a review, I would compare the preferred address, canonical tags, internal links and sitemap entries. Google treats redirects and canonical annotations as strong canonicalisation signals, while sitemap inclusion is weaker; they are signals, not instructions it must accept (Google Search Central, Canonicals, 2026).

Crawling and indexing are separate checks

I would read the production robots.txt, not the version I remember writing. Then I would inspect the actual page response for indexing restrictions. Google describes robots.txt as a way to control crawler access, not a reliable way to keep a URL out of search; blocking indexing and requiring authentication are different mechanisms (Google Search Central, Robots, 2025).

That separation gives me a useful review question: am I trying to prevent a fetch, prevent indexing, or protect something private? I would not use one setting as a substitute for all three. I would check the intended behaviour explicitly and record anything still uncertain.

For AI search, I would add a provider-specific access check rather than a blanket instruction to allow every bot. OpenAI’s search and training permissions are independent, and Perplexity documents separate crawler and user-request behaviour. I would review those rules with whoever owns the site before changing them (OpenAI, n.d.; Perplexity, n.d.).

Generated files must agree with the site

Transit generates its sitemap, robots file, RSS feed and llms.txt from live content. My check is not simply that those URLs return something. I want the relevant files to contain the pages I expect and point to the preferred host. The missing sitemap pages I found are the reason I make that distinction.

Google says a sitemap helps it discover URLs but does not guarantee that they will be crawled or indexed. I therefore treat it as a discovery aid and compare it with navigation and published content, not as a certificate that search is working (Google Search Central, Sitemaps, 2025).

I would sample a newly published post, an older post and a country guide. I would check that each intended public page has a sensible title, that its canonical address agrees with the site, and that the generated references have not silently dropped it. Those are the kinds of disagreements I want the script to catch.

I would keep the sample small enough to understand. A report that nobody reads is not a safeguard just because it has many rows.

Structured data must describe the visible page

At Transit, country guides carry structured FAQs and each blog post has one clean set of structured data. I prefer one clear owner for that output, rather than several templates each adding a slightly different description of the same post.

That is a maintenance decision, not a Google rule that every page may have only one script. Google supports multiple relevant items, but requires the markup to reflect visible, accurate content. I would validate the output and then read the page beside it. Passing a syntax check is not enough (Google Search Central, Structured data, 2026).

There is a date-sensitive limit here too. Google’s May 2026 documentation update says FAQ rich results stopped appearing from 7 May 2026. Transit’s structured FAQs are not evidence that its guides receive that discontinued search treatment (Google Search Central, Documentation updates, 2026).

I would keep useful questions and their answers for readers. I would not sell their markup as a shortcut to a search feature that no longer exists. That distinction is exactly why checking current documentation belongs in a release review.

Useful content has to survive the phone

The Transit rebuild included sideways scrolling for article tables and tools for questions about costs, GPA and IELTS bands. Those are concrete pieces of the product. I do not need an invented speed improvement to explain why I care about whether a student can use them.

In a fresh review, I would open a guide on a phone-sized screen, read a table, follow a link and try the main action. I would measure loading, responsiveness and layout stability as well. Google says Core Web Vitals are used by its ranking systems, but good scores do not guarantee a top position. It also cautions against chasing a perfect score just for SEO (Google Search Central, Page experience, 2026).

I would read important answers out of context too. Does the paragraph name the thing it describes? Are the limits beside the claim? Can I find where the information came from? That is my editing check, not a claim that every assistant prefers a particular paragraph length.

Google’s people-first guidance asks for clear sourcing and useful, trustworthy content. I would use that standard to remove empty introductions, not turn every page into a pile of isolated answer fragments (Google Search Central, Helpful content, 2026).

Keep optional AI files in proportion

Transit has llms.txt, but I put it after the essentials. Howard’s current proposal describes a Markdown guide for agents, not a replacement for the public pages or a universal crawling standard (Howard, 2026).

Google’s current AI optimisation guide explicitly says llms.txt does not affect its visibility or rankings. I can maintain the file for other systems without putting it on the same priority level as a broken destination or missing content (Google Search Central, AI optimisation, 2026).

My handover would name what passed, what still needs a decision, and what evidence I have not collected. If the script catches a missing page tomorrow, I want that to lead to a correction, not an argument about whether the launch was already declared complete.

Search-ready means I can explain the route from a real question to a useful page and inspect the parts I control. It does not mean I control the search engine. That is a good place to build less and think deeper.

Sources

Documentation checked on 30 October 2026. Pages without a published date are marked n.d.

Google Search Central (2026). Site moves with URL changes. Updated 20 August 2026. https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

Google Search Central (2026). How to specify a canonical URL with rel="canonical" and other methods. Updated 10 July 2026. https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

Google Search Central (2025). Introduction to robots.txt. Updated 10 December 2025. https://developers.google.com/search/docs/crawling-indexing/robots/intro

OpenAI (n.d.). Overview of OpenAI crawlers. https://developers.openai.com/api/docs/bots

Perplexity (n.d.). Perplexity crawlers. https://docs.perplexity.ai/docs/resources/perplexity-crawlers

Google Search Central (2025). Learn about sitemaps. Updated 10 December 2025. https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview

Google Search Central (2026). General structured data guidelines. Updated 10 July 2026. https://developers.google.com/search/docs/appearance/structured-data/sd-policies

Google Search Central (2026). Latest documentation updates. FAQ deprecation entry dated 8 May 2026. https://developers.google.com/search/updates#may-2026

Google Search Central (2026). Understanding page experience in Google Search results. Updated 22 September 2026. https://developers.google.com/search/docs/appearance/page-experience

Google Search Central (2026). Creating helpful, reliable, people-first content. Updated 5 October 2026. https://developers.google.com/search/docs/fundamentals/creating-helpful-content

Howard (2026). The /llms.txt file, v2. First published 3 September 2024; updated 10 August 2026. https://llmstxt.org/

Google Search Central (2026). Google’s guide to optimising for generative AI features on Google Search. Updated 10 July 2026. https://developers.google.com/search/docs/fundamentals/ai-optimization-guide