Two years is a long time in the life of a website. Usually you don’t see it right away: the site still loads, the forms mostly work, and the CMS still lets you add new pages. The problems build up where they are harder to spot: in indexing, speed, security, analytics, accessibility, and visibility in AI-powered search.
In this article, I show what to check if your website is more than two years old and hasn’t had a technical review in a long time. The point is not to build a new website right away. An audit, a list of priorities, and a few well-chosen fixes are often enough.
In this article:
- 1. Technical SEO and indexing
- 2. Content, search intent, and old pages
- 3. GEO/AEO: visibility in AI search results
- 4. Core Web Vitals and real-world page speed
- 5. Scripts, consent mode, and analytics
- 6. CMS and framework security updates
- 7. Digital accessibility
- 8. Forms, conversions, and integrations
- 9. Monitoring, backups, and an incident response plan
- What to do after the audit?
- Technical SEO and indexing
The first area is SEO basics, which can quietly drift out of shape over two years. Someone changed the menu structure, someone removed an old section, someone added new filters to product or article lists, and someone else redirected a campaign landing page without checking the consequences. After a few changes like these, Google sees a different website than the marketing team does.
Google keeps stressing the basics: a page has to be accessible to search engine crawlers, indexable, and easy to understand. So start with Google Search Console, a crawl of the whole site, and a list of your most important URLs.
Check first of all:
- whether important pages are indexed,
- whether unnecessary pages have made it into the index,
- whether canonical URLs point to the right pages,
- whether robots.txt and meta robots tags block important pages,
- whether the XML sitemap (sitemap.xml) is up to date,
- whether 301 redirects create chains,
- whether titles, meta descriptions, and H1 headings are duplicated at scale,
- whether important pages are buried too deep in the site structure and whether internal links lead to them.
The most common mistake after two years: the team only compares organic traffic month over month. That’s not enough. You need to check whether the site is still technically in order, because traffic drops often come from many small oversights, not from one spectacular failure.
If your website runs on Drupal, also read our article 10 SEO features a modern CMS should have, using Drupal as an example.
- Content, search intent, and old pages
The second area is content. After two years, some articles, landing pages, and service descriptions may still be accurate but no longer answer the questions your customers ask today. This is especially visible in B2B and in industries such as IT, finance, education, healthcare, and ecommerce.
Products change, and so do offerings, competitors, the words customers use, and the search results themselves. An article that attracted a lot of traffic in 2024 may be losing to competitors in 2026 because it doesn’t cover new query variations or doesn’t reflect how customers make decisions today.
In a content audit, check:
- pages with a large drop in clicks or CTR,
- pages with many impressions but few clicks,
- old blog posts that still rank high in search results but contain outdated CTAs,
- keyword cannibalization, meaning several pages that answer the same search intent,
- missing internal links to service pages and case studies,
- pages without an author, an update date, or real examples,
- content that reads like a neutral category description rather than an expert answer.
Not every old article needs a rewrite. Sometimes it’s enough to add current context, an FAQ section, a new CTA, and a link to newer material, and to remove broken links. But make the decision deliberately: update, merge, keep, or delete.
- GEO/AEO: visibility in AI search results
If your website was built more than two years ago, nobody probably designed it with AI Overviews, AI Mode, Perplexity, or ChatGPT search in mind. In 2026, this is no longer a curiosity. It’s a separate channel where customers discover brands, services, and guides.
Google’s guidance is clear: SEO basics still matter in generative results. A page has to be indexed, the content should be original, specific, and useful, and important information has to be available as text. Google doesn’t require a special file such as llms.txt or additional structured data for a page to appear in AI Overviews or AI Mode.
That doesn’t mean nothing has changed. What has changed is how users reach content and how they judge it. AI-powered search engines more often show pages that answer questions clearly, demonstrate experience, have well-organized sections, and let AI systems determine who the author is, what the content covers, and why it can be trusted.
In a GEO/AEO audit, check:
- whether key pages answer specific customer questions,
- whether the text includes definitions, comparisons, selection criteria, and examples,
- whether authorship and your company’s experience are visible,
- whether structured data matches the content visible on the page,
- whether images and videos add to the text instead of just decorating the layout,
- whether your company is described consistently on your website, in case studies, on profiles, and in external mentions,
- how impressions, clicks, and CTR change in the Performance report in Search Console. Google includes traffic from AI Overviews and AI Mode there, but doesn’t provide a separate report for these features.
On Reddit, opinions about GEO are sharply divided. Some people see clicks dropping because of AI Overviews, others argue that “GEO” is simply well-done SEO with better-structured content. My practical recommendation is simple: don’t look for tricks aimed only at AI. Create content that can be cited, understood, and verified.
We describe exactly what we check on Drupal websites in the article Beyond SEO: what we check in a Drupal AI-readability audit.
- Core Web Vitals and real-world page speed
A website can be fast on launch day and noticeably slower two years later. All it takes is a few campaigns, new ad pixels, a chat widget, an embedded third-party tool, large photos uploaded by an editor, and an extra form plugin. There’s no single big failure. The site slows down gradually.
In 2026, monitor the three Core Web Vitals metrics:
- LCP, the time it takes to display the main content – target: 2.5 seconds or less,
- INP, the time it takes the page to respond to a user action – target: 200 ms or less,
- CLS, the visual stability of the page layout – target: 0.1 or less.
Important: a PageSpeed Insights score for a single URL is not enough. Check different page types: the homepage, a product or article list, an article, a landing page, a form, a login page, a cart, or a customer portal. The problem often sits in a template, not in a single URL.
Typical causes of problems:
- an unoptimized image in the hero section,
- too much JavaScript above the fold,
- render-blocking CSS and JS files,
- third-party scripts loaded without control,
- web fonts that shift text while the page loads,
- ads or banners that change the page layout,
- frontend components that block the browser’s main thread.
If your website runs on Drupal, check caching, CSS and JS aggregation, lazy loading of images, WebP and AVIF support, the CDN, and whether a custom theme adds too much code to every page. You’ll find more practical tips in the article Fastest CMS: how to improve its performance and speed up the site? It’s worth combining a performance audit with Drupal support and maintenance so that the recommended fixes don’t stay in the report.
- Scripts, consent mode, and analytics
After two years, analytics is often one of the most neglected parts of a website. GA4 was implemented in a hurry, conversion definitions stopped matching after the forms were rebuilt, and the cookie banner was configured once and never revisited. As a result, the team makes decisions based on data it shouldn’t trust.
In 2026, an audit should cover not only GA4 but also consent mode, Google Tag Manager, events, paid campaigns, and whether tags fire only after the user gives consent. Google describes consent mode as a mechanism that adjusts data collection for ads and analytics to the consent users give. A poorly implemented consent mode can cause data loss and the risk of breaking privacy regulations at the same time.
Check:
- whether GA4 events match your current forms and CTAs,
- whether Google Ads counts clicks that don’t lead to a real action as conversions,
- whether GTM loads unused tags,
- whether consent mode v2 is implemented correctly,
- whether ad scripts hurt INP and LCP,
- whether reports show the data you need for decisions, not just nice charts,
- whether lead source information reaches your CRM correctly.
In this area, marketing and the development team have to work together. Marketing knows what to measure. Developers know whether a specific implementation makes sense and whether it slows the site down.
- CMS and framework security updates
If your website runs on an open source CMS or framework, after two years you need to check the state of updates. Not “we’ll update someday,” but specifically: the core version, modules, plugins, Composer and npm packages, PHP, the database, the server, the cache configuration, the admin panel, and integrations.
The 2025 edition of the OWASP Top 10 still shows that web applications keep running into the same risk categories. The Drupal community publishes security advisories for core and contributed modules. CISA maintains a catalog of known vulnerabilities that are actively exploited in attacks. These aren’t theoretical lists for auditors. Following these sources regularly is part of routine website maintenance.
In a security audit, check:
- whether your CMS or framework version is still supported,
- whether modules and plugins have active maintainers,
- whether the project contains abandoned libraries,
- whether Composer and npm report known vulnerabilities,
- whether the admin panel is protected with multi-factor authentication (MFA) and user roles have limited permissions,
- whether forms are protected against spam and abuse,
- whether backups can actually be restored,
- whether it’s clear who responds to critical security advisories and how quickly.
For Drupal, also check whether the site has stayed on an older minor version that no longer receives security fixes, and whether custom code is blocking updates. We explain why security advisories need a faster response today than they used to in the article Drupal security updates in the AI era. If you’re planning a bigger update, also see what an upgrade to Drupal 11 involves.
- Digital accessibility
Accessibility is no longer a “when we have time” topic. The European Accessibility Act has applied since June 28, 2025, and covers selected products and services, including ecommerce, banking, transportation, telecommunications services, and e-books. The latest version of the guidelines is WCAG 2.2, and it’s worth following even if your organization doesn’t yet have a formal legal obligation.
After two years, accessibility often gets worse because of everyday content editing. Missing alt text appears, along with broken heading hierarchy, text placed in images, banners that can’t be operated with a keyboard, new colors introduced without a contrast check, and forms without clear error messages.
Check:
- the contrast of text and buttons,
- keyboard navigation,
- a visible focus indicator on the active element,
- alt text for images,
- the heading structure,
- form field labels,
- error messages,
- the accessibility of menus, modal windows, and dynamic components,
- the accessibility of PDF files published on the site.
This isn’t only a legal requirement. An accessible website is usually easier for everyone to use, especially on a phone, in poor light, in a hurry, or on a slower connection. We describe how to approach accessibility in Drupal in the article How to build an inclusive website? Drupal accessibility tips and tricks.
- Forms, conversions, and integrations
Many companies judge a website by its traffic rather than by what users do on it. After two years, walk through the most important user journeys the way a customer would: arriving from Google, reading a service page, clicking a CTA, filling out a form, receiving a confirmation, the lead being saved in the CRM, and the sales team being notified.
It sounds trivial. In practice, this is exactly where the gaps show up: the form works, but the lead reaches the CRM without a source. A CTA leads to an old page. An automatic notification goes to someone who no longer works at the company. The message after submitting a form doesn’t say what happens next. The German version of the form has different fields than the English one.
In the audit, check:
- whether all forms send data where they should,
- whether field validation messages are clear,
- whether marketing consents are up to date,
- whether confirmation emails still have the correct content,
- whether the source, campaign, and landing page are recorded for each lead,
- whether CTAs match your current offering,
- whether all language versions guide users the same way,
- whether your most important landing pages clearly show the next step.
If your website runs on Drupal, these problems can often be fixed without rebuilding the whole site, through changes to the Webform module, CRM integrations, Views, CTA blocks, and the content structure. For bigger changes, plan further Drupal development to remove the cause of the problem, not just its symptoms.
- Monitoring, backups, and an incident response plan
The last area is the least spectacular, but neglecting it often costs the most. After two years, your website should have a clear plan: what you monitor, who gets alerts, who responds, where the backups are, how long it takes to restore them, and what counts as an incident.
The minimum to check:
- uptime monitoring for the site and key user journeys,
- monitoring of SSL certificate and domain expiration,
- alerts for 5xx errors,
- application and server logs,
- database and file backups,
- a backup restore test,
- an escalation contact list,
- a procedure for responding to critical vulnerabilities,
- a separate staging environment.
Without these, the team reacts only when a customer or the management board notices the problem. That way of working is risky. A company website, especially in B2B, finance, education, healthcare, or ecommerce, has to be treated as a business system, not a collection of pages. If you don’t have a plan like this yet, start with server and application monitoring.
What to do after the audit?
A good audit doesn’t end with a PDF report. It should end with a decision: what we do now, what we plan for later, and what we don’t do at all. After two years, there’s usually no shortage of topics. What’s missing is priorities.
I suggest a simple split:
- critical: security, broken forms, indexing errors on important pages,
- quick fixes: metadata, CTAs, redirects, heavy images, unused tags,
- planned work: theme refactoring, accessibility fixes, content cleanup,
- strategic decisions: a CMS upgrade, an architecture change, redesigning selected user journeys.
An audit rarely shows that you need to build the website from scratch. More often, it shows which elements are worth changing in stages. We describe this approach in the article Don’t rebuild, evolve: a phased CMS modernization framework.
If your website runs on Drupal and nobody has audited it in a long time, start with a technical review: SEO, performance, security, accessibility, analytics, and the content publishing process. At Droptica, we help teams maintain and develop Drupal websites, from day-to-day support to bigger architecture changes. If you want to check the state of your system and set priorities first, see our Drupal code audit.
If you’d rather get a specific list of risks and recommended actions than guess, contact us. We’ll check what really needs fixing and what can wait.
