Drupal SEO audit checklist

Run the crawl at a rate the site can absorb, outside peak traffic, and agree the limits with whoever operates the hosting before the first request. Set a low concurrency and a delay between requests, identify the crawler with a clear user agent, and stop early if response times climb or error rates rise. Crawl from a sample of templates first, then expand. Heavy crawls also trigger cache misses, so ask the operations team whether a crawl can be run against a read-only replica or a staging copy with the same content and configuration. Record the crawl settings in the audit so the results can be reproduced.

Use a staging copy for anything that changes data, runs cron jobs or sends email, and use production only for read-only checks that the team has approved. A staging copy made from a recent production database contains the same URLs, aliases, metatags and redirects, which is what the audit needs. Confirm that staging is protected by authentication or network controls, that it does not index publicly, and that outbound email and payment or CRM connectors are disabled. Ask who owns the copy and when it is deleted.

Access logs, Drupal watchdog entries, form submissions, user records and staging databases can all contain personal data such as IP addresses, email addresses and account names. Limit who can read them, keep the audit to the fields it needs, and redact or pseudonymize where possible. Agree a retention period for the copies and logs with the data protection owner, and remove them when the audit closes. Ask your privacy team whether a staging copy of production data needs the same handling as production.

Do not share an administrator password with the auditor. Create a named, time-limited account with the narrowest role that lets the auditor view the configuration, such as the permissions needed to read metatag, alias, redirect and sitemap settings, and remove it when the audit ends. Require multi-factor authentication where the site supports it, keep the credentials out of tickets and chat, and rotate any credential that was exposed. Check that the account cannot change content or users unless the work requires it.

Store audit exports, crawl data, redirect maps and screenshots in a restricted repository or document space that only the audit team and the site owners can open. Exports often include internal URLs, unpublished content titles, user data and configuration details that are useful to an attacker. Do not place them in a public web root, an open file share, a public issue tracker or a shared spreadsheet with external links enabled. Set an expiry for the files and delete working copies when the engagement closes.

Yes. Before applying a module or core change recommended by the audit, check the Drupal Security Team advisories for the affected project and version, because a fix may already be shipped in a newer release or a vulnerable version may be the one running in production. The Drupal Security Team publishes advisories with CVE identifiers and risk scores, and security releases come out on the third Wednesday of the month. Plan audit fixes so they follow the same routine as security updates: test in staging, then deploy in the normal window.

Treat each audit fix as a change request that goes through the same path as any other update: code or configuration in version control, a test in staging, a review, and a deployment in an agreed window. Bugfix releases come out on the first Wednesday of each month, so a monthly routine can absorb most module updates alongside the audit work. Avoid bundling SEO changes with unrelated updates, so that any ranking or traffic change can be traced to a known release. Ask your team how rollbacks are handled before the first change goes live.

The price follows from the written scope, and no figure is given here. The main drivers are the number of pages and content types, the number of languages, how many URL patterns and redirect rules exist, whether logs and a staging copy are available for review, and how many fixes you ask the team to implement rather than only document. Ask for a quote that separates the review from any implementation work, so you can see what is one-time and what would recur if you keep the site under review. DeployOpen fixes its scope and deliverables in writing before work starts.

Duration depends on the same factors as cost: site size, the number of languages and content types, and how much historical data needs analysis. Discovery usually takes longer when documentation is thin, because the team must first learn how content is modeled and how URL aliases are generated. Ask for a timeline in the written scope with named milestones, including when crawl results, the findings report and the prioritized fix list will be delivered. Confirm which dates depend on your staff returning access or answering questions.

A useful audit needs access and documentation in four areas:

• Crawl access: a staging or production URL the crawler can reach, with credentials for any protected areas and a sitemap or list of known entry points.
• Analytics and webmaster access: read access to your analytics property and search console properties, so the team can compare crawl findings with indexing and traffic data.
• Content model documentation: content types, taxonomies, fields used for titles and summaries, and the Pathauto or Metatag patterns already in place.
• Change history: recent migrations, redirect files and any known incidents that affected traffic.

Confirm each item in the scope so that missing access is visible early.

Yes, a capable internal team can work through the checklist, provided it has a developer who can read Drupal configuration, someone who can run a crawler and interpret its output, and an SEO owner who can judge which findings affect search visibility. The hardest parts are usually the duplicate URL analysis and the redirect review, because they require knowledge of how aliases, taxonomy paths and legacy URLs interact. A partner adds independent review, prioritization and implementation capacity. Decide which parts your team will own after the audit, since the findings only matter if someone maintains the metadata defaults, sitemaps and redirects going forward.

An audit identifies technical issues and documents them with evidence, but it cannot promise a specific ranking outcome, because search results depend on factors outside the site's control. What the audit can deliver is a written list of findings, their likely effect on crawling, indexing and presentation, and a prioritized set of fixes with owners. Ask the provider to describe exactly what the deliverables contain and what would be retested after fixes are applied. Treat any claim of a guaranteed position as a warning sign.

The audit reviews publicly reachable URLs, response headers, redirect behavior and how staging environments are protected from indexing. Staging sites that are open to crawlers can create duplicate content, and exposed admin paths or verbose errors raise security concerns that the audit team should flag to your security function. Confirm in writing how crawl credentials are stored, who receives the crawl data, and how long logs and exports are retained. The audit does not produce a compliance attestation, and any regulatory review needs its own independent assessment.

Commission it before the migration when possible, so the team can capture current URLs, ranking-relevant pages, metadata and redirect history that the new site must preserve. An audit run after launch still helps, but it must work from logs and search console data to reconstruct what changed. Pair the audit with a redirect map review and launch checks if the platform is changing. Ask the provider whether the audit scope includes a baseline crawl, because that baseline is the reference for measuring whether fixes or the migration caused regressions.