Search metadata and technical SEO checks

This is a QA service, not a marketing one. We do not research keywords or promise rankings. We check that the technical signals a search engine reads are correct, consistent and free of the mistakes that turn up at launch: a staging noindex left in place, canonicals pointing at a test domain, or a redesign that sends every old address to the home page.

What we check

• Titles. Every indexable page has a title that describes it and differs from other pages. Google's documentation asks for "distinct text that describes the content of the page" and advises against "repeated or boilerplate text" in titles.
• Meta descriptions. Present, specific to the page, and not duplicated across templates.
• Headings. One main heading per page that matches what the page is about.
• Indexing rules. No noindex on pages that should appear in search, and noindex where it belongs, such as thank-you pages or internal search results. We check both the meta robots tag and the X-Robots-Tag response header.
• robots.txt. It does not block pages or resources the site needs indexed. Google notes that a noindex rule only works if the page is not blocked by robots.txt, because a crawler that is turned away never reads the rule.
• Canonical tags. Absolute URLs, pointing at the live domain and the preferred version of each page, with no chains or loops.
• Redirects. Old URLs from a previous site go to their closest new equivalent in one step, with permanent redirects. HTTP to HTTPS and www to non-www, or the reverse, resolve in a single hop.
• XML sitemap. Lists only live, indexable, canonical URLs, and is referenced in robots.txt.
• Structured data. Valid markup that matches what the page shows, without types that claim things the page does not support, such as review stars with no reviews behind them.
• Status codes. Missing pages return a real 404, not a soft 404 that looks like a page to a search engine.
• Internal links. No links to staging hosts, no links that redirect when they could point straight at the destination, and no orphaned pages that nothing links to.
• Language and region. A correct lang attribute, and hreflang annotations where a site has language or country versions.

How a session runs

We crawl the staging site before launch and the live site straight after, because problems introduced by the move itself, such as hard-coded staging addresses, only show up on live. Where you are moving from an old site, we compare the old URL list with the new redirects and report any gaps. Where you use Google Search Console, read-only access lets us check how Google sees the live site in its first days; we do not need it to do the rest of the work.

Redirect planning for a site move

When a new site replaces an old one, the redirect map deserves more care than any other piece of search work. Without it, every old address that other sites, bookmarks and search results point to becomes a dead end. We check the map in four steps:

1. Collect the old addresses From the old site's sitemap, a crawl of the old site, and, where available, the pages that received search traffic or links.
2. Match each to a destination The closest equivalent page on the new site. Sending everything to the home page is not a match; Google can treat it as a soft 404.
3. Test the redirects Each old address should return one permanent redirect to its destination, with no chains through intermediate addresses.
4. Watch after launch Check for addresses that were missed, using the live site's 404 log or Search Console's coverage reports where you have access.

If the old site is already gone and its address list was not kept, we reconstruct what we can from public sources and say plainly what could not be recovered.

What you receive

• A findings list by severity, from launch blockers such as site-wide noindex down to tidy-ups such as long titles.
• A redirect gap list where an old site existed, with suggested destinations.
• A post-launch recheck to confirm the fixes went live, if listed in the quote.

What this service does not cover

No keyword research, content strategy, link building or ranking promises. Search engines decide rankings; a technically clean site removes avoidable obstacles but guarantees nothing about position. We also do not edit your CMS; we list what needs changing and where.

When to book search metadata checks

• In the week before launch, and again soon after it, on dates set in the scope.
• Before and after a domain change, a move to HTTPS, or a change of URL structure.
• After a CMS migration, when plugins that handled titles and redirects may not have come across.

Questions about search metadata checks