Technical SEO audit: checklist and example

A website may open normally in a browser, accept orders, and yet still have technical errors that prevent search engines from finding and indexing its pages. These include sections blocked from crawling, incorrect canonical URLs, duplicate URLs, redirect issues, or content loading issues.

A technical SEO audit helps detect such errors before they affect a significant portion of the site. Below, we'll discuss the sequence of checks, the necessary tools, and the procedure for fixing issues. The article also includes an SEO audit checklist and a sample report to help you prepare tasks for the developer.

What is a technical SEO website audit and why is it necessary?

A technical SEO audit checks a website for errors that affect page accessibility, processing, indexing, and the correct display of content. During the audit, a specialist examines the URL structure, server settings, service files, HTML code, internal links, and other technical elements.

The check helps determine which pages the search engine can find, which ones may be crawled, and what indexing requirements apply. However, a page's availability to Googlebot doesn't guarantee its appearance in search results: Google independently evaluates the content, quality, and appropriateness of indexing.

How does a technical audit differ from a comprehensive SEO audit?

A technical audit focuses on website performance and its interaction with search engines. A comprehensive SEO audit covers a broader range of issues, including the structure of the semantic core, content quality, rankings, competitive environment, and link profile.

For example, a technical audit will show that an important category contains noindex, while a comprehensive audit will also identify the absence of a landing page for a popular group of queries. Both types of audits can be conducted simultaneously, but the scope of work and final documents will differ.

When is it necessary to check the technical condition of a website?

It's advisable to conduct the initial check before starting SEO promotion to avoid investing resources in pages with technical limitations. This is especially true for online stores, large catalogs, and multilingual projects, where a single template error can affect thousands of addresses.

A re-check is necessary after moving a site to a different domain, changing the CMS, redesigning, setting up new filters, or launching language versions. Other reasons include a decrease in the number of indexed pages, an increase in errors in Google Search Console, or a change in organic traffic after a technical update.

Where to start a technical website audit?

Before launching a scan, it's important to determine which sections are most valuable and what changes have occurred on the site recently. Without this information, it's easy to mistake normal technical limitations for errors and waste time on minor issues.

A few readily available tools are sufficient for a basic analysis, but a full-scale audit will require examining server responses, page templates, and search engine crawl results. It's best to begin checks with site accessibility and indexing, gradually moving on to content and performance.

What data and access should be prepared?

First, compile a list of priority URLs: the home page, important categories, product pages, services, and blog content. For a large site, it's helpful to separate templates, as a single template-level fix can resolve an issue across multiple pages.

It is advisable to prepare the following data:

• Google Search Console. It will be needed for indexing analysis, checking individual addresses and studying crawl statistics.
• Google Analytics 4. It will help you compare the dates of technical changes with the dynamics of organic traffic.
• XML sitemap. Allows you to determine the pages that the resource owner plans to submit to search engines.
• Information about CMS. It is necessary to understand where URLs, meta tags, canonical and other settings are formed.
• Update history. Helps you check the impact of migrations, route changes, templates, and server configurations.

Access to the admin panel or server isn't required for every check. However, without technical implementation details, it's difficult to identify the source of a widespread error and propose a fix that will persist after a site update.

What tools should I use for an SEO audit?

Google Search Console provides key indexing data. It includes page reports, URL inspection tools, sitemap information, and Core Web Vitals issues.

For mass analysis, use Screaming Frog SEO Spider or Netpeak Spider. These SEO crawlers crawl internal links, collect HTTP codes, titles, descriptions, H1 tags, canonicals, and other page elements. They also help find broken links, duplicates, and redirect chains.

For specific tasks the following will be useful:

• PageSpeed Insights and Lighthouse – diagnostics of speed, resource loading and performance.
• Chrome DevTools – viewing network requests, source HTML, CSS and JavaScript.
• Rich Results Test – verification of structured data supported by Google.
• Schema Markup Validator – Schema.org syntax and structure checking.
• Ahrefs or Semrush – additional analysis of the site structure, individual technical issues and backlinks.

Tools may show different results because they use their own crawl settings. Therefore, each significant error should be confirmed on a specific URL and its impact on indexed pages should be checked.

How to perform an express website check in 15 minutes?

An express audit is suitable for identifying the most obvious technical limitations when a resource's health needs to be quickly assessed. Closed pages, faulty redirects, or accessibility issues with key sections can be quickly identified.

Get started with five steps:

1. Check your homepage and several important URLs through Google Search Console, including crawlability and your chosen canonical.
2. Open robots.txt and make sure important sections aren't blocked by accidental rules.
3. Check your sitemap.xml for the presence of main pages and the accessibility of the addresses specified in it.
4. See how HTTP, HTTPS, www, and trailing slash URLs work.
5. Check your homepage and several key templates with PageSpeed Insights.

You can also use the site:example.com operator to roughly check whether pages are present in search results. However, the number of results from this operator cannot be taken as an exact number of indexed URLs. For a more complete picture, consider Search Console, taking into account the specifics of its reports.

Technical SEO Website Audit: A Complete Checklist

A full audit typically begins with questions related to crawling and indexing. The specialist then examines URLs, redirects, internal links, content loading, metadata, and the technical features of individual templates.

For each point, it's helpful to save specific URLs and proof of any issues found. This will help the developer reproduce the error, and the SEO specialist verify the results after the fix.

1. Crawling and indexing pages

The search engine must be able to locate important pages and retrieve their content. If Googlebot encounters a crawl ban, an unavailable server, or incorrect indexing settings, some useful content may not appear in search results.

Start by comparing your site structure, XML sitemap, and Search Console data. Pay particular attention to URLs that should receive organic traffic but are missing from the index or have an unexpected status.

Checking robots.txt

The robots.txt file is located in the root of the host and contains access rules for search robots. The Disallow directive restricts crawling of specific paths, while the Allow directive helps refine permissions within the corresponding rule group.

Check that categories, product cards, services, and resources required for proper page display are not blocked. Also, review the rules for search results, service sections, and URLs with parameters.

It's important to understand the difference between crawling and indexing. Blocking a URL in robots.txt doesn't guarantee its removal from search results, as Google may discover the address through external or internal links.

To exclude HTML pages from the index, use noindex via meta robots or the X-Robots-Tag HTTP header. However, the robot must be able to access the page to see the corresponding directive.

Checking sitemap.xml

An XML sitemap helps search engines find important website addresses. It should ideally include canonical pages that should be indexed and return a successful server response.

During the audit, check for the presence of a sitemap, the correctness of the XML, the relevance of the URLs, and the absence of unwanted addresses. For large projects, a sitemap index may be used, combining several separate files.

Common issues include pages with noindex, 404 errors, unnecessary redirects, and non-canonical URLs. These URLs should be reviewed and, if necessary, removed from the sitemap, preserving useful pages.

A sitemap helps Google discover URLs, but it doesn't ensure they're indexed by itself. Therefore, the results need to be compared with Search Console reports and the actual state of the pages.

Checking indexation in Google Search Console

Open the “Pages” report and examine the reasons why individual URLs weren't indexed. These may include indexation restrictions, redirect errors, crawling issues, duplicates, and pages for which Google chose a different canonical.

Not all excluded URLs require correction. For example, a technical account login page or a duplicate URL may be legitimately missing from the index.

For priority pages, use URL Inspection. Compare your user-declared canonical URL with Google's chosen one, check for URL accessibility, and ensure there are no indexing restrictions.

If a page is accessible but not indexed, examine its internal links, content quality, similarities to other documents, and its discovery history. If necessary, check how often the robot accesses the site and whether there are any server-side restrictions.

2. Server response codes and redirects

The HTTP status informs the client and search engine robot of the result of a request to a specific resource. Errors in server responses can disrupt indexing, break internal navigation, and lead users to inaccessible pages.

During the audit, collect response codes for the main URLs and internal links, including addresses from the sitemap. Pay particular attention to situations where the server returns a success status even though the page content is actually missing.

Checking HTTP statuses 200, 301, 302, 404, 410, and 5xx

A 200 code indicates successful processing of the request, but does not yet confirm the page's quality or ability to be indexed. A 301 code indicates a permanent redirect, while a 302 code is used for a temporary address change.

A 404 status indicates a resource not found, a 410 status indicates a resource removed, and 5xx codes indicate server issues. For a document that has been removed without a suitable equivalent, a 404 or 410 status may be the correct solution.

Check for 200 status codes on empty pages and templates with error messages. These may be identified as soft 404s.

Don't automatically redirect every deleted page to the homepage. A permanent redirect is appropriate when a new address with a similar meaning and purpose exists.

Checking redirect chains and loops

One common technical issue is multiple consecutive redirects to the final page. For example, an old URL first redirects to the HTTP version, then to HTTPS, and then changes the trailing slash.

It's advisable to shorten this chain by configuring the transition directly to the target canonical URL. This reduces the number of unnecessary requests and simplifies URL processing.

When checking, consider domain variations with and without www, HTTP/HTTPS, character case, and the chosen trailing slash policy. The main thing is that the site consistently uses a single agreed address scheme.

Cyclic redirects, where pages redirect to each other, are especially dangerous. They must be fixed first, as the final resource in such a chain becomes unavailable.

3. Duplicate pages, canonical and GET parameters

Identical or very similar content is sometimes available at multiple URLs. Causes include GET parameters, sorting options, incorrect CMS settings, duplicate categories, and different URL versions.

Such situations require an analysis of the site structure and the purpose of each page. Some URLs should be indexed independently, while others may represent alternative versions of the same document.

Checking Canonical URLs

The rel="canonical" element helps indicate to search engines the preferred version of a page among duplicates or similar documents. Google considers canonical as a signal and may choose a different URL.

Main pages typically have their own canonical URL if it aligns with the chosen indexing strategy. Particular attention is paid to product cards, categories, and content accessible via multiple paths.

Check whether the canonical URL of an important page points to the homepage, a different section, or an incorrect URL. Also, identify cases where the canonical URL is blocked from crawling or does not match the internal linking.

It's best to make the correction in the template where the canonical is generated, and then rescan all affected pages. This will prevent the error from recurring the next time you create a URL.

Testing page filtering, sorting, and pagination

Online stores often create URLs with parameters such as color, size, manufacturer, price, and sort order. If poorly configured, the number of such URLs can significantly exceed the number of useful landing pages.

First, determine which filters have independent search demand and unique value. For example, a product category for a particular brand may merit a dedicated indexed page, while a random sorting combination typically doesn't require promotion.

Check link generation, canonical, internal linking, and the inclusion of parametric URLs in the sitemap. If pagination is present, ensure that products on subsequent pages are discoverable and crawlable.

There's no universal rule for closing all filters or canonicalizing them to the main category. The decision depends on the catalog structure, semantics, and URL formation.

4. Website architecture and internal linking

A logical structure helps users navigate between sections, and search engines find pages through standard HTML links. A technical audit should examine the nesting depth, navigation, and accessibility of important documents.

Particular attention should be paid to orphan pages that have no internal links. Such URLs may be present in the sitemap but remain weakly connected to the rest of the site.

Please check the following items:

• Accessibility of main categories through menus and other navigation blocks.
• Correctness of breadcrumbs and their correspondence to the real structure.
• No internal links to deleted pages or unnecessary redirects.
• Ability to navigate to product cards from category and pagination pages.
• Linking relevant services, products and information materials.
• No endless generation of technical addresses when crawling a site.

If an erroneous link is used in a common template, it must be corrected at the source of the navigation. Manually replacing it on individual pages will not resolve the issue and creates the risk of recurrence.

5. Title, Description, H1 and duplicate content

Meta tags and headings help search engines determine the topic of a document and help users understand the page's content. During an audit, we check for missing values, massive duplicates, and inconsistencies between headings and the actual content.

For example, if all online store cards use the same title, “Buy Product”, they poorly describe the differences between the products. A similar problem arises when different services have the same H1 and body text.

Check:

• Title and Description for the main indexed pages.
• The presence of the main H1 heading and the correct H2–H4 structure.
• Repeating meta tags on different URLs.
• Technically created copies of one document.
• Empty categories and pages with insufficiently useful content.
• Matching text in different language versions.

There's no universal rule for titles that guarantees SEO results with a strictly defined character count. It's more important to convey the main topic of the page, avoid word spam, and maintain readability.

6. Loading Speed and Core Web Vitals

Slow loading times hinder users' ability to browse products, use filters, and interact with forms. During a technical audit, speed should be assessed on mobile devices and computers, taking into account actual website browsing conditions.

PageSpeed Insights, Chrome DevTools, and Search Console reports are used for testing. The resulting values should be analyzed by page type, as the homepage, category, and product pages can have completely different issues.

Checking LCP, INP and CLS

Core Web Vitals includes three core metrics that describe page loading, responsiveness, and visual stability.

User data is evaluated at the 75th percentile for mobile and desktop visits separately. This helps account for the majority of visitor experiences, rather than the results of a single test run.

Real-world user data may differ from the Lighthouse lab test results. For example, INP cannot be fully determined by a standard automated test without user interaction, so main thread load and Total Blocking Time are also analyzed for diagnostics.

Checking images, JavaScript, and CSS

Large images often slow down the display of the main content, especially on mobile devices. Check the actual file sizes, whether WebP or AVIF formats are used, and whether the image resolution matches the block size.

Lazy loading can be used for graphics below the fold, but the image that defines the LCP should generally not be deferred unnecessarily. This approach can increase the time it takes for the most prominent page element to appear.

JavaScript and CSS also require review. Excessive third-party scripts, blocking styles, and heavy components can degrade the speed and responsiveness of the interface.

Additionally, examine caching, font loading, critical CSS styles, and Time to First Byte (TTFB). Fixes should be tested on real templates, as speeding up one test page does not necessarily translate into improvements for the entire site.

7. Mobile version and JavaScript rendering

Google uses the mobile version of website content for indexing, so important text and links should be accessible on smaller screens. Check the responsiveness, display of menus, product cards, filters, and contact forms.

Pay special attention to JavaScript rendering. With client-side rendering (CSR), some content appears after scripts are executed, while server-side rendering (SSR) typically renders ready-made HTML markup.

Using JavaScript in itself isn't considered an error. The problem arises when required elements fail to load, require user interaction, or depend on resources unavailable to search engines.

Compare the original HTML with the rendered DOM using Chrome DevTools and the URL Inspection tool. Ensure Googlebot can retrieve the body text, links, metadata, and structured data.

Also, check that images, CSS, and JS files are crawlable. If necessary resources are blocked, search engines may not get a complete picture of the page.

8. Multilingualism and hreflang

On multilingual websites, it's important to check the consistency of pages across different languages and the accuracy of search signals. Particular attention should be paid to projects where the Ukrainian, Russian, and English versions use different URLs.

The hreflang attribute helps Google determine the appropriate language and regional variants of a document. For example, for the Ukrainian version, you could use uk or uk-UA, for the Russian version, ru or the appropriate regional variant, and for the English version, en.

Check that language links are reciprocal and that each version is self-referencing in the hreflang set. Links should point to existing equivalent pages, not to random documents in a different language.

The x-default value is used for pages intended for users for whom none of the specified language variants is suitable. Its use depends on the structure and language selection logic of a particular website.

A common mistake is using ua-UA instead of the correct language code uk-UA. In addition to hreflang, you should check your own Title, Description, H1, text, and canonical URLs for each language version.

9. Schema.org Structured Data

Structured data helps search engines more accurately interpret the page type and specific details about its content. Websites often use JSON-LD because this format is easy to generate and maintain in templates.

During the audit, the markup is checked to ensure that it matches the actual content and that there are no technical errors. Organization can be used for the organization, BreadcrumbList for navigation, Article or BlogPosting for the article, and Product for the product page.

The data must match the information available to the user. Fictitious prices, ratings, and reviews cannot be added for the sake of enhanced search results.

Check syntax with the Schema Markup Validator, and support for specific rich results with the Rich Results Test. Valid Schema.org markup does not guarantee special rendering of the document in search results.

It's worth checking the outdated FAQPage and HowTo guidelines separately. The presence of questions in an article doesn't mean Google will show an expanded FAQ result, and the capabilities of these formats depend on the search engine's current support.

10. HTTPS and technical security

HTTPS testing begins with the availability of the secure version of the website and the validity of the TLS certificate. It's important to ensure that the main pages open without browser warnings, and that old HTTP addresses redirect to the selected HTTPS versions.

The next challenge is to detect mixed content, which occurs when a secure page loads separate resources over HTTP. Such requests can be blocked by the browser or cause problems displaying interface elements.

Additionally, check for server errors, ensure CSS and JavaScript are accessible, ensure forms are functioning correctly, and ensure there are no accidental publications of service documents. For larger sites, it's helpful to review security settings, including HSTS and Content Security Policy.

Not all security headers directly impact Google rankings. However, proper server configuration reduces the likelihood of technical failures and problems for visitors.

Website SEO Audit Checklist: A Self-Checking Table

For self-checking, it's convenient to use a table where each technical element corresponds to a clear criterion. This helps you step through the basic settings and identify problems without having to repeatedly return to individual instructions.

Below is a 30-point SEO audit checklist. It can be used for an initial audit of a small website or as a basis for a detailed technical study.

When working with the table, it's convenient to add the “Status”, “Priority”, “Responsible Person”, and “Review Date” columns. This will help you use the results not only for diagnostics but also for tracking corrections.

Not all deviations from the conventional norm are errors. For example, a page with a noindex may be specifically excluded from search results, and a 404 status code may be correctly returned for a deleted document.

An example of a technical SEO audit of a website with errors found

A practical example of an SEO audit helps us understand how crawl results translate into concrete tasks. For clarity, let's consider a hypothetical online store with main categories, product pages, filters, and multiple language versions.

The URLs and results below are fictitious and are used for illustrative purposes only. In a real project, all metrics are confirmed by crawler, Google Search Console, browser, and server data.

Initial site data before audit

Let's assume an online store contains 2,500 product cards, 80 categories, and several hundred filter combinations. The website has Ukrainian and Russian versions, and the catalog is generated automatically based on CMS data.

After updating the templates, some categories stopped indexing correctly, and users began complaining about slow page loading. A specialist is checking the main sections, comparing Search Console data, and crawling the catalog.

When preparing an audit, product cards, categories, and filter pages are identified separately. This helps determine which errors occur on individual URLs and which ones apply to entire groups of documents.

What problems were discovered?

The hypothetical report identifies several technical issues of varying severity. Each error includes an example URL, priority level, and recommended action.

The most dangerous issue in this example is the disallowed indexing of an important category. If the category is to be listed in Google, it's necessary to remove the erroneous noindex and ensure the page is crawlable.

An incorrect canonical also requires high priority. When product pages link to the homepage, search engines receive conflicting information about the preferred document URL.

Problems with speed and meta tags should be examined by template. If the same error occurs on hundreds of pages, it usually makes sense to fix the overall mechanism for generating these elements.

What does a sample technical specification for a developer look like?

After diagnostics, the SEO specialist must describe each error so the developer can reproduce and fix it. The task must include the affected pages, the actual behavior, the expected result, and the verification method.

Let's look at an example of a technical audit of a website that revealed incorrect canonical generation for product cards.

Description of the error and affected URLs

Problem: product cards pass the homepage address to rel="canonical" instead of their own canonical URL.

Example:

• Page being tested: https://example.com/product/item-1/
• Current canonical: https://example.com/
• Expected canonical: https://example.com/product/item-1/

An error was detected while crawling product cards. It's necessary to determine whether this applies to all cards or only occurs with certain product parameters.

Additionally, you should check the server's HTML response to ensure that the incorrect value is indeed passed in the resulting markup. A screenshot of the crawler and a list of affected URLs are attached to this task.

Required correction

The developer needs to find a mechanism that generates canonical URLs for the product page template. For standard, stand-alone indexed pages, the corresponding canonical URL should be passed, and for products with multiple URLs, a consistent strategy should be used.

The fix must be made at the level of the general template or CMS SEO settings. Manually changing the canonical on one page will not fix the issue on other pages.

After changing the logic, you need to test products with variants, URLs with parameters, and different language versions. It's important to ensure that the new implementation doesn't conflict with previously configured canonical URLs.

Acceptance criteria and re-checking

The task is considered completed if the verified standalone cards contain correct canonical addresses, have no conflicting instructions, and return the expected HTTP statuses.

To confirm the result, you should rescan the affected URL group. You should also open the pages in a browser, check the source HTML, and ensure that the change works on the published version of the site.

Several new cards created after the correction are checked separately. This will confirm that the error has been corrected in the page generation mechanism and will not recur in future catalog updates.

How to prioritize after an SEO audit?

A scan result may contain hundreds or thousands of warnings, but fixing them all at once is usually impractical. Priority is determined by the error's impact on important pages, the scale of the problem, and the complexity of implementation.

For example, an erroneous noindex for all categories requires immediate attention, while a missing description for several technical documents may not impact the site's core functionality. Therefore, the list of fixes must be sorted based on the actual state of the project.

What errors should be corrected first?

Four priority levels are useful for assigning tasks. They help the team understand which issues require immediate attention and which can be included in the next update plan.

Lead SEO specialist — Gennady

When I conduct a technical SEO audit, I'm not interested in the number of errors in the report, but rather in which ones are actually hindering the site's search performance. For example, an incorrect canonical on a category template can affect hundreds of pages, whereas a missing alt tag on a single decorative image is usually a much lower priority. Therefore, I always check the scope of the problem and its impact on important URLs before assigning tasks to the developer. For me, the main result of the audit is not a table of warnings, but a list of specific fixes that can be implemented and verified.

Priorities can differ even between two websites of the same type. An error on a page with high organic traffic usually requires more attention than a similar issue on a secondary URL.

How to prepare a final report?

A useful report should contain sufficient information to implement a fix without further troubleshooting. It should include the affected URLs, a description of the error, confirmation, priority, and expected technical outcome.

The following fields are convenient to use:

1. Verification section. For example, indexing, redirects, meta tags or performance.
2. Affected URLs. Specific addresses or templates of pages where the error was found.
3. Description of the problem. The actual behavior of the site and how it is reproduced.
4. Consequences. Possible impact on crawling, indexing, display, or users.
5. Recommendation. Specific technical action for the responsible specialist.
6. Priority and status. The order of implementation and the current status of the task.
7. Verification criteria. Conditions under which the correction can be accepted.

It's best to keep the report in a spreadsheet or task management system where both the developer and SEO specialist can see the same information. If necessary, screenshots, crawl exports, and server response fragments are added to each item.

An SEO audit example with such data helps avoid general statements like “improve technical optimization”. The contractor immediately understands what problem needs to be fixed and how to verify the results.

What to do after a technical website audit?

After the audit is complete, it's necessary to agree on the corrections, assign responsibilities, and determine the implementation process. Even a detailed report won't improve the site's condition until the identified issues are resolved.

It's a good idea to save the audit results as a baseline for subsequent comparisons. This will make it easier to determine which changes were actually implemented and whether any new errors were introduced after the updates.

How to check fixes after implementation?

A re-check should cover not only the URLs specified in the task but also other pages within the same template. For example, after fixing the canonical for product pages, several standard and non-standard pages should be checked.

First, confirm the technical result through the browser, HTTP headers, and crawler. Then, use Google Search Console to monitor the recrawling and processing of important URLs.

Improved indexing and changes in search traffic may not be immediately apparent. Therefore, technical fixes should be separated from subsequent SEO performance evaluation.

If the detected issue is related to a common template, it's helpful to add an automatic check to the new version publishing process. This will reduce the risk of recurring errors after the next CMS update.

How often should an SEO audit be repeated?

The frequency depends on the number of pages, the technical complexity of the project, and the frequency of changes. For a small website with infrequent updates, periodic checks and additional monitoring after significant edits are usually sufficient.

Large online stores, news resources, and sites with rapidly changing catalogs require more frequent monitoring. Particular attention is paid to indexing new pages, filtering, and server stability.

After a migration, URL change, or new template implementation, it's advisable to conduct an audit independently of the scheduled time. In such situations, a single error can quickly affect a large number of pages.

How long does a technical website audit take?

The duration depends on the number of URLs, template structure, CMS used, filters, and language versions. A small website can be checked significantly faster than a large online store with thousands of products and numerous technical URLs.

Additional time is required to analyze scan results, review ambiguous cases, and prepare developer assignments. This timeframe also depends on the availability of Google Search Console, server logs, and other technical information.

What's included in a technical SEO audit checklist?

The checklist includes checks for crawling, indexing, robots.txt, sitemap.xml, HTTP status codes, redirects, canonicals, and internal links. Meta tags, duplicate content, mobile version, loading speed, and structured data are also checked.

For a multilingual website, hreflang and language matching are additionally analyzed. The full set of checks depends on the structure, size, and purpose of the resource.

A technical SEO audit helps identify issues that prevent search engines from processing your website's pages correctly. The check should begin with indexing and URL accessibility, then move on to structure, redirects, content, speed, and other technical elements.

Every significant issue must be confirmed, prioritized, and passed on to the developer with clear fix criteria. If this requires specialist assistance, order a technical SEO website audit from Seo-Gen and get recommendations on the problems found.