Auditing WordPress plugins on a client site

Auditing WordPress plugins on a client site is one of the first things you should do before making major changes to an existing installation.

A plugin list tells you which extensions are installed, but it does not tell you why they are there, which parts of the website depend on them, who owns their licenses or what will break if one disappears.

Client websites often contain years of accumulated decisions: plugins installed by previous agencies, temporary tools that became permanent, duplicate functionality, expired premium licenses, forgotten integrations and custom code depending on extensions nobody remembers.

A proper plugin audit turns that unknown stack into something understandable.

In this guide, we will look at how to review WordPress plugins systematically, identify risk and dependency areas, document the current setup and decide what should be kept, replaced, updated or investigated further.

What is a WordPress plugin audit?

A WordPress plugin audit is a structured review of the plugins installed on a website.

The goal is to understand:

• which plugins are installed;
• which are active or inactive;
• what each plugin is responsible for;
• whether the functionality is still needed;
• whether plugins overlap;
• whether important dependencies exist;
• whether the plugin is maintained;
• whether licensing is under control;
• whether removal would affect content or integrations.

An audit should happen before cleanup.

Deleting plugins first and investigating broken functionality afterward is not an audit. It is a considerably less elegant form of archaeology.

Once the audit is complete, use A WordPress plugin cleanup checklist to move from discovery into safe removal and consolidation.

Why audit plugins before touching a client site?

When you inherit an existing WordPress website, you usually do not have the historical context behind every technical decision.

A plugin may look unnecessary while quietly handling something important.

For example, an unfamiliar plugin could be responsible for:

• custom post types;
• custom fields;
• payment processing;
• SMTP delivery;
• redirects;
• security rules;
• scheduled imports;
• CRM synchronization;
• analytics;
• critical shortcodes.

Understanding the plugin stack before making changes reduces the risk of breaking functionality that was not immediately visible.

Start with a complete inventory

The first step is to record every installed plugin.

In WordPress, begin with:

Plugins → Installed Plugins

Do not limit the audit to active plugins.

Record:

• active plugins;
• inactive plugins;
• network-activated plugins on multisite;
• must-use plugins;
• hosting-specific integrations;
• custom plugins.

A useful inventory might contain:

Plugin
Status
Purpose
Version
License
Owner
Dependencies
Notes

Record active and inactive plugins separately

Inactive plugins deserve their own review.

Some may have been disabled recently for troubleshooting, while others may have remained unused for years.

For every inactive plugin, ask:

• why is it still installed?
• when was it last used?
• is it part of a rollback plan?
• was it replaced by another plugin?
• does anyone still understand its purpose?

An inactive plugin is not automatically safe to delete, but a long-forgotten inactive plugin is certainly worth investigating.

Review must-use plugins

Must-use plugins, commonly called MU plugins, can be easy to overlook because they do not behave like ordinary plugins.

They are typically stored in:

wp-content/mu-plugins/

MU plugins can contain:

• hosting configuration;
• security rules;
• custom business logic;
• performance modifications;
• multisite functionality;
• agency-specific tools.

WordPress automatically loads PHP files located directly inside the must-use plugin directory, and these plugins are not activated and deactivated through the normal Installed Plugins workflow. See the official WordPress documentation on must-use plugins.

Do not assume the normal Plugins screen tells the complete story.

Identify custom plugins

Custom plugins deserve particular attention during a client audit.

A plugin with a company-specific or generic internal name may contain functionality that cannot simply be downloaded again from a public repository.

Check:

• who developed it;
• whether the source code is documented;
• whether a repository exists;
• whether it is still maintained;
• which PHP version it expects;
• which other plugins it depends on;
• whether the current agency owns or has access to the source.

A custom plugin without documentation is not necessarily bad, but it deserves a higher level of scrutiny.

Determine what every plugin actually does

For every installed plugin, write down its real purpose on the site.

A useful description is:

Handles contact forms and sends submissions to HubSpot

rather than:

Forms plugin

The more specific the description, the easier future decisions become.

Ask:

• what visible feature depends on it?
• does it affect the frontend?
• does it affect only wp-admin?
• does it connect to an external service?
• does it store important data?
• does it register content structures?

Do not trust plugin names alone

Plugin names rarely describe their full responsibility.

An SEO plugin may also manage:

• canonical URLs;
• XML sitemaps;
• robots directives;
• social metadata;
• schema markup;
• redirects.

If you are considering replacing an SEO plugin, map those responsibilities before the migration. SEO titles, descriptions, canonical settings and other metadata may be stored differently by each plugin, so see Migrating SEO fields between WordPress plugins before assuming that activating the replacement is the entire migration.

A security plugin may also handle:

• 2FA;
• login limits;
• firewall rules;
• audit logs;
• file scanning.

Removing one visible feature can therefore remove several invisible ones too.

Identify business-critical plugins

Not every plugin deserves the same level of concern.

Mark plugins that are critical to revenue, operations or access.

Examples include plugins handling:

• WooCommerce checkout;
• subscriptions;
• payments;
• membership access;
• booking systems;
• forms generating leads;
• customer accounts;
• authentication;
• backups;
• business integrations.

These plugins should receive stricter testing before updates, replacement or removal.

Check for duplicate functionality

Plugin stacks often contain multiple tools solving the same problem.

Common examples include:

• two SEO plugins;
• multiple caching plugins;
• several image optimization plugins;
• multiple security plugins;
• two SMTP plugins;
• several analytics integrations;
• multiple redirect managers;
• two code snippet managers.

Duplicate functionality does not automatically mean one plugin can be removed immediately.

You first need to understand which plugin currently owns which configuration.

Look for overlapping rather than identical functionality

Two plugins do not need to be exact duplicates to create overlap.

For example:

Plugin A:
SEO metadata + sitemap

Plugin B:
SEO metadata + redirects

Plugin C:
Redirects + 404 logging

There may be no exact duplicate, but several responsibilities overlap.

Mapping features by responsibility can reveal consolidation opportunities that a simple plugin count does not show.

Check plugin dependencies

Some plugins explicitly depend on others.

WordPress also supports declared plugin dependencies through the Requires Plugins header. Core can use that information to prevent plugin operations that would leave declared dependencies unresolved. See the WordPress Plugin Dependencies reference.

Other dependencies are informal and exist only because of how the website was built.

For example, a custom addon may assume another plugin provides:

• a specific class;
• a function;
• a custom post type;
• a hook;
• a database table;
• a REST API endpoint.

Before removing an apparently redundant plugin, inspect custom code and related addons.

Search for shortcodes

Shortcodes are one of the most common hidden plugin dependencies.

A page might contain:

[contact_form id="42"]

or:

[gallery_plugin category="portfolio"]

If the plugin disappears, the content may stop rendering or expose the raw shortcode.

Search posts, pages and custom post types before removing shortcode-based plugins. If you need to understand how these embedded commands are registered and rendered, see WordPress Shortcodes Explained for Beginners.

Check Gutenberg block dependencies

Plugins can register custom Gutenberg blocks.

Existing content may rely on those blocks even if nobody regularly opens the plugin settings anymore.

Review important:

• pages;
• posts;
• patterns;
• templates;
• reusable blocks;
• custom post types.

Removing a block plugin can leave unsupported or invalid blocks in the editor.

Check page builder addons

Elementor, Bricks and other page builders commonly have addon plugins that provide additional elements or dynamic functionality.

An addon may be used only once on the entire website but still be essential to that page.

Check:

• global templates;
• headers and footers;
• landing pages;
• dynamic templates;
• form actions;
• query loops;
• conditions.

Do not assume an addon is unused because its settings page looks empty.

Review custom post types and taxonomies

Plugins may register content structures that disappear from the dashboard when the plugin is deactivated.

Audit whether a plugin creates:

• custom post types;
• custom taxonomies;
• custom statuses;
• custom admin menus.

The actual posts may remain in the database, but WordPress may no longer know how to expose them correctly without registration code.

When a plugin owns an important content type, record its post type key, rewrite configuration, archive behavior and any associated taxonomies before changing the component that registers it.

Review custom field plugins

Custom field systems often sit deep inside a site’s architecture.

They may control data used by:

• templates;
• dynamic content;
• API responses;
• conditional logic;
• forms;
• custom admin interfaces.

Never remove a custom field plugin simply because the frontend appears normal during a quick visual check.

Inspect custom code for plugin references

If the client site contains a child theme, custom plugin or code snippets, search for references to important plugins.

Useful search targets include:

• class names;
• function names;
• constants;
• hooks;
• shortcodes;
• REST routes;
• plugin-specific helpers.

A custom integration can create a dependency even when WordPress itself does not declare one explicitly.

Review scheduled tasks

Plugins can register recurring WordPress cron jobs.

These may handle:

• imports;
• exports;
• emails;
• subscription processing;
• cleanup tasks;
• API synchronization;
• reports;
• cache regeneration.

WordPress provides WP-Cron as its scheduling system, and plugins can register recurring events that execute without a user manually opening the plugin interface. See the official WordPress documentation on WP-Cron.

A plugin may appear inactive from a user’s perspective while performing important scheduled work in the background.

Audit external integrations

Many WordPress plugins exist mainly to connect WordPress to another platform.

Look for integrations with:

• payment gateways;
• CRM systems;
• email marketing platforms;
• analytics services;
• accounting systems;
• cloud storage;
• Telegram;
• Slack;
• external APIs.

Record both sides of the integration.

If a plugin connects WordPress to an external service, identify who owns the external account and who controls the credentials.

Audit API keys and credentials

Client sites frequently contain credentials nobody can clearly attribute.

You may find:

• API keys;
• OAuth connections;
• webhook secrets;
• SMTP credentials;
• license keys;
• service tokens.

For each credential, determine:

• which service it belongs to;
• who owns the account;
• whether the client controls it;
• whether it is still required;
• whether it should be rotated.

Check premium plugin ownership

Premium plugins often create maintenance problems when nobody knows who owns the license.

Common situations include:

• license owned by a previous agency;
• license tied to a freelancer’s account;
• subscription expired;
• plugin installed from an unknown source;
• client does not have access to updates.

For every important premium plugin, record:

License owner
Renewal date
Account access
Update source
Support access

Check whether premium plugins still receive updates

A premium plugin may continue functioning after its subscription expires while losing access to new releases.

This creates a future maintenance problem even if the site currently works.

If the plugin is business-critical, decide whether to:

• renew the license;
• move the license to the client’s ownership;
• replace the plugin;
• plan a controlled migration.

Check plugin maintenance status

Review whether important plugins are still maintained.

Useful signals include:

• recent releases;
• compatibility with the current WordPress version;
• compatibility with the current PHP version;
• security updates;
• developer activity;
• working support channels.

A plugin being old does not automatically make it dangerous.

A small plugin may be perfectly stable for years if its functionality rarely needs to change.

The real question is whether the plugin remains compatible, secure and supportable.

Identify abandoned plugins

An abandoned plugin deserves additional attention when it performs an important function.

Warning signs can include:

• very old releases;
• known compatibility failures;
• unresolved security problems;
• deprecated PHP code;
• broken support channels;
• no evidence of active maintenance.

If an essential plugin appears abandoned, document a replacement plan rather than waiting until a WordPress or PHP upgrade forces the decision.

Review outdated plugins

Do not immediately click Update All during the first audit.

Before updating a heavily customized client website, understand what you are changing.

For each outdated plugin, determine:

• how far behind it is;
• whether updates contain breaking changes;
• whether the site contains overrides;
• whether custom code depends on old behavior;
• whether a staging environment exists;
• whether rollback is possible.

Record these findings before applying updates so the audit remains a useful baseline rather than becoming a moving target while you are still investigating it.

Do not confuse an audit with an update session

An audit is primarily about understanding the current state.

You may discover updates that should be applied, but documenting the situation first gives you a baseline.

If you update twenty plugins immediately and the site changes behavior, you have already destroyed part of the evidence you were trying to understand.

Review plugin auto-update settings

During the audit, record whether important plugins use automatic updates.

Automatic updates can be useful, but the right policy depends on the site.

A brochure website and a complex WooCommerce installation may justify different update strategies.

For critical plugins, ask:

• are auto-updates enabled?
• who monitors failures?
• is there automatic backup?
• is rollback available?
• does staging exist?

Check compatibility with the PHP version

Older plugin stacks can become a major obstacle when the server needs a PHP upgrade.

Look for plugins using:

• deprecated PHP features;
• unsupported libraries;
• old syntax;
• legacy integrations.

A site may appear stable simply because the server has remained on an old PHP version to accommodate one forgotten plugin.

Test PHP version changes in a staging or otherwise isolated environment before applying them to production.

Review plugin performance impact

A plugin audit should also identify components that create significant performance overhead.

Do not judge solely by plugin count.

Investigate behavior such as:

• slow database queries;
• large numbers of queries;
• large autoloaded options;
• external HTTP requests;
• heavy frontend JavaScript;
• large CSS files;
• frequent scheduled tasks;
• expensive admin processing.

One badly behaving plugin can create more overhead than dozens of lightweight ones.

Review frontend assets

Some plugins load CSS or JavaScript across the entire website even when their feature appears on only one page.

Check whether plugins add:

• large JavaScript bundles;
• duplicate libraries;
• unused stylesheets;
• third-party tracking scripts;
• external fonts;
• frontend API calls.

This information can help prioritize optimization work after the audit.

Review database usage

Plugins may create substantial database structures.

Look for:

• custom tables;
• large options;
• autoloaded data;
• post metadata;
• user metadata;
• logs;
• transients.

The purpose is not to immediately delete unfamiliar data.

It is to understand which plugins own significant database resources.

Database growth can continue long after the feature responsible for it stops being actively used. For a broader look at revisions, transients, logs, orphaned metadata and other sources of unnecessary growth, see WordPress database bloat, explained.

Check plugin log growth

Some plugins generate logs that grow indefinitely if nobody configures retention.

Common examples include:

• security logs;
• email logs;
• debug logs;
• webhook logs;
• automation logs;
• audit trails.

A plugin may be perfectly useful while its historical data quietly consumes most of the database.

Check filesystem usage

Plugins can also create files inside locations such as:

wp-content/uploads/

Possible examples include:

• backups;
• generated images;
• PDF exports;
• cache files;
• logs;
• temporary imports.

Record large plugin-generated directories, especially when storage usage is unexpectedly high.

Audit security-related plugins carefully

Security plugins often overlap heavily with hosting or server-level protections.

A site may simultaneously use:

• a WordPress firewall plugin;
• a hosting firewall;
• Cloudflare;
• login attempt limiting;
• 2FA;
• malware scanning.

This does not automatically mean the configuration is wrong.

However, understand which layer owns each responsibility so security settings do not conflict or duplicate effort unnecessarily.

Audit caching plugins against server caching

Caching is another common source of duplicated configuration.

A client site might use:

• a WordPress page cache plugin;
• server-level full-page cache;
• Redis object cache;
• CDN caching;
• browser caching.

Determine what each layer does before disabling anything.

Two caching systems may complement each other, conflict with each other or be doing the exact same job. Naturally, the plugin names will rarely volunteer this information.

Audit SEO plugins for overlapping output

If multiple SEO tools are installed, inspect the rendered frontend output.

Check whether more than one component produces:

• title tags;
• meta descriptions;
• canonical URLs;
• robots directives;
• Open Graph metadata;
• schema markup;
• XML sitemaps.

Duplicate SEO output can create inconsistent signals and make configuration difficult to understand.

If one SEO plugin is going to replace another, inventory not only visible frontend output but also the stored metadata that will need to survive the change. The migration itself should be treated as a data transition rather than a simple deactivate-and-activate operation.

Audit backup plugins

A client site may contain several backup systems without anyone knowing which one is actually reliable.

For every backup plugin, identify:

• what is backed up;
• how often;
• where backups are stored;
• how long they are retained;
• whether encryption is used;
• whether restoration has been tested.

A backup system should be evaluated by recoverability, not by the comforting presence of a green status icon.

Audit form plugins and submission storage

Forms can affect lead generation, privacy and email delivery.

For each form system, determine:

• which pages use it;
• where submissions are stored;
• where emails are sent;
• whether CRM integration exists;
• whether spam protection is configured;
• whether obsolete submissions are retained indefinitely.

If forms depend on email delivery, remember that the form plugin and the mail transport layer may be separate responsibilities. An SMTP plugin can therefore remain critical even if it has no visible frontend interface.

Review user-facing authentication plugins

Plugins affecting login and authentication deserve careful handling.

These may manage:

• custom login URLs;
• 2FA;
• login attempt limits;
• social login;
• LDAP or SSO;
• membership authentication.

Do not deactivate authentication plugins casually on a production site without understanding the recovery path.

Review plugins modifying user roles and capabilities

Some plugins change WordPress permissions.

Audit whether custom roles or capabilities depend on a plugin.

Removing the management interface may leave custom capabilities in the database while making them difficult to understand or maintain.

Record any non-standard roles and their purpose. If you need to map what those roles actually allow before replacing a permissions plugin, see WordPress user roles and capabilities, explained.

Check whether plugins are actually used by current staff

A technically functioning plugin may still be obsolete from a business perspective.

Ask the client or content team whether they still use:

• old newsletter integrations;
• legacy galleries;
• unused popups;
• abandoned analytics tools;
• old marketing widgets;
• retired booking systems.

The website cannot tell you whether a business process ended three years ago. Humans remain inconveniently necessary for that part.

Interview the client before deleting uncertain plugins

When a plugin’s purpose is unclear, ask targeted questions.

Instead of asking:

Do you use this plugin?

ask:

Do new contact form submissions still need to be sent to Salesforce?

Clients may not recognize plugin names, but they usually understand their own business processes.

Check previous documentation

Before concluding that nobody documented the site, look for:

• README files;
• Git repositories;
• deployment notes;
• agency handover documents;
• hosting documentation;
• support tickets;
• internal client notes.

A forgotten note can save considerable reverse engineering.

Create a risk classification

Not every plugin needs the same priority.

You can classify plugins using a simple system such as:

Critical
Important
Low impact
Unknown

For example:

WooCommerce Payments     Critical
Custom Fields            Critical
SEO plugin               Important
Admin color utility      Low impact
Unknown legacy plugin    Unknown

The Unknown category deserves investigation, not immediate deletion.

Create an action status for each plugin

After the audit, assign a proposed action.

Useful statuses include:

Keep
Update
Investigate
Replace
Consolidate
Remove
License review
Security review

This converts the inventory into an actual maintenance plan.

Separate facts from recommendations

When documenting a client audit, distinguish between what you observed and what you recommend.

For example:

Observation:
Plugin X has been inactive for 18 months.

Recommendation:
Confirm no rollback dependency and remove it.

This makes the report easier to review and avoids presenting assumptions as established facts.

Create a backup before remediation

Once the audit is complete and you begin making changes, create a current backup.

Depending on the planned work, this may include:

• database backup;
• filesystem backup;
• plugin configuration exports;
• external integration settings.

Audit first, backup second, remediation third.

There is little value in learning exactly what the site depends on and then immediately testing fate on production without a recovery path.

Use staging before high-risk changes

Changes involving critical plugins should normally be tested in staging first.

This is particularly important for:

• WooCommerce;
• membership systems;
• page builders;
• custom field frameworks;
• SEO plugins;
• authentication systems;
• multilingual plugins;
• caching systems.

The goal is not merely to see whether the homepage still loads. Reproduce the workflows that depend on the plugin, inspect logs and verify data before the production environment is changed.

Do not remove plugins during the discovery phase

During the initial audit, resist the temptation to clean up immediately.

Discovery should establish the current state first.

Once the inventory and dependencies are documented, cleanup becomes a separate controlled process.

This is especially useful on client sites because you can explain proposed changes before implementing them.

What should a client plugin audit report contain?

A practical report does not need to be excessively complicated.

For each plugin, include:

• name;
• status;
• purpose;
• criticality;
• maintenance status;
• license status;
• known dependencies;
• external integrations;
• recommended action;
• notes.

For example:

Plugin: Example Forms Pro
Status: Active
Purpose: Contact forms + HubSpot integration
Criticality: Important
License: Expired
Dependency: Contact and quote pages
Action: Renew or migrate
Notes: Test CRM integration before replacement

Red flags during a WordPress plugin audit

Some findings deserve immediate attention.

Examples include:

• unknown plugins with administrator-level functionality;
• premium plugins from unofficial sources;
• abandoned critical plugins;
• expired licenses blocking security updates;
• multiple conflicting caching systems;
• duplicate SEO output;
• hard-coded API credentials;
• plugins depending on unsupported PHP versions;
• large uncontrolled log tables;
• former agency accounts controlling essential services.

These do not all require instant removal, but they should be prioritized in the remediation plan.

Green flags during a plugin audit

A healthy plugin stack usually has several positive characteristics.

For example:

• every important plugin has a known purpose;
• licenses are owned by the client or clearly documented;
• plugins are maintained;
• critical dependencies are known;
• external accounts are accessible;
• staging exists;
• backups are tested;
• custom plugins are documented;
• duplicate functionality is limited;
• credentials are stored securely.

A practical WordPress plugin audit workflow

You can use the following sequence when taking over a client site.

Step 1: Record every installed plugin

Include active, inactive, must-use, network and custom plugins.

Step 2: Document purpose

Identify what each plugin actually does on the website.

Step 3: Assign criticality

Separate business-critical plugins from low-impact utilities.

Step 4: Map dependencies

Check shortcodes, blocks, custom fields, page builders, custom code and external integrations.

Step 5: Review update and maintenance status

Identify outdated, abandoned or incompatible plugins.

Step 6: Review licenses

Determine who owns premium subscriptions and whether updates remain available.

Step 7: Review credentials

Document API keys, external accounts, OAuth connections and service ownership.

Step 8: Check overlap

Identify plugins providing duplicate or competing functionality.

Step 9: Review performance impact

Look for heavy queries, large frontend assets, external requests and large database usage.

Step 10: Review security impact

Prioritize authentication, security, payment and privileged administration plugins.

Step 11: Assign a recommended action

Use statuses such as Keep, Update, Replace, Investigate or Remove.

Step 12: Present the audit before remediation

Document findings and agree on high-risk changes before altering production.

WordPress plugin audit checklist

• List every installed plugin.
• Record active and inactive status.
• Review must-use plugins.
• Identify custom plugins.
• Document the purpose of each plugin.
• Mark business-critical plugins.
• Identify duplicate functionality.
• Map plugin dependencies.
• Search for plugin shortcodes.
• Check Gutenberg blocks.
• Review page builder addons.
• Review custom post types and taxonomies.
• Review custom fields.
• Search custom code for plugin references.
• Review scheduled tasks.
• Review external integrations.
• Document API keys and credentials.
• Check premium plugin ownership.
• Check license renewal status.
• Review plugin maintenance status.
• Identify abandoned plugins.
• Record outdated plugins.
• Review auto-update settings.
• Check PHP compatibility.
• Review performance impact.
• Review frontend assets.
• Review database usage.
• Check plugin-generated logs.
• Check filesystem usage.
• Review security plugins.
• Review caching layers.
• Check for duplicate SEO output.
• Review backup systems.
• Review form and lead-generation plugins.
• Review authentication plugins.
• Review role and capability plugins.
• Ask the client about unclear business processes.
• Review existing documentation.
• Assign plugin risk levels.
• Assign recommended actions.
• Create a remediation plan before making changes.

What to do after the audit

Once the plugin audit is complete, you can move into cleanup and remediation.

Typical next steps include:

• updating maintained plugins;
• renewing important licenses;
• moving licenses into client ownership;
• replacing abandoned plugins;
• consolidating duplicate functionality;
• removing confirmed unused plugins;
• rotating obsolete credentials;
• documenting custom integrations;
• testing changes in staging.

Once dependencies have been documented, use A WordPress plugin cleanup checklist for the controlled removal phase.

Using TheOneWP during a plugin audit

A plugin audit often reveals that a WordPress installation contains many separate plugins providing small administrative, SEO, security or utility functions.

TheOneWP uses a modular architecture where individual features can be enabled only when required.

This can help reduce the number of independent utility plugins that need separate maintenance while still allowing unused functionality to remain disabled.

The purpose of an audit, however, is not simply to replace many plugins with one plugin.

The important goal is to understand responsibility.

Every feature should have a clear owner, a known configuration and a documented reason for existing.

Consolidation only makes sense when functionality can be replaced safely without losing required behavior or data.

Final thoughts on auditing WordPress plugins on a client site

Auditing WordPress plugins is one of the most valuable steps when taking responsibility for an existing client website.

Before updating, replacing or deleting anything, understand the current plugin stack and the business processes behind it.

Inventory active and inactive plugins, identify custom and must-use code, document dependencies, review licenses, check external integrations and determine which plugins are truly critical.

Then classify the findings and turn them into a controlled remediation plan.

A good audit replaces assumptions with documentation.

Once you know why every important plugin exists and what depends on it, cleanup and future maintenance become considerably safer.

The real objective is not to produce a site with the smallest possible number of plugins. It is to produce a site where every remaining plugin has a clear purpose, known ownership and an understandable place in the architecture.