AI SEO agency in Manchester

Where AI SEO and classic SEO overlap

A fast, crawlable, well-structured site helps in both worlds, and so does genuine authority. If your technical foundations are poor, no amount of AI-specific work will rescue you — a page that renders slowly, hides its content behind script, or returns the wrong status codes is a problem for every system that tries to read it. We start by making sure the basics are sound, because they are the shared floor beneath both disciplines and because fixing them is cheap relative to what follows.

Where they part company

Classic SEO optimises a page to rank. AI SEO optimises a business to be described accurately. That shifts the emphasis away from keyword targeting and towards identity: who you are, what you sell, where you operate, and what other credible sources say about you. It also introduces a failure mode search never had — an assistant confidently stating something about you that is simply wrong. A bad ranking costs you a visitor. A wrong answer costs you a customer who never learns they were misinformed.

The AI crawler question

Before anything else, it is worth checking whether the AI systems are allowed to read your site at all. A surprising number of businesses block GPTBot, ClaudeBot, PerplexityBot or Google-Extended in robots.txt without realising, often inherited from a template, a plugin default, or a well-meaning developer following advice written for publishers. It is a two-minute check. Occasionally it explains everything, and the fix is a one-line edit.

Technical foundations we check first

Server response codes and redirect chains. Rendering — whether your content exists in the HTML or only after script runs. Canonical tags, and whether they contradict your sitemap. Page speed on a real connection rather than a lab score. Mobile rendering. Duplicate and thin pages, particularly the location pages agencies mass-produce. Broken structured data. Orphaned pages nothing links to. None of this is exciting, all of it is measurable, and it is the part most likely to be quietly broken.

Content architecture that helps both

One page per subject, named the way a customer would name it, linked to from the pages that logically relate to it. Pillar pages for the big subjects, supporting pages beneath them, and internal links that make the relationship explicit rather than implied by a navigation bar. This is old advice and it survives the transition intact, because a structure that helps a reader find the right page also helps a machine work out what you are authoritative about.

Local signals

For most Manchester and North West businesses, local is where the enquiries are. That means a Google Business Profile with the right primary category, complete services, real photographs and current opening hours. It means reviews arriving steadily rather than in suspicious bursts, and replies to them. It means consistent details across the directories that matter in your sector. And it means location pages that say something specific about the place, rather than the same paragraph with the town name swapped — which readers and models both recognise instantly.

Measurement, and its limits

We report on whether the assistants name you and what they say about you, alongside the conventional metrics where they are useful — impressions, clicks, and the queries actually driving them. What we will not do is hand you a dashboard full of numbers that has nothing to do with whether the phone rang. Attribution from AI assistants is genuinely poor at present: some send no referrer, some send traffic that looks direct, and none of them gives you a query report. Anyone claiming precise AI attribution is guessing, and we would rather say so.

Inheriting from a previous agency

Often we are the second or third agency on a site, and the first job is archaeology. Mass-produced location pages with duplicate copy. Schema describing services that no longer exist. A migration that left redirect chains behind. Links bought years ago. Two Google Business Profiles for one location. We audit before we build, because it is common for the fastest gain to be removing something rather than adding to it, and because you deserve to know what you inherited.

Timescales, honestly

Technical fixes and entity corrections show up fastest, sometimes within weeks. Content and authority work compounds over months. Anything involving reviews moves at the speed your customers move. We plan in quarters and report monthly, and if a quarter has not produced the movement we expected, we would rather examine that with you than pad the report.

Two things we will not do

We will not buy links. It is against every platform guideline that matters, the footprint is detectable, and the businesses that get caught are rarely the ones who bought them — they are the ones who inherited them from an agency three years earlier. And we will not publish mass-generated location or service pages that say nothing. They are cheap to produce, they briefly look like progress on a page count, and they actively damage the impression of substance that both search engines and assistants are trying to form about you.

What a first month looks like

Days one to three, the audit: prompts written, all six assistants run, signals traced. Days four to five, a call to walk through what we found and agree the order of work. Week two, the quick corrections — crawler access, robots.txt, structured data, the Google Business Profile. Week three, entity work across the public record, which is mostly patient list-checking. Week four, the first content restructuring on your two or three most important pages, and a re-test so the month closes with evidence rather than an invoice.

Working with your developer

Most sites we touch have somebody who owns the code, whether that is an in-house developer, a freelancer, or the agency that built it. We write for them: what to change, which file or template, what the expected output is, and how to verify it. No GEO vocabulary required to implement it. Where a change is risky — anything touching redirects, canonicals or the sitemap — we say so plainly and suggest doing it on a staging copy first.