A real report, start to finish

The problem

Search engines show a page's title as its headline in results. 5 pages currently compete with an identical headline, so a searcher cannot tell them apart and none of them describes what makes it distinct. This also makes it harder for search engines to work out which of these pages answers a given query.

The /products/* template renders a fixed title rather than deriving one from the page it is rendering, so every page it produces inherits the same value.

Evidence

The fix

Make the template build each title from the specific page it is rendering — typically the product, article or category name, followed by the site name.

Where

The template behind /products/*. Start from https://northgate-joinery.example/products/red-widget.

Why

Distinct, descriptive titles let searchers tell results apart and give search engines a clear signal about what each page covers.

Watch for

Titles are the visible headline in search results, so this changes how existing listings appear. Keep the wording natural — a title written for search engines rather than people usually performs worse.

Check it worked

Fetch several affected pages and confirm each returns a different <title>. In Search Console, the Pages report should stop grouping them.

Steps

1. Locate the title assignment in the /products/* template.
2. Replace the fixed string with the page-specific name from the page data.
3. Keep titles under about 70 characters so they are not cut off in results.
4. Do not repeat the site name more than once per title.
5. Re-fetch a sample of pages and confirm every title now differs.

The problem

This page is excluded from search results entirely. Anyone searching for it will not find it, however well it is written.

A robots meta tag tells search engines not to index the page. 1 of these pages are also listed in the XML sitemap, so the site is simultaneously asking search engines to crawl them and refusing to let them be indexed.

Evidence

The fix

Remove the noindex directive from the pages that should be findable in search. Confirm first that each page is genuinely meant to be public — some may have been excluded deliberately.

Where

The <head> of each affected page, or the layout component that renders it.

Why

Removing the directive makes the pages eligible to be indexed. Eligibility is a precondition for appearing in search results rather than an assurance of where they appear — but while the directive is present, they cannot appear at all.

Watch for

Pages that were deliberately hidden — staging content, thin duplicates, internal tools — would become eligible for search results. Review the list before removing the directive rather than removing it everywhere.

Check it worked

Fetch the page and confirm no `noindex` appears in either the robots meta tag or the X-Robots-Tag response header. In Google Search Console, use URL Inspection: the page should report as eligible for indexing rather than "Excluded by ‘noindex’ tag".

Steps

1. List the affected URLs and confirm each one is genuinely intended to be public.
2. Locate where the robots directive is set for each affected page.
3. Check for a hardcoded robots meta tag in the shared layout or head component.
4. Remove the noindex directive for the pages that should be indexed.
5. Re-fetch each page and confirm the directive is gone from both the HTML and the response headers.
6. Request indexing for the highest-value affected pages in Search Console.

The problem

A temporary redirect tells search engines to keep the old URL indexed and expect the content to return. If the move is actually permanent, the accumulated value of the old URL is not passed on to the new one, and the old URL keeps appearing in results.

The redirects use status 302, 303 or 307, which mean "temporarily elsewhere". A permanent move should use 301 or 308, which instruct search engines to transfer signals to the destination and replace the old URL in their index.

Evidence

The fix

For each redirect, decide whether the move is permanent. Where it is, change the status to 301.

Where

The redirect definitions in server, framework or CDN configuration.

Why

A permanent status transfers the old URL's accumulated signals to the new one and removes the old URL from search results.

Watch for

Permanent redirects are cached aggressively by browsers, so reversing one later is slow to take effect. Only mark a redirect permanent when the move genuinely is.

Check it worked

Request each URL and confirm the response status is 301 rather than 302.

Steps

1. List each temporary redirect and its destination.
2. Decide for each whether the original URL will ever serve content again.
3. Change permanent moves to status 301.
4. Leave genuinely temporary redirects — maintenance pages, A/B tests, geo-routing — as 302.
5. Re-request each URL and confirm the status.

The problem

Browsers mark HTTP pages as "Not secure", which visibly undermines trust — particularly on any page asking for contact details or payment. Search engines also prefer secure pages when other factors are comparable.

The site responds on http:// and does not redirect to https://.

Evidence

The fix

Obtain a TLS certificate, serve the site over HTTPS, and permanently redirect every HTTP URL to its HTTPS equivalent.

Where

Hosting or CDN configuration. Most platforms now issue certificates automatically.

Why

Removes the browser security warning and eliminates a known ranking disadvantage.

Watch for

Any resource still loaded over http:// on an https:// page will be blocked by the browser, so check for hardcoded http:// URLs in templates, CSS and scripts after switching.

Check it worked

Request an http:// URL and confirm a 301 to https://. Load several pages and confirm no mixed-content warnings appear in the browser console.

Steps

1. Enable HTTPS in your hosting or CDN configuration.
2. Redirect all http:// URLs to https:// with a 301.
3. Search templates, CSS and JavaScript for hardcoded http:// resource URLs and update them.
4. Update the canonical tags and sitemap to use https:// URLs.
5. Confirm no mixed-content warnings appear on any page type.

The problem

Visitors cannot reach these pages by browsing — there is no path to them from any other page. They also receive none of the internal support that tells search engines a page matters, so they tend to rank poorly even when the content is good.

No internal link on any crawled page points at these URLs. They were discovered through the XML sitemap, which is how search engines are likely finding them too — but a sitemap entry carries far less weight than a link from a relevant page.

Evidence

The fix

Link to each of these pages from somewhere a reader would genuinely expect to find them — a relevant category page, a parent section, or related content on a topically similar page. Only keep the pages that should exist; delete or consolidate any that should not.

Where

The most topically relevant existing pages. For each orphan, the right place is wherever a reader looking for it would already be.

Why

A link from a relevant page makes the content reachable for readers and signals to search engines that the page is a real part of the site rather than a stray URL.

Watch for

Do not add links purely to satisfy a count. A link in a footer or an unrelated block adds almost nothing and clutters the page.

Check it worked

Re-crawl the site and confirm each previously orphaned page now has at least one internal link from a relevant page.

Steps

1. Review each orphaned page and decide whether it should exist at all.
2. For pages worth keeping, identify the most relevant existing page to link from.
3. Add a contextual link with anchor text describing the destination.
4. Where several orphans share a topic, consider adding a listing or hub page.
5. Re-crawl and confirm each page is now reachable by following links from the homepage.

The problem

The page never states its subject as a heading, so both readers scanning the page and search engines parsing its structure have to infer the topic from body copy.

No <h1> element is present. On these pages the first heading is either absent or starts at a lower level, which leaves the document without a top-level subject.

Evidence

The fix

Give each page one H1 stating what the page is about. Where a heading already exists at the wrong level, change its level rather than adding a second heading.

Where

The main content area of each affected page.

Why

A single clear main heading makes the page structure explicit for readers, assistive technology and search engines alike.

Watch for

Heading levels usually carry styling. Changing an h3 to an h1 may change its appearance, so adjust the CSS rather than reverting the markup.

Check it worked

Fetch each page and confirm exactly one h1 element is present and describes the page.

Steps

1. Identify the visible page heading on each affected page.
2. Change it to an h1, or add one if no suitable heading exists.
3. Confirm there is exactly one h1 per page.
4. Update CSS so the visual design is unchanged.
5. Re-fetch and confirm the h1 is present.

The problem

The markup on these pages does nothing. Search engines discard structured data they cannot parse without reporting an error anywhere visible, so the effort spent adding it has produced no benefit and the site is not eligible for the richer result formats it was meant to unlock.

The JSON-LD blocks are not valid JSON, so parsing fails before any of the content is read. A trailing comma or an unescaped quote is enough.

Evidence

The fix

Fix the JSON syntax. Where the markup is assembled in a template, build it as an object and serialise it properly rather than concatenating strings — that removes the whole class of error.

Where

The pages listed in the evidence.

Why

Valid markup is actually read, which makes the page eligible for the richer search result formats the markup describes.

Watch for

Structured data must describe what is genuinely on the page. Markup claiming ratings or prices that do not appear in the visible content violates search engine guidelines.

Check it worked

Run each page through Google's Rich Results Test and confirm the markup is detected without parse errors.

Steps

1. Copy each malformed JSON-LD block into a JSON validator to locate the syntax error.
2. Where a template generates it, switch to building an object and serialising it.
3. Confirm every value that appears in the markup also appears in the visible page content.
4. Test each page type in the Rich Results Test.
5. Check Search Console for structured data errors after re-crawling.

The problem

These pages are advertised to search engines through the sitemap and then refused when crawled. The wasted crawl requests are minor; the real cost is that the sitemap no longer reflects what the site actually wants indexed, which makes it useless as a diagnostic signal.

An XML sitemap is a statement that a URL should be crawled and indexed. A noindex directive on the same URL contradicts it. Search engines follow the noindex.

Evidence

The fix

Exclude noindexed pages from the XML sitemap, or remove the noindex from pages that belong in it.

Where

The sitemap generation logic. Most CMS and framework sitemap generators support filtering by index status; this is usually a filter condition rather than a manual list.

Why

A sitemap that lists only indexable URLs gives search engines a clean signal and makes Search Console's coverage reporting meaningful.

Watch for

Nothing visible to visitors. Sitemap entry counts in Search Console will drop, which is the intended outcome rather than a regression.

Check it worked

Regenerate the sitemap and confirm none of the listed URLs return a noindex directive when fetched.

Steps

1. Find where the XML sitemap is generated.
2. Add a filter that excludes any page carrying a noindex directive.
3. Regenerate the sitemap.
4. Spot-check several listed URLs and confirm none carry noindex.

The problem

Visitors following this link from 1 page reach an error instead of content. Search engines following the same links spend crawl requests on dead ends rather than on pages that matter.

These URLs are linked from within the site but return a 4xx or 5xx status. The links were probably valid once and were not updated when the target moved or was removed.

Evidence

The fix

For each broken target, either update the link to the correct current URL, redirect the old URL to its replacement, or remove the link if the content is genuinely gone.

Where

The pages containing the links, listed in the evidence. Where the same broken target is linked from many pages, it is likely in a shared component.

Why

Visitors reach the content they expected, and crawl requests go to real pages instead of errors.

Watch for

If a broken URL has inbound links from other sites, redirecting it is better than removing the link, since that also recovers those visitors.

Check it worked

Re-crawl the referring pages and confirm every internal link returns 200.

Steps

1. List each broken target URL with the pages linking to it.
2. For each, identify whether a replacement page exists.
3. Update links to point at the replacement, or add a 301 redirect from the old URL.
4. Remove links where the content no longer exists and has no replacement.
5. Re-crawl and confirm no internal link returns an error.

The problem

Every hop adds a round trip before the visitor sees anything, which is most noticeable on mobile connections. Search engines follow a limited number of hops, and long chains risk the destination never being reached at all.

These URLs redirect to a URL that redirects again. The chains appear to have accumulated over successive URL changes, with each change layered on top of the last rather than replacing it.

Evidence

The fix

Rewrite each redirect so the original URL points straight at the final destination in a single hop.

Where

The redirect configuration — server rules, framework middleware, or CDN edge rules, depending on where the existing redirects are defined.

Why

One hop is faster for visitors and removes the risk of search engines abandoning the chain.

Watch for

Keep the intermediate URLs redirecting too — other sites may link to any URL in the chain, and removing a middle rule would turn those links into errors.

Check it worked

Request each original URL and confirm a single redirect straight to the final destination.

Steps

1. List each chain and its final destination.
2. Update the first redirect in each chain to point directly at the final URL.
3. Keep intermediate redirects in place so existing inbound links still resolve.
4. Re-request each original URL and confirm exactly one hop.

The problem

Without a declared canonical, search engines pick which URL to index themselves. When the same page is reachable with a trailing slash, tracking parameters, or through several paths, they may pick a different version than the one you would choose.

No canonical link element is present. A self-referential canonical is the usual way to state which URL is authoritative for a page.

Evidence

The fix

Add a self-referential canonical tag to each page, generated from the page's own preferred URL.

Where

The shared head component or layout, so it applies site-wide.

Why

It removes ambiguity about which URL should be indexed when a page is reachable more than one way.

Watch for

A canonical generated incorrectly is worse than none at all — pointing every page at the homepage, for instance, would remove the whole site from results. Verify the generated value on several page types before deploying.

Check it worked

Fetch a sample of pages of each type and confirm each canonical matches that page's own URL exactly, including protocol and host.

Steps

1. Add a canonical link element to the shared page head.
2. Generate its value from the page's absolute preferred URL.
3. Confirm the value is absolute and uses the correct protocol and hostname.
4. Test on a homepage, a listing page and a detail page before deploying site-wide.
5. Re-fetch and confirm each canonical is self-referential.

The problem

People using screen readers get no description of these images — for a product photo or a diagram, that can make the page unusable. Search engines also lose the only description they have of the image, so it cannot surface in image search.

These images have no alt attribute at all. An empty alt attribute would be correct for purely decorative images; a missing one means no decision was made.

Evidence

The fix

Add alt text describing what each image shows and why it is on the page. For images that are purely decorative, add an explicitly empty `alt=""` so assistive technology skips them.

Where

The pages listed in the evidence.

Why

The page becomes usable for people who cannot see the images, and search engines gain a description of what each image contains.

Watch for

Alt text should describe the image, not repeat target keywords. Keyword-stuffed alt text is both unhelpful to screen reader users and against search engine guidelines.

Check it worked

Re-crawl and confirm every content image has an alt attribute, empty or otherwise. Browse a page with images disabled and check it still makes sense.

Steps

1. List the images missing alt attributes, grouped by page.
2. For each, decide whether it conveys information or is decorative.
3. Write descriptive alt text for informative images, describing what is shown.
4. Add `alt=""` to decorative images.
5. Where a template renders the image, make the alt value a required field in the content model.
6. Re-crawl and confirm no content image lacks an alt attribute.

The problem

Search engines fall back to an extract from the page, which is often a navigation fragment or a mid-sentence snippet. A written description is the site's chance to say why someone should click.

No meta description element is present on these pages.

Evidence

The fix

Write a meta description for each of these pages, describing what the page offers and why it is worth opening. Around 150 characters keeps it from being cut off.

Where

The head of each affected page.

Why

A written description gives searchers a reason to choose this result. Search engines may still substitute their own text for some queries, but a good description is used most of the time.

Watch for

Changes the descriptive text under the title in search results.

Check it worked

Fetch the page and confirm the meta description is present and under about 160 characters.

Steps

1. List the affected pages in importance order.
2. Write a description for each that states what the page offers, in plain language.
3. Keep each under roughly 160 characters.
4. Avoid repeating the title verbatim, and avoid keyword lists.
5. Re-fetch and confirm the tag is present.