Consulting
Website Audit Checklist: What to Check Before a Redesign or Ad Launch
A complete self-audit checklist covering indexation, speed, markup, mobile usability and commercial ranking factors, with the tools to run each check and a way to prioritise what you find.
In short
Before a redesign or an ad launch, a free checklist catches most of the recurring problems: indexation and crawling (10 items), speed and Core Web Vitals (8 items), markup and metadata (6 items), mobile and usability (8 items), Yandex commercial ranking factors (6 items), 38 checks in total. Running through it takes 3 to 5 hours with Yandex.Webmaster, Search Console, PageSpeed Insights and Lighthouse open.
Why this is the cheapest insurance in the whole project
A redesign starts at around 150,000 RUB, and a month of Yandex Direct advertising for an average project runs 60,000 to 300,000 RUB in media spend alone, management fees aside. Both investments assume the site can technically absorb a new design or new traffic without losing it on the very first step. Checking that in advance costs a few hours. Skipping the check risks the entire redesign or ad budget at once.
The logic is simple. Advertising drives traffic to a site that either is not indexed correctly, loads slowly on mobile, or loses leads through a broken form, and every click you pay for is structurally incapable of becoming money. A redesign layered on top of unexamined problems risks repeating them in a new wrapper, or worse, accidentally deindexing pages that used to bring in traffic.
The checklist below is not a trimmed-down version of a paid audit. It is a working set of 38 specific checks you can run yourself in a single working day using free tools. It is organised into five blocks: indexation and crawling, speed, markup and metadata, mobile and usability, and Yandex commercial ranking factors. Every item is phrased as a concrete action, not a vague nudge to "improve SEO."
Block 1. Indexation and crawling: 10 items
If a search engine cannot see a page, nothing else matters: design, speed and copy will not rescue a page that is not in the index. This block checks the basic accessibility of the site to Yandex and Google, and it is where critical problems most often turn up after a domain move, a CMS switch or a redesign.
Half of these items take five minutes in a browser to check, the other half need a crawler like Screaming Frog or the reports inside Yandex.Webmaster and Search Console. Start here. If indexation is broken, the rest of the checklist can wait until it is fixed, because these 10 items decide whether a search engine ever sees the new design or the traffic you are about to pay for.
| Item | What exactly to check |
|---|---|
| robots.txt | Disallow directives are not blocking important sections: the catalogue, articles, service pages. This is especially common after a platform migration, where a test-stage Disallow: / line often survives into production. |
| sitemap.xml | The file exists, loads at a direct URL, lists every key page, and contains no URLs that 404 or redirect internally. |
| Sitemap submission | The sitemap is added and accepted in both Yandex.Webmaster and Google Search Console, with no processing errors in the report. |
| Meta robots tags | Pages meant to be indexed do not carry a stray noindex tag, a common leftover from moving a staging build to production without editing it. |
| Canonical tags | Points to the page own URL, not to the homepage or an unrelated page. A canonicalisation mistake can wash entire sections out of the index at once. |
| Actual indexed count | The indexed page count in Webmaster and Search Console is in the same order of magnitude as the sitemap page count. A gap of several times over signals a systemic problem. |
| URL duplicates | The site does not respond on both http and https, with and without www, with and without a trailing slash. Each unresolved pair creates a duplicate in the index. |
| Redirect chains | No chains of two or more redirects in a row (301, then 301, then 200). Chains slow crawling down, and some bots simply give up before reaching the final page. |
| Broken internal links | Internal links do not point to 404 pages. A crawler such as Screaming Frog finds every instance in a single pass over the site. |
| HTTPS and mixed content | The entire site loads over HTTPS with no mixed-content warnings and no leftover internal links pointing to the http version of a page. |
Block 2. Speed and Core Web Vitals: 8 items
Both Google and Yandex use speed as a ranking factor, but even without that, a slow site loses visitors before they ever see the offer. The Google Core Web Vitals thresholds: LCP (main content load) under 2.5 seconds is good, up to 4 seconds is borderline, beyond that is poor; INP (interaction response) under 200 milliseconds is good; CLS (layout shift) under 0.1 is good. These are worth checking against real field data, not only a lab test.
The most common mistake when checking speed is testing only the homepage. A product page with twenty images and a price calculator behaves completely differently from a lightweight homepage. Check every unique template separately: homepage, category or catalogue, product or service page, and checkout.
| Item | What exactly to check |
|---|---|
| LCP per template | Measured separately for the homepage, catalogue and product or service page, not just the homepage. |
| INP under real interaction | Response is checked against real actions: clicking a filter, opening a modal, typing into a form field, not only page load. |
| CLS causes | Specific elements without fixed width and height are identified: images, banners, font blocks with no font-display set. |
| Image weight | Images are compressed, served in modern formats (WebP or AVIF) and sized to what the screen actually needs, via responsive sources. |
| Render-blocking scripts | Analytics and widget scripts are not loaded synchronously in the head before content. They are deferred or loaded asynchronously. |
| Caching | Browser caching is configured, and CDN-level caching where available, for static assets: styles, scripts, images. |
| Server response time | TTFB is stable and does not spike under normal load. Checked separately from the front end, and often traced back to hosting. |
| Third-party scripts | The number and weight of external widgets are counted: chat, trackers, social embeds. This is often the least visible source of page weight. |
Block 3. Markup and metadata: 6 items
Metadata and structured markup do not change what a visitor sees on the page, but they directly affect how the page looks in search results and whether the search engine understands it correctly. Mistakes here rarely break the visual site, which is exactly why they survive for years unnoticed: the page works, it just gets fewer clicks in results or shows up without the price and rating snippet it was built for.
The main rule when checking structured markup is to cross-check it against what is actually visible on the page. Product markup showing a price of 5,000 RUB on a page where the real price is now 6,500 RUB is not a minor technicality, it is a direct trigger for a search engine penalty over misleading data.
| Item | What exactly to check |
|---|---|
| Title and description | Unique on every page, not duplicated en masse across product cards, and never left empty on important sections. |
| Schema.org validity | Passes a validator and matches the visible content: price, availability and rating agree with what is actually shown on the page. |
| Open Graph tags | og:title, og:description and og:image are filled in. They decide how the link looks when shared in messengers and social platforms. |
| A single H1 per page | There is exactly one H1, it reflects the specific page topic, and it does not repeat the title word for word. |
| Heading hierarchy | H2 through H6 follow the logical structure with no skipped levels, and are not used purely to make text visually bigger. |
| Alt text | Product and service images carry descriptive alt text, which matters most on cards where the image carries most of the information. |
Blocks 4 and 5. Mobile, usability and commercial factors: 14 items
Both Yandex and Google build their index mobile-first: ranking is based on the mobile version of the page, even for sites where most current traffic still comes from desktop. That makes the mobile block just as critical as indexation, not an optional check added for completeness.
A technically sound site routinely loses leads over mundane details: a call-to-action below the fold on a small screen, a phone number that cannot be tapped to dial, a form with no validation that simply does nothing when input is wrong. This block finds these faster than any other, because most of them are visible in five minutes on an actual phone.
The same logic applies to the commercial factors Yandex has historically weighed separately from technical health and content relevance: how much a site resembles a genuinely operating business rather than a placeholder page. Google does not formally declare these factors, but for Russian search results they noticeably affect rankings on commercial queries, and for online stores this block also covers Product markup health and filter structure. Empty categories and duplicate URLs generated by filters are a commercial factor too, just expressed through a technical symptom.
| Item | What exactly to check |
|---|---|
| Content parity | The mobile version carries the same text, links and markup as desktop, not a stripped-down subset. This is a direct requirement of mobile-first indexing. |
| Tap target size | Buttons and links are large enough and spaced far enough apart to avoid mis-taps on a small screen. |
| Viewport and zoom | Text reads without a forced pinch-to-zoom gesture, and the viewport meta tag is configured correctly. |
| Tappable contacts | Phone numbers and email addresses are tel: and mailto: links, not plain unlinked text. |
| Mobile forms | Fields trigger the right keyboard (numeric for phone, with @ for email), and validation errors are visible, not hidden. |
| CTA above the fold | The primary call to action is visible without extensive scrolling on a typical phone screen. |
| Popups and modals | They do not permanently block content and are easy to close on a small screen. Intrusive interstitials carry their own separate Google penalty. |
| Real session recordings | Yandex.Metrica session recordings are watched: where visitors stall, what they click without effect, where they abandon a form. |
| Price visibility | Prices are visible without registration or a phone call, if competitors in the niche show prices openly. |
| Contact information | Phone, address and working hours are visible and consistent across every page and in the Yandex Business listing. |
| Ordering process | Checkout steps are clear, with delivery and payment information visible without hunting through the site. |
| Reviews | Reviews exist on the site or on linked platforms, ideally with company responses. |
| About the company | Real company information exists: team, address, registration details, not just a placeholder page with a contact form. |
| Catalogue structure | Sections match what is actually sold, with no empty categories and no filters spawning duplicate pages. |
Tools: what each one actually shows
Five free tools are enough to cover all 38 items. Yandex.Webmaster is the source of truth for Yandex indexation: how many pages are indexed, which are excluded and why, sitemap errors, security issues and Yandex-specific commercial factor recommendations. Google Search Console does the same job for Google: an indexation coverage report, a mobile usability report, and a Core Web Vitals report based on real user data (CrUX), not just a lab test.
PageSpeed Insights gives a fast snapshot for a specific URL: both lab and field Core Web Vitals data, plus a list of specific findings per metric with an estimated impact. Lighthouse runs the same engine directly from Chrome DevTools, which is useful for pages behind a login or not yet published, somewhere PageSpeed Insights cannot reach, and it additionally checks accessibility and baseline security.
Yandex.Metrica session recording covers what no automated report will show: how real people actually behave on the page. It is worth sampling rather than watching everything, 15 to 20 recordings on a key page is usually enough to spot a repeating pattern, whether that is a dead click on a non-functional element or people consistently abandoning the form at the same field.
How to prioritise what you find
Working through all 38 items almost always produces a list of 15 to 30 findings, and fixing them top to bottom in checklist order is a poor strategy: time goes into low-priority edits while a critical problem keeps costing money every single day. Sort the list into three tiers instead.
Critical: whatever is blocking indexation of revenue pages or breaking conversion right now, a deindexed product page, a broken lead form, a site without HTTPS, a severe LCP failure on the checkout page. These get fixed within days, regardless of whatever else is planned.
Important: not urgent today but slowing growth, missing or incomplete markup, weak mobile behaviour on secondary pages, unnecessary third-party scripts. This goes into a sprint or a monthly plan. Can wait: low traffic on the affected pages, cosmetic heading-hierarchy issues, duplicates on pages almost nobody visits anyway. The rule is simple: if a finding does not block money or the indexation of an important page, and the effort to fix it outweighs the payoff, it goes into the backlog.
What a checklist cannot catch
A checklist answers "what is wrong," not always "why it is wrong and what to actually do about it." If LCP on a product page is 4.8 seconds, the checklist flags the problem but will not say whether it is caused by heavy images, a slow server, a blocking third-party widget script, or some combination, and those are three different people to fix it and three different budgets.
Nor does a checklist replace understanding of your business and competitors. It will not tell you whether the catalogue structure matches real demand in your niche, will not benchmark you against the three closest competitors in search results, and will not set priorities against your actual budget and the metric that matters most to you right now, traffic, leads, or a specific revenue number. That takes context no automated report carries.
The sensible order of operations is to run the checklist yourself, fix whatever is clear and cheap to fix in house, and take the remaining list to a professional review for whatever stays unclear. At Veltos.Tech a website audit starts at 15,000 RUB for the three-day express format, and if part of what you find gets handed over for further work, that fee is typically credited against it. But the checklist above covers most of the ground for free. A professional audit exists for the remaining 20 percent, not as a replacement for doing this yourself first.
Frequently asked questions
How long does running through this checklist take?
For a mid-sized site, 3 to 5 hours, if the tools (Yandex.Webmaster, Search Console, PageSpeed Insights) are already connected. If access does not exist yet, add a day for setup and initial data collection: both Search Console and Webmaster show history with a delay, and session recording needs time to accumulate enough sessions to draw conclusions from. A large site with dozens of unique page templates and a catalogue takes noticeably longer simply because of how many page types need checking against each block separately.
Do all 38 items need to be checked in one sitting?
No, it works fine block by block. If the site is about to receive ad traffic, start with indexation and speed, the two blocks that directly determine whether ad spend can turn into sales at all. Before a redesign, add the markup and mobile blocks, to record exactly what must not be lost in the move to the new design. The commercial factors block can almost always wait: it affects ranking growth gradually and rarely explains a sharp, sudden drop in traffic or leads.
Can this be done without Search Console or Webmaster access?
Partially. PageSpeed Insights, Lighthouse and manually checking robots.txt, sitemap.xml and markup all work without registering the site in either search console. But real indexation data, crawl errors and field Core Web Vitals only come from Webmaster and Search Console, and without them part of the findings can only be estimated indirectly, from analytics data. For instance, instead of an exact indexed page count, a rough estimate can come from the site: search operator, cruder than the Webmaster report, but better than nothing.
The site has not launched yet. Which items still apply?
Almost all of them, except the items that need accumulated history: actual indexed count, field Core Web Vitals from CrUX and session recordings only exist after launch and initial traffic. Everything else, robots.txt, the sitemap, canonical tags, structured markup, mobile behaviour, lab speed tests, can and should be checked before launch, while fixes are still cheap. Commercial factors are also partly checkable ahead of time, provided prices, contacts and the ordering process on the site are already final rather than placeholder content for the designer.
What if there are too many findings to fix all at once?
That is normal for a site that has never been checked against this list before. Split the findings into critical, important and can-wait using the rules in the prioritisation section, close the critical tier within the first week, the important tier within the month, and roll the rest into the regular quarterly work plan. Trying to close the entire list in one push usually means closing none of it on time. It helps to show the prioritised list to the team or contractor who will fix the findings right away, which heads off arguments about what should happen first.
Need a hand with this?
We do this work, not just write about it. Describe the task and we will scope it and send a staged estimate.
Related services
- Website audit: technical, SEO and UXBefore changing the design, raising the ad budget, or telling support the site "just feels slower," find out what is actually happening. An audit is one report that pulls technical health, SEO and usability into a single list: what is on fire, what matters, and what can wait.
- IT consulting and product auditThe most expensive mistakes in software happen before the first line of code: a misread problem, a stack chosen out of a contractor’s habit, and a specification that does not exist. Consulting exists to settle all of that before the development meter starts running: what to build, out of what, at what cost and in which order. The result is a document, not an opinion on a call.
- SEO and GEO website promotionSearch traffic is the one acquisition channel that keeps working after the ad budget stops. We run two tracks in parallel: classic SEO for Yandex and Google, and GEO, the work of getting your pages quoted inside AI Overviews, Yandex Neuro, ChatGPT and Perplexity, where a growing share of queries now ends. It starts with an audit, never with buying links.
Read next
- Technical, SEO and UX Audit: Which One Do You Actually NeedTechnical, SEO and UX audits answer different questions and catch different problems. A practical breakdown of what each one covers, what it misses, and how to know which one your situation calls for.
- A Slow Site Loses Money: Core Web Vitals and ConversionSite speed is not a technical metric, it is a line in the revenue report. Core Web Vitals explained in plain language, how to find the real cause of a slow page, and a fix list sorted by return per hour of work.
- Redesigning a Site Without Losing Traffic: Stages, Risks and the SEO Migration ChecklistHalf of all redesign requests are really content, speed or offer problems. How to tell them apart, why a phased rollout beats a big bang launch, and what belongs in the migration checklist so the organic traffic survives.