A Developer-Led Technical SEO Audit Before You Rewrite Content

Before rewriting a large part of a website, confirm that search engines can reliably discover, render and interpret its current pages. If indexing, canonicalisation, rendering or internal linking is broken, new copy will not remove the underlying technical obstacle.

A developer-led audit begins with an inventory, follows the signals attached to each important URL and ends with prioritized actions. It does not promise rankings. Its job is to determine whether the implementation obstructs access to useful content.

1. Establish the current inventory

List the URLs that matter and the role each one serves.

Include core services, categories, articles, localized pages and destinations used by campaigns or external links. Then compare:

• URLs found by a crawler;
• URLs declared in the sitemap;
• URLs known or indexed by the search engine.

Differences can reveal orphaned pages, outdated sitemap entries, unexpected parameters and content that is reachable only through one route.

Record the current state before making changes. Without a baseline, it becomes difficult to separate an existing issue from one introduced during the rewrite or migration.

2. Audit statuses, redirects and canonicals

Every important URL should return its intended status and identify the correct canonical version.

Inspect:

• internal links leading through redirects;
• redirect chains and loops;
• 4xx and 5xx responses;
• protocol and hostname variants;
• trailing-slash inconsistencies;
• parameter-based duplicates;
• canonical tags.

A canonical should point to the page that genuinely represents the preferred version. It should not be used to conceal uncontrolled duplication or replace a necessary redirect.

For localized sites, verify reciprocal hreflang references, correct language codes and accessible alternate URLs. The broader architecture is covered in Building a Bilingual Website for Slovenian and European Customers.

3. Inspect rendered output

What appears after several seconds in a browser is not necessarily what a crawler receives or can process reliably.

For representative templates, check whether:

• primary copy exists in the rendered HTML;
• titles and descriptions are generated correctly;
• navigation contains crawlable links;
• important content requires an interaction to appear;
• an external API failure removes the main page content;
• protected or state-dependent routes are being presented as public pages.

JavaScript is not automatically an SEO problem. The risk appears when essential content and links depend on delayed, fragile or client-only behaviour.

Compare the initial response with the rendered result. If key content arrives later, establish whether that dependency is necessary and dependable.

4. Match metadata and schema to visible content

Review titles, descriptions, headings, Open Graph fields and structured data together.

Look for:

• missing or duplicate titles;
• generic descriptions generated across many pages;
• headings that do not describe the page purpose;
• template variables producing the wrong service or category;
• outdated social-sharing metadata;
• structured data that includes information absent from the page.

Schema.org markup should describe visible, accurate content. If it names an offer, author, date, rating or FAQ that the user cannot see, the implementation and document do not agree.

Structured data can improve machine understanding and support eligible search features. It does not guarantee a particular display, ranking or AI citation.

5. Follow internal link paths

Important pages need clear routes from navigation, related content or relevant parent pages.

Identify:

• orphaned pages;
• important pages buried unusually deep;
• links to redirects or errors;
• generic anchors that hide the destination’s purpose;
• links crossing into the wrong locale;
• several paths leading to unintended duplicates.

Internal links should express meaningful relationships. A service can link to an explanatory article, while an article can lead to the next relevant decision. Adding links to every keyword occurrence makes the page less useful rather than more connected.

6. Validate sitemap and robots rules

The XML sitemap should contain canonical, accessible pages intended for indexing. It should not list redirects, errors, duplicates or private routes.

Check whether it:

• updates when pages are published or removed;
• contains correct localized URLs;
• uses real modification dates where provided;
• excludes non-canonical variants.

Review robots.txt separately. Blocking crawling is not the same as requesting removal from an index. Ensure the rules do not prevent access to resources required to render or understand public pages.

7. Separate technical and editorial findings

Classify each issue:

1. Discovery and indexing: the page cannot be found, accessed, rendered or canonicalised correctly.
2. Structure and interpretation: headings, metadata, links or schema do not describe it clearly.
3. Content and intent: the page is technically available but does not answer the right customer question.

This prevents a technical failure from being handed to a copywriter and a weak proposition from being treated as a development bug.

8. Define verification before implementation

Every action should have a way to confirm that it was applied correctly.

Track:

• response status and final destination;
• canonical and hreflang output;
• rendered content;
• sitemap inclusion;
• internal links;
• form or journey failures;
• implementation date and reason.

Performance should be reviewed with the same discipline. Core Web Vitals in Practice explains how field and laboratory data support that work.

A technical audit cannot guarantee visibility, but it can remove preventable implementation barriers. For a review of a live site, see SEO and performance optimisation or share the context through the contact section.

← Back to the blog