How to improve SEO: a process to audit, prioritize, fix and measure

Why improving SEO is a loop, not a checklist

Google's SEO Starter Guide is blunt about it: there are no secrets that automatically rank a site first, and not every change you make will have a noticeable effect in search results. Its Search Essentials add that most sites pass the technical requirements without even realizing it. So the hard part of improving website SEO is rarely knowing what good looks like. It is choosing, out of hundreds of possible changes, the few that will move the pages your business depends on, and proving afterwards that they did.

A loop does that. Each round starts from a goal and a measured baseline, turns an audit into a short ordered list, ships the fixes, and checks the result against the same numbers. It also protects what already works. Google's guide to debugging traffic drops notes that small position changes happen all the time and recommends against radical changes to a page that is already performing well. A tips list cannot tell you when to leave something alone; a baseline can.

Step 1: Set goals and record a baseline

Start from the business, not the tools. Which pages produce enquiries, sales or sign-ups? Which searches describe what you sell, in the words your customers use? Write down that short list of target pages and queries first. Everything later in the loop is judged against it, and a rise in total traffic that never reaches those pages is not the goal.

Then record where those pages stand today. Google's guide to using Search Console and Analytics together draws the line at the moment a person arrives from Search:

• Search Console measures what happens before the click. Its Performance report gives clicks, impressions, click-through rate (CTR) and average position for every query and page.
• Google Analytics measures what happens after it: which pages visitors see, how long they stay and what they do. Mark the actions that matter as key events, such as a contact form submission, so you can count them by landing page.

Linking the two adds Google Organic Search Queries and Google Organic Search Traffic reports to Analytics (the collection is unpublished by default; publish it from the Library). Search Console data arrives there 48 hours after collection, and only the last 16 months are kept.

Two newer views make the baseline sharper. The branded queries filter, announced in November 2025 and available to all eligible sites since March 11, 2026, splits searches for your name from everything else. Branded searches come from people who already know you; non-branded searches are where new customers find you, so that is where improvement shows. The filter only appears on top-level properties with enough query volume. And as of August 31, 2026, the Generative AI performance report, which counts impressions in AI Overviews and AI Mode, has rolled out to all websites; a site with too few of those impressions will not see it yet.

Step 2: Audit crawling, indexing, speed and mobile

The technical audit asks two questions in order: can Google find and index the pages that matter, and do those pages work well for the people who land on them?

Crawling and indexing

Open the Page indexing report first. Google states the goal plainly: the canonical version of every important page indexed. It is not 100% coverage, and a URL marked as a duplicate or alternate is usually working as intended. Filter the report by your sitemap to see only the URLs you submitted, then read the reasons against your target list:

• Crawled - currently not indexed: Google fetched the page and did not index it, and says there is no need to resubmit it. Treat it as a content question for step 3: is the page useful, and clearly different from its neighbours?
• Discovered - currently not indexed: Google knows the URL but rescheduled the crawl because it expected to overload the site. Slow responses and server errors lower how much Google will crawl, so check server response times first.
• Duplicate without user-selected canonical: Google picked another URL as the canonical. Check that it picked the one you want.

For a single page, the URL Inspection tool shows the indexed version, the Google-selected canonical and a screenshot of the rendered page, and its live test checks the version on your server now. To see the site as a set of templates, add a crawler such as Screaming Frog SEO Spider or Sitebulb for status codes, canonical tags, noindex rules, titles and internal links, and your server logs for what Googlebot actually requests. The mechanics behind these reports, from the URL frontier to robots.txt, are in web crawling and indexing explained.

Size the crawl work to the site. Google's crawl budget guide is written for sites with roughly a million or more pages that change weekly, 10,000 or more that change daily, or a large share of URLs stuck in Discovered - currently not indexed. If your pages are crawled the day they are published, it says you do not need it, and the Crawl Stats report says a site with fewer than a thousand pages should not need to worry about that level of detail.

Core Web Vitals and mobile

The Core Web Vitals report uses field data from real Chrome visits, scores the value that 75% of visits over the last 28 days met, and groups similar pages into URL groups. The thresholds:

Google recommends good Core Web Vitals and says they align with what its core ranking systems seek to reward. To debug one URL, PageSpeed Insights shows that page's field data from the Chrome User Experience Report (CrUX), over a trailing 28 days, next to a Lighthouse lab run. Its numbers can differ from the report's, because one URL can be an outlier in its group. Use the lab run to find the cause and the field data to judge the result.

Check mobile as the version that counts. Under mobile-first indexing, Google indexes the mobile version of a page, crawled with its smartphone agent. The mobile page needs the same primary content as the desktop page, and content that only loads after a tap or a swipe will not be loaded by Google.

Step 3: Audit content: keep, improve, merge or remove

A content audit starts with an inventory: every indexable URL, with its clicks and impressions over the last 16 months, its key events, the links pointing at it and the one question it is meant to answer. Sorted that way, the problems show themselves: pages that answer nothing anyone searches for, two pages answering the same question and splitting the clicks between them, and pages whose facts have gone out of date.

Judge each page with the self-assessment questions in Google's guide to helpful, reliable, people-first content. Does it offer original information or analysis? Is it a substantial, complete answer? Does it add value compared with the other pages in the results? The same guide lists the moves that do not help: writing to a word count (Google says it has no preferred one), changing a page's date when the content has not substantially changed, and adding or removing large amounts of content to make the site seem fresh.

Then give every page one decision:

A redirect is a strong canonical signal, which is why merging consolidates two weak pages into one stronger one. Removal comes last on purpose. Google's guidance on core updates calls deleting content a last resort, for content that cannot be saved, and the Page indexing report says a 404 for a page removed without any replacement is not necessarily a problem. When a page needs more depth rather than more words, semantic SEO shows how to map the entities and questions a topic should cover.

Step 4: Audit internal and external links

Internal links are how Google finds your pages and how you show which ones matter. Google's link best practices say it can generally only crawl a link that is an <a> element with an href attribute, and that the anchor text tells people and Google what the target page is about. In the audit, look for three things:

1. Orphan pages: target pages that appear in the sitemap or analytics but receive no internal links in the crawl.
2. Buried pages: important pages several clicks deep while minor pages sit in the main navigation.
3. Vague anchors: "read more" and "click here" where a descriptive phrase would say what the page is.

The Search Console Links report shows your top linked pages from inside and outside the site. It is a sample, not a complete list, and its tables stop at 1,000 rows, so use it to spot patterns rather than to count. For external links, note which pages earn them and which do not. Do not buy them: buying or selling links for ranking purposes is link spam under Google's spam policies. How Google determines a website's authority explains where links fit among the other signals, and the power of quality backlinks covers what makes an external link worth earning.

Step 5: Prioritize by impact against effort

An audit of an ordinary site produces more findings than any team can fix in a month. Rate each one on two scales. Impact is how much business value the affected pages carry, how many pages the finding touches, and how much demand is already there (impressions you are getting but not converting into clicks). Effort is developer time, writing time, risk and anything the fix depends on. Then apply five rules:

1. Indexing blockers first. An important page that is not indexed cannot rank at any position.
2. Templates before single pages. The Core Web Vitals report groups URLs on the assumption that they share a framework and the causes of their scores, and the Page indexing report notes that error spikes can come from a template change. One template fix reaches every page built from it.
3. Pages just off page one before new pages. A page ranking just below the first page for a query you care about already has demand and relevance. Finding untapped SEO opportunities shows how to pull those queries out of Search Console.
4. Leave what works alone. Small position changes are normal, and Google advises against changing content that already performs well.
5. Drop what does not apply. Crawl budget work on a site of a few hundred pages that are crawled promptly, or an llms.txt file for Google (its generative AI guide says Google Search ignores them), is effort with no impact.

A worked example: one prioritized list

Take a hypothetical services company: a dozen service pages that produce enquiries through a contact form (the key event), and a blog of a few hundred posts. The audit returns six findings. This is an illustration, not a client: the findings are typical, and the order is the point.

Why this order: the first item is one template change on the pages that make money. The second is also one template, and it fixes a whole URL group at once. The third costs writing time, but the demand already exists and the pages are close. The fourth is a quick merge with a 301 redirect. The old news posts are parked for the next content review rather than deleted, since removal is the last resort. The crawl budget warning is dropped: the site is well under a thousand pages and new posts are crawled promptly, so by Google's own criteria it is not a concern.

Step 6: Turn findings into tickets and fix the cause

A finding is not a fix. Each item on the list becomes a ticket someone can pick up without asking questions:

1. What is wrong, in one sentence, and which template or component causes it.
2. Where, with three or four example URLs, and the report that shows it.
3. The fix, specific enough to review in a pull request.
4. The acceptance test: what the served page must contain, or must not contain, after release.
5. How it will be verified in Google, and which baseline number it should move.

Fix the cause where it lives. A missing canonical tag, a stray noindex or a lazy-loaded hero image usually comes from one template or shared component, not from each page. Fixing it there reaches every URL built from that template, and so would a new bug, which is why the acceptance test belongs in your build or deploy checks rather than in someone's memory.

The acceptance test can be as small as two commands run against one URL per template after each release. The first reads the robots meta tag and canonical from the served HTML; the second reads the status code and any X-Robots-Tag header:

curl -sL https://www.example.com/services/web-design/ \
  | grep -Eio '<meta[^>]+name="robots"[^>]*>|<link[^>]+rel="canonical"[^>]*>'

curl -sIL https://www.example.com/services/web-design/ \
  | grep -Ei '^HTTP/|^x-robots-tag'

After the release, re-test in Google's own tools. Run the URL Inspection live test on a few affected pages, then click Validate fix in the Page indexing report; validation typically takes up to about two weeks, and validating against a sitemap of your most important URLs can finish sooner. For Core Web Vitals, Start tracking opens a 28-day monitoring session of field data. Request indexing only for a handful of key URLs: Google says recrawling takes a few days to a few weeks, requests are subject to a quota, and asking again for the same URL does not make it faster. For many URLs, submit an updated sitemap instead.

Step 7: Measure the result against the baseline

Measuring SEO results is mostly about comparing like with like, and knowing what else happened on the same dates.

Annotate every change. Search Console's custom annotations, added on November 17, 2025, let you right-click a performance chart and note a change in up to 120 characters. Everyone with access to the property sees them, so keep personal details out. Annotate Google's changes as well: the Search Status Dashboard lists ranking updates, and on September 25, 2026 it showed a September 2026 spam update that began rolling out the day before. After a core update, Google recommends waiting at least a full week after it finishes before analyzing the data.

Compare matching date ranges. Compare periods of the same length, filtered to the pages you changed and, where you can, to non-branded queries. The weekly and monthly views added on December 10, 2025 remove the day-of-week mismatches that make a daily comparison hard to read. For a seasonal business, compare with the same period a year earlier, which the 16-month window allows.

Judge the right numbers. Google's traffic-drop guide says impressions and clicks are ultimately the measure of success, not average position. After those, look at the key events from the pages you changed, because traffic that does not lead anywhere is not the goal you set in step 1.

Give it time. The Starter Guide says some changes take effect in a few hours and others take several months, and suggests waiting a few weeks before assessing whether a change helped. For specific changes, Google's documentation gives these expectations:

If a change shows nothing after that, the loop has still done its job: you know, and the next round can try something else.

Step 8: Repeat on a cadence

Google's Search Console getting-started guide says there is no need to log in every day: it emails you when it finds new issues, and checking around once a month, or whenever you change the site's content, is enough to confirm the data is stable. That fits a simple rhythm:

• Monthly: compare the baseline metrics with the previous month and the same month last year, and read the Page indexing and Core Web Vitals reports for new issues.
• After every release that touches a template: run the ticket's acceptance tests and a live URL inspection on one page per template.
• Every quarter: repeat the audit, update the content inventory and re-prioritize the list.
• Before a redesign or migration: run the full audit and map every old URL to a decision before launch.

AI search does not need a separate loop. Google's guide to generative AI features says optimizing for them is still SEO, and a page must be indexed and eligible to show with a snippet to appear in AI Overviews or AI Mode. The Generative AI performance report is one more line in the same baseline. For how ChatGPT, Perplexity, Copilot and Gemini find and cite pages, see AI's impact on SEO; for Google's AI features and their controls, AI Overviews in Google Search.

If you would rather hand the loop over, our SEO service starts with a technical audit: a crawl of the whole site, a read of Search Console and, where you have them, your server logs, with issues ranked by impact and effort and a 90-day plan. If your own developers prefer to make the changes, findings arrive as tickets they can act on. Google's own advice on hiring an SEO is worth reading either way: an audit should give realistic estimates of improvement and of the work involved, and anyone who guarantees first place is someone to avoid.