Website audit tools

The code itself doesn't determine the presence of an SEO error. A 301 response may be correct after the move, while a 404 response is normal for a permanently removed URL if there's no relevant replacement.

Code 200

A 200 OK response means the server successfully processed the request and is returning the page content. For a normal indexed document, this is the expected status.

However, a 200 status code doesn't confirm the correctness of all SEO settings. The page may still contain a noindex, an invalid canonical, or other parameters, so the HTTP check is supplemented by document analysis.

Codes 301 and 302

Code 301 is typically used for permanent redirects when the old address is replaced with a new one. Code 302 is used for temporary redirects when the original URL is to be restored.

When checking, it's important to see not only the status but also the target address. An erroneous redirect can send the user and search engine crawler to an irrelevant page or create an unnecessary clickstream.

Codes 404 and 410

A 404 response code indicates that the requested page was not found. A 410 response code indicates a deleted resource. These responses should be checked for URLs that are still being referenced by internal links, sitemaps, or external referrals.

If a deleted page has a similar replacement, a proper redirect may be required. Redirecting all deleted URLs to the main page without regard to content is not recommended.

5xx errors

5xx status codes indicate a server problem. If an important page regularly responds with this status, the search engine robot cannot reliably retrieve its content.

A single, temporary failure is different from a permanent error. If a 5xx error occurs repeatedly, you should check the server, application, proxy, database, and error log, and then retest the URL.

Redirect Checker

Redirect Checker shows whether a redirect is occurring and where the request ends up. This is useful when migrating a site, changing the URL structure, switching to HTTPS, and merging duplicates.

After mass changes, redirects should be checked selectively and systematically. An error in a single template rule can redirect hundreds of pages to incorrect addresses.

Redirect chains

A chain occurs when one URL redirects to a second, the second to a third, and the user only reaches the final page after several transitions. Such routes often persist after several successive migrations.

For internal linking, it's best to use the final URL directly. If the chain is formed from old redirects, it should be shortened where possible without disrupting the redirection logic.

Final URL

When checking a redirect, you need to look at the final URL and its HTTP response. The mere fact of a redirect doesn't guarantee the correct result: the final page may return a 404, a second redirect, or an irrelevant document.

Pages with organic traffic and external links are checked especially carefully. For these pages, an error in the final URL can immediately impact users, indexing, and the transmission of accumulated signals.

HTTP → HTTPS and www → non-www

Redirects between HTTP and HTTPS, as well as between www and non-www domain variants, help align URLs with the selected primary version. The specific domain variant depends on the project settings.

When checking, ensure that the transition occurs consistently, without loops or unnecessary intermediate addresses. Internal links should preferably point directly to the final HTTPS version of the URL.

Broken Link Checker

Broken Link Checker helps find links that lead to missing or technically inaccessible pages. A broken link impairs navigation and leaves search engines with a URL that doesn't contain the expected document.

This check is useful after deleting products, articles, categories, changing the structure, or migrating. Even if old pages are deleted correctly, internal links to them should be updated or removed.

Why do broken links need to be fixed?

Broken internal links disrupt the flow between related pages and create unnecessary requests to incorrect URLs. On a large site, such links accumulate due to regular content and structure changes.

The solution depends on the situation. You can replace the link with a current address, delete it if the transition is no longer needed, or set up a redirect from the old URL to a relevant new page.

Checking canonical and hreflang

Canonical and hreflang serve different purposes, but they often intersect on multilingual websites. Canonical specifies a preferred URL among similar documents, while hreflang links language or regional versions of a single page.

Errors in these elements can create inconsistencies. For example, the Ukrainian version of a page specifies a canonical to the Russian version while simultaneously declaring a separate hreflang. Such cases should be checked at the URL level.

Canonical Checker

Canonical Checker helps you see the canonical URL of a page and verify that it matches the expected site logic. For a unique indexed document, self-canonical is often used, but other schemes are possible.

Canonical is considered a signal by search engines. Therefore, it must be consistent with redirects, sitemaps, internal links, and the actual URL structure.

Self-canonical

Self-canonical means that the page specifies its own canonical URL. This option is often used for primary indexed URLs to clearly indicate the preferred version of the document.

After changing your domain, protocol, or structure, it's worth checking whether the canonical tag has been updated. The old address in the tag may remain after the migration and send the wrong signal to search engines.

Canonical to another URL

A canonical to a different address may be correct for a duplicate or alternative technical version of a page. The problem arises when a unique landing page accidentally links to another document.

If this error occurs, the search engine may choose a different URL as the canonical one. Therefore, the target URL must be checked alongside the page's content and its role in the site's structure.

Canonical and duplicate pages

Duplicates can occur due to GET parameters, filters, sorting, URL variations, and CMS features. Canonical helps designate the primary version, but it doesn't replace proper website architecture.

If there are a lot of duplicates, you need to analyze the reasons for their occurrence. Sometimes it's better to change link generation, eliminate technical combinations, or set up redirects, while leaving canonical links as an additional signal.

Hreflang Checker

Hreflang Checker is essential for multilingual and multiregional websites. It helps verify which alternative versions are specified for a page and whether they are correctly linked.

For Seo-Gen, this check is especially useful for projects with Russian, Ukrainian, and English versions. Each page should link to the corresponding language alternatives, and the URLs should match the expected status.

Language versions of the page

Hreflang links pages with the same purpose but different languages or regions. The Ukrainian version of a service should link to its Ukrainian URL, the Russian version to its Russian URL, and the English version to its English URL.

When checking, you should look not only at the language code but also at the URL itself. Errors often occur when a template substitutes the URL of another page or the old structure after migration.

Reciprocal hreflang links

The relationship between language versions must be reciprocal. If a Ukrainian page lists a Russian version as an alternative, the Russian version must correctly link back.

After adding a new language, these links sometimes remain incomplete. Therefore, it's best to check the entire set of language versions of a single page at once, rather than just a single tag in the source code.

x-default

The x-default value is used for a page that is appropriate for users when no specific language or regional version is selected. Its use depends on the project architecture.

X-default should be checked along with other hreflangs. The address must exist, be logical to the user, and not conflict with canonical URLs or redirects.

PageSpeed and Core Web Vitals Checker

PageSpeed and Core Web Vitals Checker help evaluate page performance and user experience metrics related to rendering speed, responsiveness, and visual stability. This check is useful after redesigns, implementing new scripts, changing images, and updating the frontend.

Poor performance requires a technical analysis of the cause. The problem could lie in images, JavaScript, server responses, CSS, fonts, or third-party integrations. A single numerical result isn't enough: you need to understand which part of the page is causing the delay.

What does a speed test show?

A speed test helps you see page loading and technical metrics. These are used to compare URL performance before and after optimization, identify weak spots, and validate the developer's work.

When analyzing, it's important to consider the page type. A complex product page, a landing page with many interactive elements, and a simple informational article all have different structures, so the causes of slowdowns vary.

Core Web Vitals

The core web vitals include LCP, INP, and CLS. These metrics describe different parts of the user experience and are assessed separately, so improving one metric does not guarantee good results for the other two.

Technical optimization first involves identifying the specific element or process that's impacting the performance. After fixing the issue, the page is retested, preferably under the same conditions.

LCP

Largest Contentful Paint shows how quickly the main, large element in the visible area of the page appears. This is often the main banner, a large image, or a large block of text.

LCPs can be affected by server response time, image loading, CSS, fonts, and resource loading order. Therefore, fixing them begins with identifying the specific LCP element.

INP

Interaction to Next Paint characterizes the page's responsiveness as the user interacts with the interface. A high value may be due to heavy JavaScript tasks or event handlers.

This check is especially important for websites with filters, calculators, drop-down menus, forms, and other interactive components. After script optimization, the metric should be re-measured.

CLS

Cumulative Layout Shift measures the visual stability of a page. If elements shift noticeably during loading, users may accidentally click the wrong button or lose their reading position.

The cause is often images without specified dimensions, or late loading of banners, fonts, or dynamic blocks. Fixing this requires addressing specific layout elements.

Why do I need to look at metrics separately for mobile devices?

A mobile device typically operates under different conditions: fewer computing resources, a more unstable connection, and a smaller screen. Therefore, a page that loads quickly on a desktop computer may noticeably lag on a smartphone.

Mobile version testing is especially important for projects where the majority of search traffic comes from phones. Optimization should be based on actual page issues, and then metrics should be re-measured.

CMS Detector – How to identify a website's CMS

CMS Detector helps identify a website's content management system based on its technical characteristics. This check is useful before an audit, project migration, development assessment, or preparing a technical specification.

Knowing your CMS helps you quickly understand potential limitations and typical project structures. WordPress, OpenCart, Shopify, custom CMSs, and other platforms handle URLs, templates, extensions, and utility files differently. However, final conclusions should still be made after a technical analysis of the specific website.

How is CMS defined?

The definition of a CMS is based on publicly accessible characteristics that a website transmits during normal access. These may include characteristic HTML elements, resource structure, technical paths, and other data accessible without logging into the administrative panel.

Not every website can be identified unambiguously. The developer may modify the standard structure, hide distinctive features, or use a proprietary platform. In such cases, it's more accurate to demonstrate a lack of reliable results than to specify a CMS without sufficient justification.

What SEO errors should you fix first?

Priority depends on the impact of the issue on the page's accessibility and indexing. If the URL returns a server error or is accidentally closed with noindex, addressing the meta tags and text won't resolve the underlying cause.

First, they fix the issues that prevent search engines from retrieving the desired page. Then they move on to structural errors and technical signals, followed by performance and additional on-page optimization.

Critical issues

Critical situations include situations where an important page is unavailable, returns a persistent server error, is closed from indexing by mistake, or redirects the user to an incorrect document.

It's best to check for such issues immediately after a release and technical changes. If the error affects a template, determine the scope and check multiple URLs of the same type.

High importance errors

This group includes incorrect canonical, broken internal links, incorrect hreflang, and sitemap issues if they affect important indexed pages.

Fixing begins with checking the template and data source. A similar error on dozens of pages usually requires a system-wide fix, rather than manually changing each URL.

Optimization problems

Once blocking errors are resolved, you can work on speed, Core Web Vitals, meta tags, and other on-page parameters. Their impact depends on the page's state and the query's competitiveness.

It's best to prioritize based on site data. A page with high traffic and poor performance is usually more important than a technical URL that barely registers in search results.

When is a separate tool sufficient, and when is a full site audit necessary?

A dedicated tool is suitable when the problem is local and clear. For example, you need to check a single redirect, find the page's HTTP code, determine the canonical URL, or verify that a new URL has appeared in Google. This format saves time and provides a specific technical answer.

A full SEO audit is necessary in the event of a decline in organic traffic, migration, CMS change, major redesign, or a large number of related errors. In these cases, it's necessary to analyze the site's architecture, indexing, internal links, content, technical parameters, and external factors together.

Who will benefit from Seo-Gen tools?

These tools are designed for professionals who regularly need to check individual URLs and website technical parameters. The tasks are equally familiar to SEO specialists, developers, project owners, and agencies, although each uses the results differently.

The main advantage of targeted testing is the ability to quickly move from a symptom to a specific parameter. However, complex issues still require root cause analysis and cross-page linkages.

For SEO specialists

An SEO specialist can quickly check indexability, meta robots, canonical, hreflang, redirects, and HTTP responses without manually reviewing each technical element.

These checks are especially useful when accepting developer tasks and after publishing changes. The results can be compared with the specifications and immediately see whether the working page meets the expected state.

For developers

For developers, these tools are useful after changes to routing, server configuration, templates, and multilingual support. They help validate the results from the perspective of a search engine crawler and the actual HTTP response.

After the release, you can test the main URLs, ensure that redirects, robots.txt, sitemap, canonical, and hreflang are correct, and then fix any discrepancies found.

For website owners and marketers

A website owner doesn't need to manually parse the source code to perform an initial page check. They can check the HTTP status, indexing, speed, or any technical restrictions.

The result helps the developer or SEO specialist more accurately formulate the task. Instead of the statement "the page has disappeared from Google", specific information about the URL parameters appears.

For agencies

Agencies regularly work with projects across various CMSs and tech stacks. Quick checks are convenient for initial analysis, acceptance of improvements, and post-release website monitoring.

Separate tools also help recheck questionable URLs without running a large crawler. For large-scale audits, they complement professional scanning systems rather than replace an analysis of the entire project structure.

What does an on-page SEO analysis show?

If the results show a questionable parameter, it should be checked separately. For example, an incorrect canonical requires Canonical Checker, a problem with the server response requires HTTP Status Checker, and a possible indexing ban requires meta robots and indexability checks.

Title, Description, and H1

Title, description, and H1 help search engines understand the topic of a page, and users evaluate its content even before clicking through search results. When checking, you should check for the presence of these elements, their relevance to the page, and the absence of obvious contradictions between the document title and the main content.

Duplicate meta tags across multiple pages complicates proper optimization, especially for categories, services, and geo-pages. A title that's too long or meaningless also requires review. However, length alone shouldn't be assessed separately from the search intent and purpose of the page.

Technical SEO parameters

Technical SEO parameters indicate whether the search engine robot is receiving the expected version of the document and whether there are any service instructions that contradict the page's purpose. URLs that have been recently created, moved, closed for development, or have had their address changed are especially closely checked.

If a potential SEO error is detected, it's best to perform a specific check. Indexability, meta robots, canonical, HTTP code, and hreflang are all interconnected, but they handle different processes. Separate diagnostics help identify the cause, rather than limiting yourself to a general problem report.

Links and page structure

An internal link conveys the path to another document on the site to the user and search engine crawler. Incorrect URLs, links to deleted pages, and unnecessary redirect chains impair navigation and complicate crawling. Therefore, links should be checked after moving, changing the URL structure, and deleting sections.

External links also require monitoring if they lead to unavailable resources. When checking, the final HTTP status of the page is important, not just the presence ofhrefin the source code. A separate Broken Link Checker is used to detect such issues.

When to use on-page SEO analysis?

An on-page SEO analysis is useful before launching a new landing page, after making SEO changes, and before handing over a task for review. It's also useful after updating the CMS, changing meta tag templates, moving a page to a new URL, or changing the heading structure.

A re-check is necessary after making corrections. If the developer has changed the canonical, meta robots, or redirect, the results should be verified on the live site. For technical SEO, the actual page response the robots receives after publishing is important, not the settings specified in the developer's task.