This weekly site check does not replace a full SEO audit, but it works well as a short operational routine. In 20 minutes, you can see whether crawling, indexing, site speed, canonical signals, and the core technical settings are all in order.
Technical problems rarely hit traffic without warning. Before rankings or clicks drop, you can usually already see signals in Search Console, indexing, robots.txt, sitemap.xml, or in the way Google crawls your pages.
A short weekly technical SEO check is useful even for teams that already have established workflows. In SEO-Evolution’s practice, this format works well as an early control point after releases, template edits, CMS changes, or server-side updates.
For commercially important websites, this checklist works best when combined not only with regular SEO services , but also with periodic technical site audits . The checks in this article are based on Google documentation and on practical weekly monitoring workflows.
Is 20 Minutes a Week Really Enough?
To be blunt, no. In 20 minutes, you do not run a full technical audit, resolve complex canonical conflicts, test every template, or manually review the entire site.
This is not deep research. It is a short diagnostic review that helps you quickly understand whether everything looks normal or whether there are already signals that deserve a deeper investigation.
One week, this review may simply confirm that the site is stable. Another week, it may help you catch problems with noindex, rel canonical, mobile-first indexing, sitemap.xml, or a sudden spike in technical issues in Search Console.
This format does not include a full review of templates, log files, JS rendering, every hreflang and canonical connection, or a detailed analysis of why traffic dropped. It is a short control check that helps you understand where a deeper review is needed.
If you have not been doing regular monitoring for a while, even a short site check like this can already be valuable. It helps prevent small technical issues from quietly piling up.
1. Search Console Overview (Minutes 0–10)
The best place to start is Google Search Console . It is the first place where you can see how Google actually views your site: what it indexes, what it excludes, what it crawls, and where problems have already appeared.
In these 10 minutes, you do not need to try to complete a full SEO audit. The task is simpler: quickly spot anomalies that do not look like a normal weekly fluctuation.
Start with the Overview
At this stage, look for major changes rather than small movements in individual queries. If clicks, impressions, or coverage have dropped sharply, that is already a reason not to postpone further investigation.
- Check for a sharp drop in clicks and impressions in performance. Not every decline points to a technical issue, but a sudden change without an obvious reason is a signal.
- See whether any new indexing issues appeared after a release, migration, redesign, or template changes.
- If the site uses schema markup and structured data for products, articles, breadcrumbs, videos, or other elements, review rich results reports as well when they are available.
If your Search Console setup still needs work, also review how to set up Google Search Console correctly .
Then Move to the Indexing Section
Next, open the page indexing report. This is one of the most useful reports for a weekly technical check because it shows how Google is handling your URLs at the indexing level.
Do not only look at the presence of errors. Watch their trend as well. The most important issues to keep an eye on are usually:
- a sharp increase in pages with noindex;
- pages blocked by robots.txt even though they should appear in search;
- a spike in soft 404s or other unusual exclusions;
- canonical conflicts where Google selects the wrong canonical page;
- growth in groups of duplicate URLs without a clearly chosen canonical.
Not every excluded URL is a mistake. But if you see an unusual increase in problematic statuses, that is no longer a minor fluctuation and deserves a deeper look. Google explains canonicalization logic separately in its documentation on canonical URLs and rel canonical . If you need a better understanding of indexing logic overall, it is also useful to keep how to get a site indexed in search engines at hand.
Review the Sitemaps Section
Here, it is not enough just to confirm that sitemap.xml has been submitted. Check whether Google has read the sitemap recently, whether there are processing errors, and whether the sitemap structure still matches the current architecture of the site.
If you have several sitemaps for different page types, that is even better: it becomes easier to spot where exactly the problem occurred, whether in products, categories, articles, or system templates.
If there are sitemap errors, do not ignore them simply because the pages seem to be indexed anyway. The sitemap is a basic signal for Google, and if that signal is noisy, future diagnosis becomes harder.
Check Manual Actions and Run a Spot URL Inspection
Manual Actions is the report you always want to see empty. That is exactly why you should open it regularly. It is better to learn about a problem through Search Console than from a sudden visibility crash.
At the end of this block, open URL Inspection for one or two critically important pages: the homepage, a key category, a service page, or a page that generates leads. Check whether the URL is indexed, when it was last crawled, which canonical Google selected, and whether it conflicts with your own rel canonical.
If you suspect a crawling problem, also open the Crawl Stats Report in Search Console settings. It is useful when you need to quickly check whether Googlebot requests have dropped, whether average server response time has increased, or whether there has been a spike in 5xx errors after changes on the site.
2. Check robots.txt (Minutes 11–12)
The robots.txt file is one of the simplest technical elements, but it is also one of the most common causes of unpleasant surprises after releases, migrations, or work on a staging environment.
The key point here is simple: robots.txt controls crawling, but it does not guarantee that a page will be excluded from the index. If a page should not appear in search, that usually requires noindex, correct status codes, or access restrictions, not just a robots.txt block.
A weekly check takes one or two minutes:
- open the file on the live site and make sure it is being served correctly;
- check that there is no accidental directive like Disallow: /;
- see whether important directories, CSS, JS, or service resources needed for rendering have been blocked;
- confirm that the sitemap path is still correct.
Pay especially close attention to robots.txt after CMS updates, template edits, site migrations, or work that was done earlier during website development .
If you want to refresh the logic behind this file separately, review robots.txt: what it is and why it matters .
User-agent: *
Disallow: /
This directive should not be present on a live site unless you intentionally want to block the entire resource.
3. Check Site Speed and Core Web Vitals (Minutes 13–15)
This block is not about running full front-end profiling. The goal is simpler: understand whether the site has become worse over the last week and whether there is any obvious decline in page experience signals.
Core Web Vitals are a set of real-user experience metrics. For weekly monitoring, it is enough to compare the overall trend, and if you see deterioration, then run PageSpeed Insights or Lighthouse for the specific URLs that matter.
The screenshot below illustrates the basic logic of a quick check: first, review the overall trend, then look at the page templates where the decline is most noticeable. For SEO evaluation, your main reference points should be Core Web Vitals and PageSpeed Insights .
If you have an internal dashboard in GA4 or Looker Studio, it is convenient to compare the last seven days with the previous seven. But for SEO evaluation, do not rely only on a general speed report: look at templates, mobile pages, and the real URLs that drive traffic and leads.
Start with the mobile version of the pages, because mobile-first indexing means Google primarily relies on mobile content for indexing and ranking. If the homepage, categories, or key landing pages have dropped sharply on mobile, that matters more than cosmetic issues on desktop.
What to check quickly:
- whether average site speed has worsened after a release;
- whether templates with commercial traffic have slowed down;
- whether there are major deviations in LCP, INP, and CLS;
- whether new heavy scripts, banners, widgets, or media are breaking layout stability.
If you do see a decline, run two or three key URLs through PageSpeed Insights and Lighthouse instead of trying to explain everything with one top-level number.
4. Review Search Results (Minutes 15–18)
No tool can fully replace a live SERP review. Even if you use rank trackers, it is still worth manually checking what a user actually sees in search results once a week.
Do not check dozens of queries. Review a few that matter most: the brand query, the main commercial pages, key informational queries, and one or two critical landing pages.
What to look at:
- whether the right page is ranking instead of a duplicate or a secondary URL;
- whether the title, description, or favicon has broken;
- whether a page that should have been excluded via noindex or canonical has appeared in the SERP;
- whether hreflang is working correctly on a multilingual site, if you have multiple language versions;
- whether rich results have disappeared where schema markup is implemented.
If the wrong page appears in search, the problem is often not content but canonical signals. In a rel canonical SEO context, the issue usually shows up when the tag conflicts with the sitemap, internal linking, hreflang, or the actual structure of the templates.
For multilingual sites, it is useful to review hreflang from time to time, especially after launching new language versions or changing templates. And if you suspect rich results have disappeared because of markup, check the relevant pages through Google’s structured data documentation and the Rich Results Test . That is a fast way to understand whether Google can actually see your schema markup and whether technical errors appeared after template changes.
5. Visually Check the Site (Minutes 19–20)
The final two minutes are worth spending on something very simple but very useful: open the site with human eyes, not through a report. That is often how teams catch problems that have not yet surfaced in tools.
Start with the mobile version, then quickly look at desktop. Because of mobile-first indexing, mobile rendering matters first for search.
Quickly go through the homepage, a key category, a service page, and one or two blog articles. You are not looking for tiny stylistic nuances here. You are looking for things that can actually affect indexing or conversion:
- broken blocks, empty sections, missing images, or JS that did not fully load;
- unexpected banners, pop-ups, or elements that cover the content;
- issues with the menu, pagination, filters, breadcrumbs, and internal linking;
- an accidental noindex in the code;
- an incorrect rel canonical;
- unnecessary or broken hreflang;
- missing or broken schema markup in the source code.
After that, open the page source for one or two pages and check the core signals: title, meta robots, rel canonical, hreflang, JSON-LD, or other schema markup. It is a simple action, but it often helps catch things that are not obvious from a visual page review alone.
Developer Tools > View Page Source
Conclusion
This 20-minute weekly site check does not replace a full audit. Its role is practical: to catch problems with crawling, indexing, site speed, canonical, hreflang, sitemap.xml, and other technical signals early, before they hit traffic.
If this short review reveals anomalies, do not delay the deeper investigation. At that point, a simple weekly routine turns into a full SEO audit or a dedicated technical audit .
If the site is growing, gaining new sections, language versions, templates, and integrations, then regular technical SEO should not be treated as a one-time task. It should become an ongoing process. That is how technical monitoring is typically built into the projects SEO-Evolution supports.
