Complete Website Audit Guide: SEO, Link-in-Bio, Portfolio, Blog, Performance and More

1. Technical SEO: can search engines reach your pages?

Start with the basics a crawler sees before it reads a single word.

• One address per page. http://, https://, www. and the bare domain should all end up at one version, and pages should consistently use (or not use) a trailing slash.
• Canonical links. Every page should have a <link rel="canonical"> pointing to its preferred address. Google treats it as a strong hint about which URL to show.
• Status codes. Real pages return 200, moved pages 301, missing pages a real 404 (not a 200 "not found" page). Avoid redirect chains.
• A proper 404 page that helps people find their way back.
• No accidental `noindex` on pages you want in search.

How to check: run curl -I https://yoursite.com/some-page/ to see status codes and redirects, use View Source to look for the canonical tag, and use the URL Inspection tool in Google Search Console.

On my own site: no canonical links anywhere, www.victorxai.com served a full duplicate copy of the site instead of redirecting, and missing pages showed my host's plain error page.

2. Content and metadata: does each page describe itself?

• A unique title on every page, roughly 50–60 characters, with the most important words first. Google cuts longer titles off.
• A unique meta description, roughly 150–160 characters, that tells people what they'll get. Google sometimes rewrites it, but a good one is often used as-is.
• One `<h1>` per page that matches what the page is about, then <h2>/<h3> in a logical order.
• Share previews: Open Graph and Twitter/X tags with a title, description and a 1200×630 image. Use JPEG or PNG: some platforms don't reliably show WebP or SVG.

How to check: View Source, a browser SEO extension, or paste your link into a messaging app to see the preview.

On my own site: six pages shared exactly the same description, three post titles were over 80 characters, and the <h1> on every page was my name in the sidebar, not the page's own title. My blog covers were WebP and SVG, so some platforms showed no preview image.

3. Indexing and sitemap: are you telling search engines what exists?

• robots.txt at the root, allowing what should be crawled and pointing to your sitemap. robots.txt controls *crawling*, not indexing: to keep a page out of search, use a noindex tag instead.
• An XML sitemap listing every page you want indexed, using canonical addresses only. Generate it from your content so new posts are added automatically. Google uses lastmod when it's accurate and ignores priority and changefreq.
• Utility pages kept out: thank-you pages, previews and admin areas should be noindex.
• Search Console and Bing Webmaster Tools: add your site and submit the sitemap. This is the only way to see what's actually indexed.

On my own site: /robots.txt and /sitemap.xml both returned 404, and my form's thank-you page could be indexed.

4. Structured data: help search engines understand who and what

Structured data (JSON-LD) describes your content in a format machines read directly.

• Person (or Organization) on your home or about page: your name, the names you're known by, your job title and your social profiles.
• BlogPosting on each article: headline, date, image and author.
• BreadcrumbList on deeper pages: Home › Blog › Post.

Only describe what's visible on the page. Never add fake ratings, reviews or achievements. That breaks Google's guidelines and can get your structured data ignored.

How to check: Google's Rich Results Test and the Schema Markup Validator.

On my own site: none at all. I now use it to connect my full name, Okikioluwa Victor Olarewaju, with "Victor Okiki" and VictorXAI, so search engines know they're the same person.

5. Performance and Core Web Vitals: does it load fast for real people?

Google's Core Web Vitals, measured at the 75th percentile of real visits:

• LCP (Largest Contentful Paint): 2.5 seconds or less.
• INP (Interaction to Next Paint): 200 milliseconds or less.
• CLS (Cumulative Layout Shift): 0.1 or less.

What to check:

• images sized for how they're displayed, in modern formats, lazy-loaded below the fold, with width and height set;
• the main above-the-fold image or heading loading first;
• unnecessary JavaScript, third-party scripts and heavy libraries;
• fonts loaded efficiently;
• compression and caching headers.

How to check: PageSpeed Insights shows both lab results (Lighthouse) and field data from real Chrome users, if your site has enough traffic. Treat lab scores as a guide and field data as the truth.

On my own site: the tech-stack icons on my home page were up to 2560 pixels wide for 40-pixel slots, about 750 KB of wasted download. Resizing them to 120 pixels cut each one to around 5–12 KB.

6. Link-in-bio essentials: your hub should be fast and trustworthy

A link-in-bio page is often the first thing people see from your social profiles.

• Clear identity: your photo, name and what you do, at a glance.
• The most important links first, grouped logically (featured, businesses, writing, contact).
• Every link tested. Dead links on a hub page look careless. Hide anything that's down.
• Fast and mobile-first, with big tap targets and no heavy animations.
• A good share preview, because the link itself gets shared.
• One official address. If the same page lives on two domains, set the canonical to the one you promote.

On my own site: my links page lived at both victorxai.com/links/ and builtbyvic.com, which search engines see as duplicate content. builtbyvic.com is now the canonical address. One partner site's link was also down, so I flagged it.

7. Portfolio and blog: make your work findable and credible

Project pages should explain the problem, your role, the approach, the technologies and verified results. Be clear about what's live, in progress or confidential, and credit collaborators.

Blog posts should have:

• permanent, readable URLs;
• a visible date and author;
• readable code blocks and images with alt text;
• links to related posts and projects;
• an RSS feed for readers who follow blogs that way;
• one place to set SEO details, so publishing doesn't mean editing metadata in several files.

On my own site: posts had no visible author, there was no RSS feed, and SEO details were set differently on each page. I moved them into one shared helper, so every new post gets its canonical link, share preview and structured data automatically.

8. Security and privacy: close the doors you didn't know were open

Even a static site has a security surface.

• No secrets in the frontend or in git. Check build output and history, not just current files.
• Security headers: HSTS, X-Content-Type-Options: nosniff, a Referrer-Policy, framing protection (X-Frame-Options or CSP frame-ancestors) and a Permissions-Policy.
• Directory listing off. Visit /images/ or /assets/ on your own site.
• No source maps, debug pages or test routes exposed in production.
• Form spam protection, such as a honeypot field, rate limits or a CAPTCHA where needed.
• Privacy: a privacy policy that matches what you collect, and consent where required.

How to check: securityheaders.com, curl -I, and browsing your own folders.

On my own site: this was the most serious finding. Directory listing was switched on, so anyone could browse my /images/, /cv/ and /_next/ folders as file lists. There were no security headers, and my forms had no spam trap.

9. Accessibility: can everyone use it?

Aim for WCAG 2.2 level AA:

• Keyboard: every control is reachable with Tab and shows a visible focus style.
• Names: every button, link and form field has a clear name (visible text or an aria-label).
• Contrast: 4.5:1 for normal text and 3:1 for large text and controls.
• Tap targets: at least 24×24 pixels.
• Alt text: describe meaningful images and use alt="" for decorative ones.
• Forms: clear labels and error messages.
• Mobile: no sideways scrolling at any width.

On my own site: my sidebar social icons were 18-pixel tap targets, now 32. The headline on my link-in-bio page was drawn as a shape with no readable text, so I added text for screen readers and search engines.

10. Testing and maintainability: will it stay working?

• Type checks, linting and a production build pass with no errors.
• Broken-link check across internal and external links.
• Browser console free of errors on every page.
• Forms tested end to end, including failure states.
• Dependencies up to date, with nothing unused.
• Work committed to version control, so you can roll back.

On my own site: checks and build passed and there were no broken internal links. But weeks of work were still uncommitted in git, which is a backup risk worth fixing before anything else goes wrong.

Run this audit with AI

You can have an AI coding assistant do most of the inspection. Ask it to look before it changes anything, to back every finding with evidence, and to be honest about what it couldn't check, such as live speed data or what Google has indexed.

Copy this prompt into Claude Code, Cursor or another AI coding assistant, opened in your project.

Act as a senior web engineer, technical SEO specialist, security reviewer and accessibility auditor. Audit this website's codebase. Inspect before you change anything.

About my site (fill this in):
- Type of site (portfolio, blog, link-in-bio, business site, store):
- Domain(s):
- Hosting and how it's deployed:
- Anything private that must stay out of search:

1. Explore first: identify the real framework, routing, rendering, build and deploy setup from the repo. Run the type check, linter and production build if available. Don't assume the stack.
2. Technical SEO: one hostname and protocol, trailing-slash consistency, canonical links, status codes and redirects, a real 404 page, accidental noindex.
3. Content and metadata: unique titles (about 60 characters) and descriptions (about 155), one h1 per page, heading order, Open Graph and Twitter tags with a 1200x630 JPEG/PNG image.
4. Indexing: robots.txt, an XML sitemap generated from the content with canonical URLs only, noindex on utility pages, duplicate URLs across domains.
5. Structured data: Person/Organization, BlogPosting and BreadcrumbList JSON-LD that matches visible content. Never invent reviews, ratings or facts.
6. Performance: image sizes vs display size, formats, lazy loading, width/height, render-blocking and third-party scripts, bundle size, fonts, caching and compression. Separate lab results from real-user field data; don't invent scores.
7. Link-in-bio (if any): clear identity, link order and grouping, every link working, share preview, one canonical address.
8. Portfolio and blog: project pages explain problem, role, approach and results; posts have dates, author, related links, RSS, and SEO set in one place.
9. Security and privacy: exposed secrets (redact values in your report), security headers, directory listing, source maps or debug routes in production, form spam protection, privacy disclosures.
10. Accessibility: keyboard and focus, accessible names, contrast, tap targets of at least 24px, alt text, form labels, no sideways scrolling.
11. Testing and maintenance: broken links, console errors, form flows, dependency health, uncommitted work.

Deliver, in order:
A. A short, honest summary of the site's state and biggest risks.
B. A findings table: ID, severity (Critical/High/Medium/Low/Info), category, file and line, evidence, impact, fix, effort, how to verify.
C. A prioritised plan: security blockers, indexing blockers, high-impact SEO, performance and accessibility, then content growth.
D. The exact files to change and why.

Rules:
- Only report what you confirmed in code or by running something. List anything else as "needs checking".
- Don't claim the site ranks, is indexed, is secure or passes Core Web Vitals without evidence.
- Preserve the design and working features, and avoid rewrites and new dependencies where a small fix works.

After the report, wait for my approval, then fix the highest-priority items in small batches and re-run the checks.

After the fixes, deploy, then test the live site: headers, redirects, the 404 page, the sitemap, and your pages in Google's Rich Results Test and PageSpeed Insights. Then submit your sitemap in Search Console and give it a few weeks.