Full SEO Audit: Crawl Your Site, Find Every Issue and Fix It Safely

A full SEO audit is a systematic check of everything that decides whether search engines can find, understand and trust your website: whether pages can be crawled and indexed, whether titles and descriptions are in order, whether content is thin or duplicated, how fast pages load for real visitors, whether structured data is valid, how pages link to each other, and whether the site is secure, mobile-friendly and ready for international and AI-driven search. The goal is not a pretty number. The goal is a clear, prioritised list of real problems, each one tied to the exact page and the exact element that causes it, with an honest explanation of why it matters and how to fix it.

Rutba runs this kind of audit for you. Its crawler visits your site the way a search engine bot would, respects your robots.txt, and then runs 84 audit rules across ten categories. You get a site health score out of 100, a score per category and per page, every issue sorted by severity, the precise places where each problem appears, a forecast of how many points each fix would add to your score and how much effort it takes, and a direct path from the issue to a safe fix in the Fix Center. Audits repeat automatically depending on your plan, so you can see which issues are new and which you have already fixed.

One thing needs to be said up front, because many tools blur it: the health score is Rutba's score, not Google's. Google does not use any third-party score, and nobody outside the search engines decides rankings. What a good audit does is remove the technical and on-page obstacles that stop good content from being found and shown properly. This guide explains what an SEO audit covers, how to do one by hand, and exactly how Rutba does it.

What an SEO audit is, and what it is not

An SEO audit is a diagnosis. It compares the current state of a website with the published guidance of the search engines (Google Search Central, Bing Webmaster Guidelines) and with well-established web standards (HTML, HTTP, Schema.org, hreflang), and it reports every gap it can measure.

A complete audit has three layers:

1. Discovery. A crawler starts at the homepage, follows internal links, reads the XML sitemap and records every URL it finds: its HTTP status, redirects, headers, HTML content and links.
2. Evaluation. A set of rules is applied to the collected data. Some rules look at a single page (does it have a title?), others look at the whole site (is the same title used on several pages? does robots.txt block Googlebot?).
3. Prioritisation. Findings are ranked by how much they hurt, how many pages they affect and how much work they need, so that you fix the things that matter first.

What an audit is not:

• It is not a ranking report. An audit tells you what is broken or weak on your site. Where you rank for a keyword is a separate question, answered by real search data such as Google Search Console.
• It is not a guarantee. Fixing every issue does not guarantee a position. Search engines weigh hundreds of signals, including the quality and relevance of your content and how other sites refer to you.
• It is not a checklist of myths. Some popular "SEO checks" have no effect on rankings at all (for example the meta keywords tag, or how many years a domain is registered for). A good audit labels low-impact items honestly instead of inflating them.

Why a technical SEO audit matters for search and for business

Search engines can only rank pages they can reach, render and understand. A single misconfiguration can undo months of content work. A "discourage search engines" checkbox left on after a site launch, a robots.txt rule that blocks the whole site, a homepage accidentally marked noindex, a redirect loop after a theme change: these problems are silent. Your site looks fine to visitors, but search engines are told to stay away.

Smaller problems add up in a different way. Duplicate titles make it harder for Google to tell pages apart. Missing meta descriptions mean Google writes its own snippet, which may not sell your page. Orphan pages, which no other page links to, are discovered late and get no internal link value. Slow server responses reduce how many pages a crawler fetches and frustrate visitors. Broken internal links waste both crawl effort and user trust.

For a business the cost is concrete:

• Lost visibility. Pages that cannot be indexed cannot bring traffic, no matter how good they are.
• Lost conversions. A slow, unstable or insecure page loses visitors before they read your offer.
• Wasted effort. Writing new content while technical problems block the old content is like filling a bucket with a hole in it.
• Risk after every change. Plugin updates, redesigns and migrations regularly introduce new problems. Without regular audits, you find out weeks later when traffic drops.

A regular audit turns all of this into a visible, measurable list. You know what is wrong, where, and in what order to fix it.

Common problems an audit uncovers, and their causes

Most sites, small or large, run into the same families of problems. Knowing their typical causes helps you fix them at the source instead of one page at a time.

Crawling and indexing problems

• Pages returning 4xx or 5xx errors. Usually deleted content that is still linked, a changed URL structure without redirects, or an overloaded server.
• Redirect chains and loops. Created when old redirects are stacked on top of new ones over the years, or when HTTP-to-HTTPS and www rules contradict each other.
• Temporary redirects (302) used for permanent moves. Common after migrations done in a hurry.
• noindex in the wrong place. A homepage or important page marked noindex by a theme setting, a plugin or a staging configuration that was copied to production.
• robots.txt mistakes. A robots.txt file that blocks the whole site, returns a server error, or does not point to the sitemap.
• Sitemap problems. No sitemap, a sitemap that cannot be read, a sitemap that lists redirected or noindex URLs, or indexable pages that are missing from it.
• Canonical problems. Missing canonicals, an HTTP canonical on an HTTPS page, or a canonical that points to a page that cannot be indexed.

On-page problems

• Missing, duplicate, too short or too long titles, often produced by templates that repeat the site name or category name.
• Missing or duplicate meta descriptions.
• Pages without an H1, or with headings that jump levels.
• More than one SEO plugin active at the same time, printing conflicting tags.
• Incomplete Open Graph tags, so shared links look poor on social networks.

Content problems

• Thin pages with very little text, often tag pages, empty categories or placeholder pages.
• Duplicate content, where several URLs show the same text.
• Images without alt text, which hurts accessibility and image search.
• A page language that does not match the site language.

Performance and mobile problems

• Slow server responses caused by missing caching, weak hosting or heavy plugins.
• Very large HTML documents produced by page builders.
• Images without width and height, which cause layout shifts.
• Missing or non-responsive viewport settings.

Link and structure problems

• Broken internal links, links to redirected URLs, nofollow on internal links.
• Pages buried too deep, requiring many clicks from the homepage.
• Generic or empty anchor text ("click here", image links without alt).
• Dead-end pages that link nowhere.

How to audit a website manually, step by step

You can audit a small site by hand. It takes time, but it teaches you what the automated tools are actually measuring.

1. Check that the site is indexable at all. Open yourdomain.com/robots.txt and read it. Make sure there is no Disallow: / for all user agents. In WordPress, check Settings, Reading, and confirm that "Discourage search engines from indexing this site" is not ticked.
2. Check the homepage source. View the page source and search for noindex. Check that there is one <title>, a meta description, a canonical link, a lang attribute on the <html> tag and a viewport meta tag.
3. Find your sitemap. Look for a Sitemap: line in robots.txt or try /sitemap.xml and /sitemap_index.xml. Open it and make sure it loads and lists your important pages.
4. Test HTTPS and redirects. Type the http:// version of your domain and the version with and without www. All of them should land on one HTTPS version in a single redirect.
5. Walk through the main pages. For each important page, note the HTTP status, the title length, the description, the H1, the word count and whether images have alt text.
6. Look for duplicates. Compare titles and descriptions across pages in a spreadsheet. Repeated values are a sign of template problems.
7. Check internal links. Click through menus and in-content links. Note any 404s and any links that redirect.
8. Measure speed. Run your homepage through Google PageSpeed Insights, on mobile and desktop. Read both the lab test and, if available, the field data from real Chrome users.
9. Validate structured data. Use Google's Rich Results Test or the Schema Markup Validator on your key templates (homepage, article, product).
10. Check international settings. If you have several languages, check that every hreflang link points to a page that links back, that language codes are valid, and that an x-default exists.
11. Prioritise. Sort what you found: first anything that blocks indexing, then errors that affect many pages, then improvements.
12. Repeat after changes. Every redesign, migration or major plugin update deserves a fresh check.

This works for ten pages. For hundreds or thousands of pages, and for repeating it every week, you need a crawler and a rule engine. That is what Rutba provides.

How Rutba's crawler works

Rutba's audit starts with its own crawler, built into the platform. It is designed to run reliably on ordinary hosting: the crawl is split into short, time-boxed steps whose state is stored in the database, so a long crawl survives worker restarts and continues where it stopped.

Where the crawler finds your pages

Before it fetches pages, the crawler prepares the audit:

• it checks that the homepage can be reached;
• it reads your robots.txt;
• it reads your XML sitemaps, including those declared in robots.txt;
• it checks for an llms.txt file;
• it tests whether the HTTP version redirects to HTTPS and whether the www and non-www versions are consistent;
• on WordPress sites connected with the Rutba connector plugin, it takes a snapshot of relevant settings and an inventory of your published content and media.

It then crawls breadth-first, one click depth at a time, starting from the homepage and following internal links. URLs known only from the sitemap or the WordPress inventory are queued as well, so pages that no link reaches are still found. That is how orphan pages are detected: they exist in your sitemap or content inventory, but no crawled page links to them. Click depth is real depth, measured by links, and a redirect does not count as an extra click.

For each page, the crawler records the HTTP status, response time, headers, title, meta description, robots directives, canonical, headings, word count, links, images, structured data and hreflang. When the crawl finishes, it counts how many crawled pages link to each page (inlinks), which the orphan and depth rules use.

Respect for robots.txt and an identifiable user agent

Rutba's crawler identifies itself as RutbaBot, with a user agent that includes a link explaining what it is. It respects your robots.txt: a URL disallowed for RutbaBot is not fetched, and it is recorded as blocked rather than silently skipped. If you need to control the crawler, you can address RutbaBot in robots.txt like any other bot. The crawler also pauses briefly between requests so that it does not put pressure on your server.

A crawler that is safe by design

Any service that fetches URLs supplied by users must protect itself and others from abuse. Rutba sends every request through a hardened HTTP layer with SSRF protection:

• only http and https addresses are allowed;
• every host must resolve to public IP addresses, so private, loopback and link-local networks are blocked;
• redirects are followed one hop at a time and each new destination is checked again;
• only common web ports are allowed;
• responses have size and time limits.

These rules apply to the full audit, to the free SEO check on the public website, and to every other place where Rutba fetches a page.

An honest note on JavaScript

The crawler reads the HTML that your server sends. That covers the vast majority of sites, including WordPress and most CMS and e-commerce platforms. If a site builds its main content only with JavaScript in the browser, some content may not be visible in the HTML, and the audit can only judge what it sees. Server-side rendering remains the safest approach for search engines anyway.

The site health score and its ten categories

After the crawl, the audit engine evaluates every rule and computes three kinds of scores:

• an overall site health score from 0 to 100;
• a score per category, so you can see which area is weak;
• a score per page, so you can sort pages from worst to best.

The calculation is transparent. For each rule, Rutba measures the share of applicable pages that fail it (site-wide rules either pass or fail). Each rule has a weight based on its severity: critical issues weigh much more than warnings, and warnings more than notices; a few important rules carry double weight inside their severity. A category score is 100 minus the weighted share of failures in that category. The overall score is the weighted average of the category scores. Categories where no rule applied to your site are left out instead of counted as perfect.

The default category weights are:

The weights adapt to the type of site you choose:

• Online store: structured data gains weight (product rich results matter a lot) and content loses the same amount.
• Local business: the international and local category gains weight, because local signals live there.
• News site: performance gains weight and internal links lose the same amount.
• Blog and business site: use the default weights.

The total always stays at 100%. In the dashboard, each category shows its score and its weight, so you can see why a weak category moves the overall score more or less.

The rule set: 84 checks grouped by topic

Rutba's audit engine currently contains 84 rules. Each rule is a small, independent check with a stable key, a category, a severity, a short title, an explanation of why it matters and a recommendation on how to fix it. The explanations follow official guidance and say clearly when an item is a best practice rather than a ranking factor. The rules are organised in folders by topic:

• Crawlability (25 rules). Homepage blocked with noindex; robots.txt blocking Googlebot from the whole site; robots.txt returning a server error, missing, or not referencing the sitemap; pages returning 4xx or 5xx; redirect loops, chains and temporary redirects used for internal moves; noindex pages listed in the sitemap; pages blocked by robots.txt but linked internally; missing, unreadable or incomplete sitemaps and sitemaps listing non-indexable URLs; missing canonicals, HTTP canonicals on HTTPS pages and canonicals pointing to non-indexable pages; orphan pages; pages buried deeper than three clicks; URLs with parameters, uppercase letters or underscores, or more than 115 characters; and the WordPress "discourage search engines" setting.
• On-page (14 rules). Missing titles; duplicate titles; titles shorter than 30 or longer than 65 characters; missing, duplicate, too short or too long meta descriptions (70 to 160 characters is the recommended range); missing H1; several H1s; H1 identical to the title; skipped heading levels; incomplete Open Graph tags; more than one SEO plugin active; Rank Math active but not printing SEO tags; Rank Math settings that differ from the recommended setup.
• Content (4 rules). Thin pages (fewer than 300 words on inner pages, with a lower threshold for the homepage); text identical to other pages; very little text compared to the page code on large pages; page language different from the site language.
• Images (3 rules). Images without alt attributes; images without width and height; pages with many images and no lazy loading.
• Performance (4 rules). Server response slower than 1.5 seconds; HTML documents over 500 KB; Core Web Vitals that need improvement for real visitors; a low mobile lab score on the homepage.
• Schema (7 rules). JSON-LD with syntax errors; pages with no structured data; homepage without Organization, business or Person schema; homepage without WebSite schema; inner pages without breadcrumb schema; Article and Product schema missing required properties.
• Links (7 rules). Links to broken internal pages; internal links to redirected URLs; internal links with nofollow; links without anchor text; generic anchor text; pages with too many links; dead-end pages with no outgoing internal links.
• Mobile (2 rules) and Branding (1 rule). Missing viewport; a viewport that is not responsive or blocks zooming; a homepage without a favicon.
• Security (7 rules). No HTTPS; HTTP not redirected to HTTPS; mixed content; missing HSTS header; and, for connected WordPress sites, outdated WordPress core, unsupported PHP version and outdated plugins.
• International (7 rules). Missing lang attribute; missing character encoding; right-to-left pages without dir="rtl"; invalid hreflang codes; hreflang targets that do not link back; hreflang sets without the page itself or without x-default.
• AI search readiness (3 rules). AI search crawlers blocked in robots.txt; no policy for AI crawlers; no llms.txt file.

Rules that need the WordPress connector (such as outdated plugins, the search engine visibility setting or Rank Math output) only run when the connector is installed. Rules that do not apply to a page, for example Product schema checks on a page with no product, are not counted against you.

Multilingual and right-to-left sites

Sites in Arabic, Turkish or several languages often carry quiet errors that the browser hides. A translated theme may keep lang="en" on an Arabic page; the language mismatch rule compares the declared page language with the content language you set for the site and catches exactly that. Right-to-left pages without dir="rtl", pages without a declared character encoding, and hreflang sets with invalid codes, missing return links or no x-default are all reported with the precise URL involved. The URL length rule measures the readable form of the address, not its percent-encoded form, so a short Arabic or Turkish slug is not penalised just because it is encoded. Explanations are shown in your interface language, English, Arabic or Turkish, so a site owner and a developer can read the same finding in their own language.

Honesty is built into the rules themselves. A few examples of what the explanations say: word count by itself is not a ranking factor, but pages with only a few lines rarely satisfy searchers; several H1s are allowed by HTML5 and Google says they are not a problem, so this is a notice about clarity; HSTS is security hardening, not a ranking factor; llms.txt is an emerging, non-standard proposal that Google Search does not use, so it is optional. You get the facts, not fear.

Issues, severity and the exact place of every problem

The Issues tab of the audit is where you spend most of your time. Each failing rule appears once, with the number of pages affected (or "Whole site" for site-level rules).

Three severity levels

• Critical: blocks indexing or ranking, or breaks the site. Examples: homepage noindex, robots.txt blocking Googlebot, 5xx errors, redirect loops, missing title, missing viewport, no HTTPS.
• Warning: clearly hurts SEO. Examples: duplicate titles, missing meta descriptions, missing H1, slow server response, redirect chains, orphan pages, invalid JSON-LD.
• Notice: an improvement or best practice. Examples: title length, missing canonical, skipped heading levels, HSTS, llms.txt.

By default the list is sorted with the most severe issues first and, inside each level, by how many pages are affected. You can filter by severity and by category.

Where exactly

Expanding an issue shows three blocks:

1. Why it matters, in plain language, based on official guidance.
2. How to fix it, with concrete steps.
3. Where exactly, a list of affected pages with the precise detail of the failure: the current title and its length, the description that is too long, the broken link target, the redirect chain hop by hop, the image without alt, the hreflang target that does not link back, the invalid JSON-LD block, the response time in milliseconds. Site-level issues show the details instead, for example which AI crawlers are blocked or which Core Web Vitals metric is failing and at what value.

Affected pages load in pages of results, with a "Show more" button, so even an issue on thousands of URLs remains readable. Each URL opens in a new tab so you can check it yourself.

Issues that appeared since the previous audit are marked New. Issues that Rutba can fix automatically are marked Fixable and have a direct link: "Fix it in the Fix Center".

If your team has no active subscription, the full explanation and the list of affected pages are shown only for the most important issues, and the remaining issues are shown as locked with a link to the plans. The check itself is enforced on the server, not only in the interface.

Impact forecast: how many points a fix is worth, and how hard it is

Not every fix is worth the same. Rutba shows, next to each issue, an estimate such as "+3.2 points · Quick fix".

The number is not a guess. Rutba recomputes the exact scoring formula as if that rule were fixed on every affected page, and the difference from the current score is the gain. Because the stored score is rounded, the forecast uses the unrounded value, so gains below one point are not lost.

Effort comes in three levels:

• Quick fix: a one-click fix exists in the Fix Center.
• Medium effort: a normal change in your CMS or settings.
• Bigger job: work that needs content writing, development or hosting changes, such as thin or duplicate content, Core Web Vitals, slow server response, the move to HTTPS, hreflang return links, redirect chains or very large HTML.

You can sort the issue list by Best impact for the effort, which ranks issues by gain divided by effort. That gives you the classic "quick wins first" plan, calculated rather than guessed.

The interface says it clearly, and so do we: the points are Rutba's health score, not a promise of Google rankings.

The pages table and the audit history

Every crawled page in one table

The Pages tab lists every URL the crawler fetched. For each page you see:

• the title and the URL;
• the HTTP status, with a "noindex" mark on pages that load but cannot be indexed, and "Not fetched" for pages that could not be retrieved or were blocked;
• the page score;
• the number of issues found on the page;
• the word count;
• the number of internal links pointing to it (inlinks);
• the click depth from the homepage.

You can search by URL or title, filter to show only errors, only redirects or only non-indexable pages, and sort the table from the worst score to the best. This is the quickest way to find the pages that need attention first, or to check a specific section of your site. Response times are measured for every page, and pages slower than the threshold appear under the slow response issue with their exact value.

History, new issues and fixed issues

Every completed audit is stored. The audit summary shows:

• the current health score and the change since the previous audit;
• a score history chart across recent audits;
• how many issues are new since the previous audit and how many have been fixed;
• the number of pages crawled and how many are indexable;
• critical, warning and notice counts.

This turns SEO into a measurable process. After a round of fixes, the next audit shows the result: issues move from "open" to "fixed", the score updates, and new problems introduced by an update or a redesign are flagged as new instead of hiding among old ones.

PageSpeed Insights and Core Web Vitals after every audit

When an audit finishes crawling, Rutba runs Google PageSpeed Insights on your homepage for both mobile and desktop (when PageSpeed is enabled on the platform). The results feed both the performance rules and a Core Web Vitals card on the audit page.

The card shows:

• the lab performance score for mobile and desktop, from a simulated test;
• real-visitor data from the Chrome User Experience Report (CrUX) over the last 28 days, for the whole site (origin) or for the homepage, depending on what Google has;
• the biggest opportunities reported by the test.

If Google does not have enough real-visitor data for your site yet, the card says so and shows the lab test only. The Core Web Vitals rule only fires when real field data exists and a metric needs improvement; it reports which metric fails and its 75th percentile value. For reference, Google's "good" thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1.

Honest context: Core Web Vitals are part of Google's page experience signals. They are a real but modest ranking factor that matters most when competing pages are otherwise similar. Their larger effect is on visitors: slow pages lose readers and sales. Field data also changes gradually over 28 days after a fix, so do not expect the number to move the next day.

When and where the audit runs

Manual, scheduled and change-triggered audits

You can start an audit at any time from the site page with "Run a new audit". It runs in the background, so you can close the page; the panel shows the progress, the number of pages crawled out of your limit, and when the results are being analysed. You can also cancel a running audit.

Rutba also audits your sites automatically:

• Scheduled audits. Every verified site is re-audited after its plan's scan interval. The first audit starts right after verification.
• Change-triggered audits. On plans with real-time monitoring, events reported by the WordPress connector (content published, updated or deleted, plugins activated or deactivated, theme switched, search engine visibility changed) trigger a fresh audit. Edits are given time to settle first, so a burst of changes costs one crawl, and there is a minimum gap between two change-triggered audits of the same site.

Only one audit runs per site at a time. If a run stops responding, for example because the host restarted its workers, Rutba marks it as failed after a while so that a new audit can start, and the panel tells you the reason of the last failure in plain language. If the homepage cannot be reached at all, the audit stops early and says so instead of reporting hundreds of empty pages.

Crawl limits by plan

How many pages are crawled per site and how often automatic audits run depend on your plan. Higher plans crawl more pages per site and audit more often. See the pricing page for the current limits. Without an active subscription, an account stays usable, but audits run at a much longer interval, which also applies to manual audits.

WordPress sites and other sites

The audit works for any website you can verify, not only WordPress.

• WordPress with the Rutba connector. You get the deepest audit: the crawler adds your content and media inventory to the discovered URLs, and connector-only rules check the search engine visibility setting, Rank Math output and settings, conflicting SEO plugins, and outdated WordPress core, PHP and plugins. Fixes can then be applied safely through the connector.
• Any other site. You can verify ownership with a DNS record, a verification file or a meta tag. The crawler then audits the site from the outside with all the rules that do not depend on WordPress: crawling and indexing, on-page, content, performance, structured data, links, mobile, security, international and AI readiness. For sites that are not on WordPress, Rutba also offers a lightweight SDK that can apply approved head-level changes such as titles, descriptions, canonicals and structured data, described on the SEO fixes page.

An audit only starts on a verified site, which prevents anyone from using Rutba to crawl a site they do not own.

From the audit to the Fix Center and Rutba's other services

An audit that ends with a list is only half the job. In Rutba, the audit is the starting point for everything else.

• Fix Center. Issues marked "Fixable" have a one-click fix: missing or badly sized titles, missing or badly sized meta descriptions, missing image alt text, the WordPress "discourage search engines" setting, Rank Math settings and output, a missing sitemap and a robots.txt without a sitemap reference. Each fix is first proposed as a change you can review and edit, then applied only after approval. Learn more on SEO fixes.
• Safe changes. Every change goes through Rutba's safety engine: a restore point is created before the change, the result is verified after it, and anything that fails is rolled back automatically. After a fix, Rutba fetches the page again and re-runs the same audit rule to confirm the problem is really gone. See safe changes.
• Google search data. The audit tells you what is technically wrong; Google Search Console and Analytics tell you what is happening in search. Connecting them gives you real clicks, impressions and positions next to your audit. See Google search data.
• AI search visibility. The AI search readiness category checks whether AI search crawlers can reach you. The AI search visibility service goes further and measures whether AI assistants mention your site.
• Rutba AI. When an audit finds thin pages or missing descriptions, Rutba AI can help write improvements in your site's content language, always for your approval.

Optionally, on plans that include it, the SEO autopilot can apply selected fix types automatically after an audit, but only if you enable it for those action types.

Who the Rutba SEO audit is for

• Site owners and small businesses who want to know, in plain language, what is wrong with their site and what to do first, without learning a desktop crawler.
• Online stores that need product structured data, clean category pages and fast mobile pages; the store site type gives structured data more weight.
• Local businesses whose visibility depends on correct local and language signals.
• Bloggers and publishers with many articles, where duplicate titles, thin pages, orphan articles and deep pages accumulate over time.
• Agencies and freelancers who manage several client sites and need regular, repeatable audits, history and a clear list of fixes to report.
• Arabic, Turkish and multilingual sites, where lang, dir="rtl", character encoding and hreflang are frequent sources of quiet errors. The audit explanations are available in English, Arabic and Turkish.

Practical checklist and mistakes to avoid

A checklist for every audit

1. Confirm there are no critical issues: nothing blocks indexing, no 5xx errors, no redirect loops.
2. Check that the homepage is indexable and has a correct title, description, canonical and H1.
3. Make sure the sitemap is readable, lists only indexable pages and is referenced in robots.txt.
4. Fix broken internal links and update links that point to redirects.
5. Resolve duplicate titles and descriptions at the template level.
6. Give orphan pages links from relevant pages, or remove them if they no longer serve a purpose.
7. Review thin pages: expand, merge or noindex them.
8. Check the Core Web Vitals card and start with the slowest metric.
9. Validate structured data on your key templates.
10. Review your policy for AI crawlers so that it reflects a conscious choice.
11. Run a new audit after your fixes and compare new and fixed issues.

Mistakes to avoid

• Chasing 100 out of 100. A perfect score is not the goal. Fix critical and warning issues first; notices are good practice but rarely change rankings on their own.
• Treating every warning as urgent. Use the impact forecast and effort to plan, not panic.
• Fixing symptoms page by page. If fifty pages have the same title problem, the cause is usually a template or plugin setting.
• Blocking crawlers to "fix" errors. Disallowing a section in robots.txt hides it from crawlers but does not remove it from the index reliably and can create new problems; use the right status codes, redirects or noindex instead.
• Ignoring the audit after a launch or migration. The highest-risk moments for SEO are right after big changes.
• Believing myths. Meta keywords, domain registration length and exact keyword density are not ranking levers. Rutba does not pretend they are.
• Expecting instant ranking changes. Search engines need time to recrawl and reassess pages. Measure progress with repeated audits and real search data.

Getting started with your first audit

Try the free SEO check first

You can try the audit engine before you sign up. The free SEO check checks one public URL with the real audit rules, not a simplified imitation.

How it works:

• you enter an address; Rutba fetches robots.txt and then the page itself, following redirects one hop at a time;
• the same SSRF protection, size and time limits, RutbaBot user agent and robots.txt respect apply as in the full audit;
• the result shows a page score out of 100, a breakdown by category, the top issues on the page and what the page already does well.

The free check is honest about its limits. It examines one page, so rules that need the whole site, such as duplicate titles, orphan pages, sitemaps, click depth, broken links or Core Web Vitals, are skipped rather than counted as passed. The result says so and explains that the full audit checks your whole site. Abuse is limited per visitor and globally, without CAPTCHAs, and contact details are only stored if you explicitly agree.

Your first full audit in eight steps

1. Create your account on the sign-up page and start your free trial.
2. Add your site and choose its type (blog, store, business, news or local), which adjusts the category weights.
3. Verify ownership. On WordPress, install the Rutba connector plugin and pair it; on other sites, use a DNS record, a verification file or a meta tag.
4. Run the first audit. It starts automatically after verification, or you can start it from the site page. It runs in the background.
5. Read the summary. Look at the health score, the category scores and the critical issues.
6. Open the Issues tab and sort by "Best impact for the effort". Expand each issue to see why it matters, how to fix it and exactly where it occurs.
7. Fix. Use the Fix Center for issues marked "Fixable"; handle the rest in your CMS or with your developer.
8. Re-audit and compare. Run a new audit or wait for the scheduled one, then check the new and fixed issues and the score history.

Want to see the audit engine at work before you sign up? Run the free SEO check on any page of your site. When you are ready to audit the whole site, with history, impact forecasts and safe fixes, start your free trial and run your first full SEO audit with Rutba today.