“Improve crawlability” is not an instruction a developer can finish. It leaves them to find the affected pages, diagnose the fault and decide what working properly should look like. An audit that stops there has passed the investigation to the person expected to implement the fix.
A useful SEO audit closes that gap. It connects an observed problem to a page that matters, explains the consequence and gives someone a testable piece of work. The report can be long or short. What matters is whether you can use it to decide what deserves attention and then verify the change.
For a creative business, that means looking beyond a site-wide health score. A portfolio needs to explain the work and connect it to an enquiry. A publisher’s catalogue needs to help readers find the right title. An event page needs to distinguish an upcoming date from an archive. We judge audit recommendations by how well they support those jobs, not how many warnings they remove.
01
An Inventory Is Evidence, Not a Priority List
A crawl export is useful. It can reveal repeated titles, broken links and patterns across templates that would be difficult to spot page by page. A detailed appendix also gives the implementation team the scope behind a recommendation. Length is not the defect.
The problem begins when a list of observations becomes the work queue without further diagnosis. A crawler can flag a missing description on an old archive and an inaccessible explanation of what customers can commission. Those findings do not deserve equal attention simply because both appear in the same report.
Before accepting the priority, ask what the affected page is meant to do. Is it a current collection that customers need to browse, a project that demonstrates a service, or a deliberately restricted preview? A finding only becomes actionable once the intended behaviour is clear. Making a private preview discoverable would not be an improvement.
Our SEO audits connect technical findings with content, search demand and the enquiry path, then organise tasks by impact, urgency, complexity and likely owner. That gives the inventory a purpose: supporting a decision about where effort belongs.
02
Start With the Pages Behind the Enquiry
Choose the pages that need to support the business before deciding which warnings to fix. For a production studio, an overview of its production offering may explain what can be commissioned while selected projects supply the proof. Reviewing either in isolation can miss the route a prospective client needs.
Follow that route. Can someone discover the service, understand whether it fits their brief, inspect relevant work and find a clear way to enquire? If a project page contains striking images but no explanation of the studio’s role, rewriting its metadata will not answer the visitor’s question about what the studio actually delivered.
Search access and page usefulness are separate checks. A page can be accessible to a crawler yet fail to explain an offer. It can also make perfect sense in a browser while important content is unavailable in the rendered HTML Google sees. The audit needs to identify which condition exists rather than prescribing the same content rewrite for both.
This also makes prioritisation more defensible. A confirmed fault across the current catalogue may justify template work before polishing an isolated archive page. But scale alone is insufficient: a fault on a single enquiry page can matter more than a repeated cosmetic inconsistency. Consider the page’s role, the extent of the problem, the evidence and the effort needed to address it.
03
Turn a Warning Into a Testable Issue
A recommendation should contain enough information for another person to reproduce the problem without repeating the whole audit. “JavaScript issue” names a technology. It does not identify what is missing, where it is missing or under which test conditions.
Write the issue around observable behaviour. Keep the finding separate from the proposed explanation: missing project text is an observation; a rendering failure is a diagnosis that needs supporting checks. That distinction prevents a plausible theory from becoming an unnecessary rebuild.
A practical issue brief should include:
- Affected scope: the exact URLs, shared template or component, including known exceptions.
- Evidence: what the check returned, when it was run and the relevant crawl or rendering settings.
- Reader impact: what discovery, understanding or action the fault obstructs.
- Proposed change: the behaviour to correct, with any diagnosis still to confirm clearly identified.
- Implementation owner: the person or team able to change the relevant content, code or configuration.
- Acceptance check: the observable result required before the work is accepted.
- Retest: the live checks needed after release and who will review them.
Not every finding needs a lengthy brief. A broken internal link may need little more than its location, intended destination, owner and a successful follow-up check. A shared catalogue template with inconsistent rendering needs more detail because the change can affect many pages.
Precision should reduce work, not create paperwork. If the developer cannot tell which URLs to inspect or the editor cannot tell what information is missing, the recommendation is not ready for implementation.
04
Diagnose Rendering Before Prescribing a Rebuild
JavaScript-heavy portfolios illustrate why an audit must go beyond the first response returned by a crawl. Google’s JavaScript SEO guidance states: “Googlebot queues pages for both crawling and rendering.” Google uses the rendered HTML to index page content, so an initial response without project text is not, by itself, proof that Google cannot access that text.
The next check should distinguish the initial HTML from the rendered result. Inspect whether the project description and relevant links are present after rendering, and use Search Console’s URL Inspection tool to examine how Google sees the page. Record the particular content that is absent rather than describing the entire site as invisible.
Consider a hypothetical portfolio where project descriptions appear to visitors but are missing from the rendered HTML inspected for Google. The issue brief would name the affected project URLs, identify their shared template and retain the test evidence. The consequence is specific: Google cannot index text that is absent from the rendered HTML. That is a stronger basis for investigation than a generic warning that the site uses JavaScript.
The acceptance check should then require the intended project text and links to be available in the relevant rendered output. It should also include a browser check that the portfolio still works as intended. Passing an SEO check while breaking project navigation would leave the implementation incomplete.
This example is a diagnostic pattern, not a reason to replace every interactive site. The evidence should determine whether the work concerns blocked resources, missing output, routing or another implementation fault.
05
Give the Work an Owner Who Can Complete It
Assigning everything to “SEO” conceals the dependencies. An editor may control a release description but not the template that outputs it. A developer may control that template but need the publisher to confirm which edition should be presented to readers.
Choose an implementation owner with access to the relevant system and authority to make the change. Where a decision is needed first, identify it explicitly. “Waiting for confirmation of the preferred edition” is more useful than a technical ticket that remains open without explanation.
Acceptance may require someone other than the implementer. A developer can confirm that the correct content field appears; a content owner can confirm that the field contains an accurate account of the project. Both checks matter when the fix changes what visitors learn about the work.
Separate shared causes from page-level exceptions. If a template produces the same defective link across a collection, investigate the component rather than assigning manual edits to every page. If the template works but individual records lack information, that is a content task. Confusing these cases either wastes editorial effort or sends developers a problem they cannot solve in code alone.
06
Define Acceptance Before the Change
“Optimised” is not an acceptance criterion. Neither is “health score improved”. Both allow work to be marked complete without showing whether the original problem has changed.
A useful criterion describes a result someone can inspect. For a broken link from a project to the related offering, require the link to reach the intended explanation of what customers can commission and confirm that its text makes the destination clear. For an inaccurate page title, require a title that distinguishes the project and accurately describes the page, then check the published output rather than only the CMS field.
Content recommendations need equally concrete boundaries. “Add more copy” gives no reason to stop. If a portfolio page does not explain the studio’s contribution, specify the missing information: its role, the relevant work and the route to the related service or enquiry. Acceptance can then focus on whether those questions are answered accurately, not whether an arbitrary word count has been reached.
Include constraints that the implementation must preserve. A navigation fix should not remove access to other collections. A public-page correction should not expose restricted material. These are acceptance conditions tied to the change, not reasons to postpone every task until the entire site has been reviewed.
07
Retest the Live Result, Then Watch Search
A successful pre-release check does not establish that the correction is live. After deployment, repeat the test on the affected URLs and retain evidence that can be compared with the original finding. For a shared template, check representative pages and known exceptions rather than assuming a single passing URL covers the whole group.
Use the test that answers the issue. Recrawl links to confirm their destinations. Inspect rendered HTML for missing content. Follow the enquiry route when navigation or contact access has changed. A screenshot of a normal-looking page cannot establish that its crawl or rendering problem has been resolved.
Keep implementation verification separate from search performance. You can confirm that a page now outputs the intended content without claiming that Google has already reprocessed it or that enquiries have increased. Search changes take time to appear, and a technical correction is not itself evidence of a commercial result.
Record unresolved findings too. If the original fault remains, reopen the issue with the new evidence. If it has changed into a narrower problem, revise the scope. If the behaviour was intentional, document that decision so the same warning does not repeatedly return as supposedly unfinished work.
Our technical SEO work includes developer-ready fix instructions or implementation, followed by release verification, crawl comparisons and Search Console monitoring. That is the relevant next step when the diagnosis is clear but the site still needs the correction shipped and checked.
08
Decide Whether You Need Diagnosis or Delivery
Before commissioning another audit, take a priority finding from the report you already have. Can the implementation team reproduce it? Is the affected scope clear? Does someone own the change, and is there an agreed way to accept it?
If those answers are missing, ask for the diagnosis and brief to be completed. If they are present, another inventory may add less value than implementing the existing roadmap. Where the cause of declining visibility or weak enquiries remains unclear, a broader audit can help distinguish technical access from content and visitor-path problems.
The practical test is not whether the report looks comprehensive. It is whether the next decision becomes easier and the resulting work can be verified. Tell us what dropped and when if you need that diagnosis. If you already have a confirmed technical issue, bring the crawl and affected pages before the next template change so the discussion can focus on the fix rather than restarting the audit.