Deduplicating Joins Across Citation, Referral, and CRM Data
Website owners comparing citation reports with referrals and customer relationship management (CRM) outcomes need to keep the three record types separate. A…
Categories
What to Include in an SEO Audit That a Developer Can Act On
When a search engine cannot find or fetch an important page, or cannot understand or index it, a developer may need to change the site’s code, server settings, or templates. An SEO audit records what keeps search engines from handling those pages and gives the developer evidence to reproduce and fix each problem. Crawling means fetching pages; indexing means storing and assessing them for possible display in search results.
For each finding, a useful audit names the URL or page pattern, describes what happened and why it matters, and explains how to check the fix. A list of tool warnings alone does not tell a developer what to change or how to confirm the change worked.
Write findings as reproducible tickets
For every issue, state what the page should do and what it does instead. Include a representative URL and, if known, the affected page group. Record the test conditions and evidence. Evidence may include an HTTP status or redirect destination. It may also include a page directive, rendered content, or a Search Console result. Then explain the likely search or user consequence without claiming an unmeasured ranking or traffic loss.
End with a proposed fix and a clear way to confirm it worked. For example, a redirect ticket should name the source URL and where it currently leads, state where it should lead, and explain how to check the corrected redirect. Identify whether the fix belongs in code or needs a change to the content management system, hosting, or content. If the evidence does not show the cause, state what still needs investigation.
Check how search engines discover and process pages
Google finds pages, crawls them, renders their content, and decides whether to index them in separate stages. A page listed in a sitemap, for example, has not necessarily been crawled or indexed. Use the evidence to identify which stage has a problem instead of reporting only a generic “SEO error.” Google explains these stages in its description of how Search works.
| Check | Evidence to record | What to ask the developer to verify |
|---|---|---|
| Internal links | Whether important pages have links that crawlers can follow in the rendered page | Link to priority pages with standard <a> elements that include an href. Google describes these as crawlable links in its link guidance. |
| Access and index directives | The robots.txt rules, page-level noindex directives, and X-Robots-Tag response headers |
Check that crawling is allowed where Google needs to read the page or its noindex directive. Blocking a URL in robots.txt does not ensure that Google removes it from search. |
| Responses and redirects | HTTP status, redirect chain and final destination; note if an error page returns 200 |
Correct unexpected destinations, loops, and chains. If content has been removed, check whether the URL should return 404 or 410, or redirect to a genuinely relevant replacement. A mostly empty or error-like page that returns 200 can be treated as a soft 404. See Google’s crawling error guidance. |
| Rendered content | Whether the main content, links, and page directives appear in the rendered page | Compare the initial HTML with Google’s rendered view. Fix missing or inconsistent output where it affects important content. JavaScript alone does not establish a defect; the evidence is what Google can access and render. |
| Canonical URLs | The page’s canonical tag, redirects, internal links, sitemap entries, and Google-selected canonical where available | Align conflicting signals so they point to the intended URL. A canonical tag signals a preference; Google can select a different representative URL. Google explains canonical selection. |
| Sitemaps | Whether the sitemap loads and lists the intended canonical URLs | Correct generation rules for missing, redirected, or non-canonical URLs. A sitemap supports discovery but does not guarantee indexing. Its absence alone is not necessarily a defect, especially for a small, well-linked site. |
| Performance and structured data | Relevant field performance data, page-level diagnostics, and structured-data validation results | Describe the measured page or template problem and the intended correction. Valid structured data can make a page eligible for a search feature, but it does not guarantee display. |
For pages that use JavaScript, compare the HTML the browser first receives with the page after it renders. Google describes its rendering process in the JavaScript SEO documentation. That documentation does not show how every search engine or other crawler handles the same page.
Use evidence that matches the performance question. Core Web Vitals measure loading, responsiveness, and visual stability. Google’s current “good” thresholds are LCP at or below 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. Field data records real-user experiences and shows which pages or groups are affected. Use a lab test to investigate a cause you can reproduce. Google recommends good Core Web Vitals, but a single fix does not guarantee a ranking gain.
Separate a current test from Google’s stored view
Search Console’s URL Inspection tool provides two kinds of evidence. The indexed view shows what Google recorded the last time it processed the URL. The live test checks the page as it is available now, but checks fewer things. A successful live test does not prove that Google indexed the page or chose the intended canonical. Compare the two views and record the last crawl information when available. Google explains the differences in its guidance on inspecting and troubleshooting a page.
Search Console reports have limits. The Performance report leaves out some queries because of privacy and other reporting constraints. Its query rows therefore do not show every search that brought people to the site. Use the rows as evidence of reported activity, not as a complete picture of demand. The report’s data documentation describes these limits.
Check the audit’s input data before accepting its conclusions. In a snapshot dated November 11, 2026, an export for eight US-English Google queries returned 65 organic result rows. Of those, 63 had Google redirect-wrapper URLs instead of direct destination URLs. Those unresolved URLs did not show whether the destination pages overlapped. The supported conclusion was that the available fields could not establish destination overlap, not that the query pairs had no overlap. This dated snapshot does not show how often wrappers appear across Google results or measure ranking performance.
Prioritize fixes by scope and consequence
Prioritize problems that block crawling or indexing of important pages over minor template inconsistencies, and show the evidence for that priority. One affected URL does not prove the problem affects the whole site. If a shared template, redirect rule, or robots directive affects many pages, describe the pattern and explain how you measured its scope.
Separate confirmed behavior from expected impact. “The page returns noindex” is a verifiable finding. “The page has lost traffic because of noindex” requires separate evidence. Include dependencies such as a hosting change or content decision so the developer knows who must act, and avoid promising a particular ranking, traffic, or revenue result.
After the developer makes a fix, test the same URL under the same conditions you used to document the problem. Check Search Console again after Google has had time to recrawl and process the page. Asking Google to index a URL does not guarantee that Google will include it.
Keep AI search checks tied to the same foundations
Google says a page must be indexed and eligible to appear in Search with a snippet before it can be considered as a supporting link in AI Overviews or AI Mode. Google also says these features have no extra technical requirements or special optimization. Check the same access, rendering, indexing, and content conditions described above. Do not promise that a fix will earn an AI citation. See Google’s guidance on AI features and websites.
Key Takeaways
- Document reproducible evidence: Give each finding a URL or page pattern, observed behavior, test conditions, and a clear way to verify the fix.
- Trace the failure stage: Distinguish discovery, crawling, rendering, indexing, and canonical selection so the developer addresses the actual barrier.
- Compare live and indexed evidence: A successful current test does not prove that Google has indexed a URL or selected the intended canonical.
- Treat reports within their limits: Search Console omits some query data. Unresolved redirect URLs also cannot support destination-overlap conclusions.
- Keep impact claims grounded: Report the defect and its plausible mechanism; claim traffic or ranking effects only when separate evidence supports them.
What I'm buildingDelegate tasks. Get software.
Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.
Take a look at vroni.com