Technical fixes and Core Web Vitals

This is the longest chapter because it covers 30 of the 44 checks in the audit. You do not need to read it straight through. Read the table below, then go to the section for the findings you have. Technical fixes are where an assistant saves the most time and where a wrong answer does the most damage, so each prompt asks for a check you can run.

What each technical finding costs

One exception to the table: the "noindex" check costs 5 points only if the homepage is noindexed or more than 20% of crawled pages are. Otherwise it is advice. The image-alt check, from chapter 5, works the same way.

The last row is worth understanding. The Performance score is the average of PageSpeed Insights scores, and the performance findings are listed without taking points off it. So the only way to move that category is to make the pages faster. The audit tests the homepage plus up to four other pages, the ones with the most internal links to them, on mobile and desktop. On a large site, one slow template page can drag the average, and the pages tested are a sample.

The prompt that works for any finding

Every technical fix needs three things: the finding, your stack, and a way to check the result. This prompt asks for all three, and tells the assistant to ask rather than guess when it doesn't know your setup.

Finding from the audit: {issue title and description, with two example URLs}
My stack: {CMS, theme and SEO plugin; server type (nginx, Apache or managed host); Cloudflare or not}

Give me the exact change that clears this finding: where to make it, the code or the setting, and how to confirm it worked (a curl command, a view-source check, or a re-audit). If the right fix depends on something about my setup that you don't know, ask me before you answer. Tell me what could break.

Redirects, broken links and server errors

A broken internal link is a link on your site to a page that returns an error. It is critical, because visitors and crawlers hit a dead end. The audit ignores 401 and 403 responses, since those usually mean a login wall or bot protection, not a missing page. A server error (a 5xx response) is critical for the same reason. These two are usually not SEO problems at all. They are a hosting, plugin or broken-link problem that you should have heard about already, and uptime monitoring is how you hear first.

Redirects are fixed in the redirect rule, not the page. A redirect chain is a URL that passes through more than one redirect to reach the final page, and a loop never finishes. Both are fixed by sending each old URL straight to its final destination in one hop, and by updating internal links to point at the final URL so the redirect is never used.

One canonical version of the site

A site should answer at one address. That means one choice between https and http (always https), one between www and non-www, and one canonical URL declared on each page. Not enforcing https is critical in the audit. A page that loads images or scripts over http on an https page is mixed content, which breaks the padlock. A canonical tag that is invalid, missing, or in conflict with the canonical in the HTTP header is a smaller problem. Fix the first set with server rules, and the canonical set in the SEO plugin.

These URLs pass through more than one redirect before reaching the final page:

{start URL -> 301 -> next URL -> 301 -> final URL}

My server is {nginx / Apache / Cloudflare rules / a WordPress redirect plugin}. The site should answer only at https://{www or non-www}.{domain}.

Write: (1) the single rule that sends each start URL to its final URL in one hop; (2) the rule that sends http and the other host version to the chosen one in one hop; (3) three curl -I commands I can run to check, with the exact status and Location header I should see. Do not redirect everything to the home page.

robots.txt, sitemaps and the 404 page

The audit warns when a site has no robots.txt, when it cannot be parsed, when there is no sitemap, when the sitemap is invalid, when URLs in it do not return 200, and when the site has no custom 404 page. All are warnings. The sitemap should list only pages you want in search: ones that return 200, are not noindexed, and are the canonical version. A robots.txt that blocks CSS or JavaScript, or the whole site left over from a staging copy, is one of the costliest mistakes on this list, so read it yourself.

Here is the site's current robots.txt (or "none"):

{paste robots.txt}

The site is {WordPress with its SEO plugin, or other}. The sitemap is at {URL}. Write a robots.txt that blocks only {admin and internal search pages / the paths I list}, does not block CSS or JavaScript, and points to the sitemap. Then give me a short checklist to confirm the sitemap contains only URLs that return 200, are not noindexed and are the canonical version. Explain every line you add in plain words.

Orphans, depth and links

An orphan page is one that no other crawled page links to, so a crawler only finds it through the sitemap, if at all. A deep page is five or more clicks from the home page. Orphans cost 5 points and depth costs nothing. The fix for both is a link from a relevant page, not a technical change. Ask the assistant which existing pages should link to the orphan, given the keyword map from chapter 3, then add the links yourself.

Social tags and the favicon

The audit looks for Open Graph and Twitter card tags and a favicon on the home page. All three are advisory and cost nothing. They control how a shared link looks and whether the browser tab has an icon. An SEO plugin sets them in a few minutes and an assistant is not needed.

Speed and Core Web Vitals

Core Web Vitals are three measures of how a page feels to load and use. The "good" thresholds, from Google's web.dev, are Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less. The audit flags only the poor end: LCP over 4 seconds, INP over 500 milliseconds, CLS over 0.25, a PageSpeed performance score under 50, and a server response over 1.5 seconds. So a page can pass the audit and still be short of "good". Check in PageSpeed Insights, not only in the audit.

Run PageSpeed Insights on mobile, copy the report as text, and ask for an order of work.

Here is the PageSpeed Insights report for {URL} on mobile, pasted as text: the scores, LCP, INP and CLS, and the opportunities and diagnostics list.

{paste the report}

My site is {WordPress, and which theme or page builder}. I can edit theme files and install plugins but I don't control the host. Order the fixes by effort, easiest first. For each fix give me: which metric it moves, how big the gain is likely to be (small, medium or large), the exact change, and what could break. Skip fixes for any metric already in Google's "good" range.

After each change, test again on a staging copy if you can. Speed fixes such as deferring scripts, resizing images and lazy-loading break layouts more often than any other change in this guide.

Don't bother with

• A perfect PageSpeed score. Aim for the "good" range on the real-user metrics and stop. The last 10 points cost the most.
• Redirecting every old URL to the home page. Send each one to its closest equivalent.
• Blocking pages in robots.txt to keep them out of search. Blocking stops crawling, not indexing. Use noindex for that, on a page that can be crawled.
• Chasing the info-level findings first. They cost nothing in the score.

Next

• Chapter 8: Showing up in AI answers
• Catch server errors before the client does
• Google: Core Web Vitals and Search (Google Search Central)