How to Remove the Website Field from WordPress Comments

The default WordPress comment form can include a Website field that allows visitors to associate an external URL with their comment.

For some communities, that field is useful. A developer, designer, writer or blogger may legitimately want other participants to discover their website.

For many other websites, however, the field provides little practical value and can create an additional incentive for comment spam.

Fortunately, WordPress provides a native filter that lets you remove the Website field without editing WordPress Core, rebuilding the entire comment form or hiding the input with CSS.

The standard solution is:

add_filter(
    'comment_form_default_fields',
    function ( $fields ) {
        unset( $fields['url'] );

        return $fields;
    }
);

The official WordPress Developer Resources documentation for comment_form_default_fields specifically documents this filter and includes removal of the url field as an example.

This guide explains how to remove the Website field from WordPress comments correctly, where the code should live, why CSS-only solutions are weaker, how classic and block themes affect the result, what happens to existing commenter URLs and how to troubleshoot themes or plugins that replace the native WordPress comment form.

What is the WordPress comment Website field?

When anonymous commenting is available, a standard WordPress comment form can contain fields such as:

Name
Email
Website
Comment

The Website field is the optional URL associated with the commenter.

A visitor might submit:

Name:
Sarah

Email:
sarah@example.com

Website:
https://sarah.example/

Comment:
Thanks for the tutorial.

When WordPress or the active theme displays the comment author, that URL can be used to make the author’s name clickable.

The broader WordPress comment system, including comment configuration, moderation and enabling comments on individual content, is documented in the official Comments in WordPress documentation.

The Website field comes from the native WordPress comment form

WordPress provides the:

comment_form()

function for generating its standard comment form.

The official comment_form() documentation describes the arguments, default fields and hooks involved in constructing that form.

For logged-out visitors, the default field collection can include:

author
email
url
cookies

The field we want to remove is:

url

The Website field is different from a URL inside the comment

A commenter could provide a URL in two different places.

Inside the Website field

Website:
https://example.com/

Inside the comment itself

Thanks for the article.

My website is:
https://example.com/

Removing the Website field prevents the standard comment form from collecting the first type.

It does not prevent visitors or automated bots from typing URLs inside the actual comment content.

How WordPress stores the commenter’s Website URL

The author URL is stored separately from the comment text.

Conceptually, a comment can contain:

comment_author
→ Sarah

comment_author_email
→ sarah@example.com

comment_author_url
→ https://sarah.example/

comment_content
→ Thanks for the tutorial.

This distinction becomes important when you remove the form field because existing comment_author_url values are not automatically removed.

Why remove the Website field?

Common reasons include:

• the site does not need commenter websites;
• the field attracts link-oriented comment spam;
• you want a simpler comment form;
• you want to collect less unnecessary information;
• you do not want commenter names becoming external promotional links;
• you want fewer user-generated outbound URLs to maintain over time.

The Website field can attract comment spam

A spammer may submit a generic comment primarily because an approved comment can associate their chosen URL with the commenter identity.

The basic incentive is:

submit comment
+
provide website URL
+
comment gets approved
↓
author may receive a public link

Removing the field removes that particular mechanism from the standard form.

For a deeper explanation, see Why Comment Spam Targets the Website Field.

Removing the Website field does not require disabling comments

You can continue accepting:

• names;
• email addresses;
• comment text;
• threaded replies;
• moderated discussion.

while removing only:

Website

The correct WordPress filter

WordPress exposes:

comment_form_default_fields

for filtering the default comment form fields.

The official comment_form_default_fields hook reference describes the callback parameter as an array containing the default form fields.

Remove the Website field

The simplest implementation is:

add_filter(
    'comment_form_default_fields',
    function ( $fields ) {
        unset( $fields['url'] );

        return $fields;
    }
);

What does unset() do?

Before the filter, WordPress may conceptually have:

$fields = array(
    'author'  => '...',
    'email'   => '...',
    'url'     => '...',
    'cookies' => '...',
);

This line:

unset( $fields['url'] );

removes only:

'url'

from that array.

The remaining fields are returned to WordPress normally.

A named-function version

For production code, you may prefer a named function:

/**
 * Remove the Website field from
 * the default WordPress comment form.
 */
function mysite_remove_comment_website_field( $fields ) {
    unset( $fields['url'] );

    return $fields;
}

add_filter(
    'comment_form_default_fields',
    'mysite_remove_comment_website_field'
);

Both versions use the same WordPress API

An anonymous callback is concise.

A named function can be easier to:

• find later;
• document;
• debug;
• remove conditionally;
• reuse.

Where should the code go?

Technically, the filter can live in:

• the active theme’s functions.php;
• a child theme;
• a site-specific plugin;
• a must-use plugin;
• a maintained snippet-management system.

Use functions.php when the behavior belongs to the theme

If removing the Website field is part of a particular theme’s comment design, placing the filter in:

functions.php

can be reasonable.

But remember:

change theme
↓
old functions.php stops running
↓
Website field may return

Use site-level functionality for a permanent site policy

If your policy is:

this website never collects commenter websites

then the behavior is broader than theme presentation.

A site-specific plugin, must-use plugin or maintained snippet system generally makes the policy more portable across theme changes.

Do not edit WordPress Core

You should not modify Core files such as:

wp-includes/comment-template.php

to remove the field.

WordPress already exposes a documented filter for exactly this purpose.

Editing Core creates unnecessary maintenance problems because updates can overwrite your modifications.

Why CSS is not the best solution

You may find tutorials recommending:

.comment-form-url {
    display: none;
}

This can hide the field visually.

But it does not remove the field through WordPress’s form-generation logic.

Compare the two approaches

CSS approach

WordPress generates URL field
↓
browser receives URL field
↓
CSS hides it


WordPress filter

WordPress builds fields
↓
URL field removed
↓
browser never receives normal field

Prefer the native filter

Because WordPress provides an official hook specifically for modifying the fields, using:

comment_form_default_fields

is cleaner than hiding the control afterward.

The Website field is normally optional

Removing it does not mean you also need to remove:

• Name;
• Email;
• the comment textarea.

The Website field serves a different purpose.

Name and email requirements are controlled separately

WordPress Discussion Settings can require commenters to provide a name and email address.

The official Settings → Discussion documentation describes these comment and moderation controls.

You can therefore use:

Name
→ required

Email
→ required

Website
→ removed

Comment
→ required

Removing Website does not change whether comments are open

The filter modifies the form fields.

It does not change:

comment_status

A post can remain:

comment_status = open

while the Website field is absent.

Comment configuration is a separate layer

The distinction is:

comment_form_default_fields
→ what anonymous visitors can enter

comment_status
→ whether the post accepts comments

For the wider distinction, see WordPress Per-Post vs. Site-Wide Comment Settings.

What happens for logged-in users?

Logged-in WordPress users normally do not see the same identity fields as anonymous visitors.

WordPress already knows the authenticated account.

The form may therefore look more like:

Logged in as Sarah

Comment

[Post Comment]

This creates a common testing mistake

An administrator adds the filter, opens a post while still logged into wp-admin and sees no difference.

But the Website field may not have been visible to that authenticated user in the first place.

Always test while logged out

A useful workflow is:

1. Add the filter.
2. Clear relevant caches.
3. Open a private browser window.
4. Visit a post where comments are open.
5. Scroll to the comment form.
6. Confirm the Website field is gone.
7. Submit a legitimate test comment.
8. Confirm normal moderation still works.

Before and after

Before

Name
Email
Website
Comment

[Post Comment]

After

Name
Email
Comment

[Post Comment]

Classic themes normally respect the filter

A traditional classic theme commonly calls:

comment_form()

from its:

comments.php

template.

Because the form uses the normal WordPress APIs, filtering the default fields usually removes the URL input without requiring a template override.

The official Theme Handbook documentation for classic comment templates explains the traditional relationship between the comment template and WordPress’s comment functions.

Do not edit comments.php unnecessarily

If a classic theme already uses:

comment_form()

there is normally no reason to copy the entire comment template into a child theme merely to remove one input.

The filter is more targeted.

Block themes use a different presentation architecture

Block themes display comments through blocks rather than relying primarily on a classic comments.php template.

The official WordPress Block Themes documentation explains that block themes use blocks throughout templates and allow those templates to be edited through the Site Editor.

The Comments block contains the comment interface

WordPress provides a:

Comments

block that can contain components such as:

• Comments Title;
• Comment Template;
• Comments Pagination;
• Post Comments Form.

The official Comments block documentation describes this structure.

The Block Editor Handbook also documents the current block architecture

The current WordPress Block Editor Theme Blocks reference includes the comment-related Core blocks used in modern block-theme templates.

These include:

• Comment Author Name;
• Comment Content;
• Comment Date;
• Comment Reply Link;
• Comment Template;
• Comments;
• Comments Pagination.

Removing the Website field does not mean removing the Comments block

If your requirement is:

keep comments
+
remove Website field

then removing the entire Comments block would solve the wrong problem.

You want to modify the form data, not remove discussion from the template.

The Core Comments block remains dynamic

The current Core Comments block reference documents core/comments as a block that uses post context and contains the nested comment structure.

The frontend comment form still ultimately participates in WordPress’s broader comment system.

Classic vs block themes deserve separate testing

For more detail on the architectural differences, see WordPress Comments in Classic vs. Block Themes.

What if the Website field does not disappear?

If the normal filter is active but the field remains visible, investigate the form implementation before adding more code.

First verify your filter is actually running

Check:

• the snippet is enabled;
• the PHP has no syntax error;
• the correct theme or plugin is active;
• the code executes on frontend requests;
• the page cache has been cleared.

Then inspect the generated form

The standard solution assumes WordPress is using:

comment_form()

and its normal field filtering.

A custom theme or plugin can replace those fields.

comment_form() allows custom field definitions

The official comment_form() reference shows that themes and plugins can supply their own arguments and fields.

A custom implementation may provide something conceptually similar to:

comment_form(
    array(
        'fields' => array(
            ...
        ),
    )
);

That can change how the default field filter interacts with the form.

A plugin may replace the entire comment form

Third-party comment systems can use:

• custom HTML;
• JavaScript applications;
• AJAX submission;
• social login;
• external APIs;
• their own field definitions.

If the visible field does not come from WordPress’s normal form, comment_form_default_fields may not control it.

Inspect the frontend markup

The native Website field commonly contains an input resembling:

<input
    id="url"
    name="url"
    type="url"
/>

and may appear inside:

class="comment-form-url"

Search for name=”url”

After adding the filter and clearing caches, inspect the final rendered HTML for:

name="url"

If it no longer exists in the native comment form, the field removal is working.

Do not search only for the visible word Website

A theme can:

• translate the label;
• rename the label;
• hide labels visually.

The form-control name is a stronger technical indicator.

WordPress also has field-specific filters

Individual comment fields pass through filters following the pattern:

comment_form_field_{$name}

For the Website field:

comment_form_field_url

The Core comment_form() reference documents the filter flow used when outputting individual fields.

A field-specific fallback

You could use:

add_filter(
    'comment_form_field_url',
    '__return_empty_string'
);

to return an empty value for that rendered field.

Prefer comment_form_default_fields for the normal use case

The clearer default implementation remains:

unset( $fields['url'] );

because it removes the field from the default array before the form is composed.

Do not stack multiple removal techniques without a reason

A site should not normally need all of these:

comment_form_default_fields
+
comment_form_field_url
+
CSS display:none
+
JavaScript removal

Start with the official default-fields filter.

Add another layer only when debugging proves that something else is rebuilding or reintroducing the field.

Filter priority can matter

WordPress hooks run according to priority.

The default priority is:

10

If another theme or plugin modifies the fields later, it could theoretically restore the URL field after your callback runs.

Use a later priority when there is an actual conflict

add_filter(
    'comment_form_default_fields',
    function ( $fields ) {
        unset( $fields['url'] );

        return $fields;
    },
    100
);

Priority 100 is not automatically better

Use the normal priority first.

A later priority should solve a demonstrated ordering conflict rather than becoming unexplained boilerplate.

Removing the form field does not remove historical Website URLs

This is one of the most important distinctions.

Imagine the site contains:

12,000 existing comments

and 3,000 of them contain:

comment_author_url

Adding:

unset( $fields['url'] );

does not modify those 3,000 stored URLs.

Historical author links can continue appearing

WordPress provides:

get_comment_author_url()

for retrieving the URL associated with a comment author.

The official get_comment_author_url() documentation confirms that the function returns the stored comment-author URL when one is available.

WordPress can also render that URL as an author link

The related:

get_comment_author_link()

function retrieves the HTML representation of the comment author and can link the author’s name when a URL exists.

See the official get_comment_author_link() reference for the current Core behavior.

Future collection and historical storage are separate

comment_form_default_fields
→ controls future native form fields

comment_author_url
→ existing stored value

Do not bulk-delete old author URLs automatically

Some historical URLs may belong to legitimate contributors.

Removing future Website submissions does not automatically mean old links should be destroyed.

If you want to hide historical author URLs too

The get_comment_author_url() function passes the resulting URL through the:

get_comment_author_url

filter, as documented in the WordPress function reference.

A site that intentionally wants to suppress all stored commenter websites from display could use:

add_filter(
    'get_comment_author_url',
    '__return_empty_string'
);

This is a separate decision

Compare:

comment_form_default_fields
→ stop collecting new Website URLs

get_comment_author_url
→ stop returning stored Website URLs for display

Hiding historical URLs does not delete them

The database can still contain the original:

comment_author_url

value.

The filter changes runtime output.

Data deletion is a third operation

The three layers are:

remove field
→ no normal future collection

filter output
→ do not display stored URL

delete data
→ permanently remove historical URL

Do not confuse them.

Removing the Website field does not delete existing comments

Every historical comment can remain intact.

If comments are later disabled entirely, old comments can also remain stored.

See What Happens to Old Comments When You Disable Them.

Removing the Website field is not a complete anti-spam system

A bot can still type:

Visit https://spam.example/

inside the comment body.

Other spam may not depend on external links at all.

Continue using WordPress moderation

The official WordPress Comment Moderation documentation covers moderation options including manual approval and rules for holding potentially problematic comments.

A practical configuration may therefore combine:

Website field removed
+
comment moderation
+
anti-spam filtering
+
appropriate discussion policy

Removing Website should not be presented as a security fix

The standard URL field is legitimate WordPress functionality.

Removing it can reduce:

• spam incentives;
• untrusted outbound links;
• unnecessary form complexity;
• unnecessary data collection.

But it is not a substitute for normal site security.

It is also not a guaranteed SEO improvement

Removing commenter URLs can reduce user-generated outbound links and link-spam incentives.

That is useful.

It should not be translated into:

remove Website field
=
automatic rankings increase

There is no defensible basis for such a guarantee.

It can be a useful data-minimization choice

If the site has no use for commenter websites, there is little reason to request the information.

But remember that WordPress comments can still involve other information such as:

• name;
• email address;
• comment text;
• cookies depending on configuration;
• timestamps;
• other processing associated with comments.

Can a bot still manually send a url parameter?

Automated clients do not have to respect the visible HTML form.

They can construct requests themselves.

Removing the visible native Website field should therefore be understood primarily as:

• a form simplification;
• a reduction in normal URL collection;
• a reduction in a common spam incentive.

It is not a firewall.

Conditional removal

You can also remove the field only in certain contexts.

Example: only on standard Posts

add_filter(
    'comment_form_default_fields',
    function ( $fields ) {
        if ( is_singular( 'post' ) ) {
            unset( $fields['url'] );
        }

        return $fields;
    }
);

Use conditional behavior only when users benefit from it

For example:

Blog
→ no Website field

Developer community
→ Website field available

could make sense on a site where contributor profiles are valuable in one section but irrelevant in another.

Consistency is usually easier

If there is no meaningful reason for different behavior, a single site-wide policy is easier for:

• visitors;
• editors;
• developers;
• future maintenance.

Check custom post types

A custom post type that supports WordPress comments can also display a comment form.

Test:

• Posts;
• Pages;
• custom post types;
• plugin-generated content;
• any other comment-enabled frontend.

Be careful with WooCommerce reviews

WooCommerce product reviews are built closely around WordPress comment infrastructure.

A global comment-form filter may therefore affect contexts beyond normal blog comments.

Test:

• product review forms;
• review submission;
• anonymous review behavior;
• existing review display.

before deploying the change across a production store.

Test on staging when comments are business-critical

A staging environment is particularly useful for:

• community sites;
• large publications;
• WooCommerce stores;
• membership sites;
• custom comment systems.

See WordPress Staging Site Best Practices.

Clear caches after applying the filter

A full-page cache can continue serving old HTML containing:

name="url"

even after the PHP customization is correct.

Clear:

• WordPress caching plugins;
• server page cache;
• CDN cache where applicable;
• browser cache if necessary.

Then test again in a private window

A private session helps you verify:

• logged-out behavior;
• fresh frontend HTML;
• the anonymous comment form.

Test actual comment submission

Do not stop after confirming that the Website field disappeared.

Submit a legitimate test comment and verify:

• Name validation;
• Email validation;
• Comment validation;
• submission;
• moderation;
• redirect behavior;
• notifications if enabled.

Test error states

Try submitting the form with:

• an empty required Name;
• an invalid Email;
• an empty Comment.

The Website-field modification should not interfere with unrelated validation.

Test accessibility

After changing any frontend form, verify:

• labels remain correctly associated with fields;
• keyboard navigation remains logical;
• required fields are understandable;
• focus indicators remain visible;
• error messages remain clear.

Removing one array field preserves the rest of Core’s form

This is another advantage of the native approach.

You are not rebuilding:

• labels;
• validation;
• cookies field;
• comment textarea;
• submit controls.

You are simply removing:

$fields['url']

What if you do not need comments at all?

If the website has no use for public discussion, removing the Website field may be solving only a small part of the problem.

You would still be maintaining:

• comment forms;
• moderation;
• spam handling;
• comment administration;
• stored comment data.

In that situation, see How to Completely Disable Comments in WordPress.

TheOneWP Disable Comments

If comments are not part of the site’s workflow, TheOneWP Disable Comments provides a broader option for disabling the WordPress comment system.

This solves a different problem from removing one field.

Use the right level of intervention

Need comments and Website field?
→ keep everything

Need comments but not Website field?
→ remove $fields['url']

Need comments but no historical author links?
→ remove field + filter displayed URLs

Do not need comments?
→ disable comment functionality

Common mistakes

Hiding the field only with CSS

Use the native WordPress filter for a native WordPress form.

Editing WordPress Core

The modification will be fragile and unnecessary.

Editing comments.php unnecessarily

If the theme uses comment_form(), filter the field instead.

Testing only as Administrator

Authenticated users normally see a different comment form.

Forgetting caches

Cached HTML can make working PHP look broken.

Assuming old URLs disappear

Existing comment_author_url values remain stored.

Assuming the change eliminates spam

Spam can still arrive through the comment body and other mechanisms.

Removing unrelated fields

Target only:

$fields['url']

unless additional changes are intentional.

Ignoring custom forms

A third-party comment plugin may not use WordPress’s default field collection.

Ignoring WooCommerce reviews

Test comment-related changes before deploying them globally on an e-commerce site.

Using four different removal techniques simultaneously

Start with the native filter and add complexity only when a real conflict requires it.

Recommended production snippet

For a standard WordPress site where the Website field should be removed wherever the native anonymous comment form is used:

/**
 * Remove the Website field from
 * the default WordPress comment form.
 *
 * @param array $fields Default comment fields.
 * @return array Modified comment fields.
 */
function mysite_remove_comment_website_field( $fields ) {
    unset( $fields['url'] );

    return $fields;
}

add_filter(
    'comment_form_default_fields',
    'mysite_remove_comment_website_field'
);

Optional late-priority version

If another plugin or theme demonstrably adds the Website field back later:

/**
 * Remove the Website field after
 * other default-field callbacks.
 */
function mysite_remove_comment_website_field_late( $fields ) {
    unset( $fields['url'] );

    return $fields;
}

add_filter(
    'comment_form_default_fields',
    'mysite_remove_comment_website_field_late',
    100
);

Optional historical author-link suppression

If the policy is also to stop exposing URLs already stored with historical comments:

/**
 * Hide stored comment-author URLs
 * from normal WordPress output.
 */
add_filter(
    'get_comment_author_url',
    '__return_empty_string'
);

Do not add the historical filter unless you need it

Removing future Website submissions and hiding historical author URLs are separate requirements.

A practical decision tree

Do commenters need a Website field?
│
├── Yes
│   └── Keep it
│
└── No
    │
    ├── Remove $fields['url']
    │
    ├── Test logged out
    │
    ├── Test custom comment contexts
    │
    └── Should old author URLs remain visible?
        │
        ├── Yes
        │   └── No further action
        │
        └── No
            └── Filter author URL output

Website field removal checklist

• Decide whether commenter websites provide actual value.
• Confirm the site uses native WordPress comments.
• Review the official comment_form() behavior.
• Use comment_form_default_fields.
• Remove only $fields['url'].
• Do not modify WordPress Core.
• Do not rely on CSS as the primary method.
• Choose whether the policy belongs to the theme or the site.
• Use site-level functionality for permanent policies.
• Clear all relevant caches.
• Test while logged out.
• Inspect the HTML for name="url".
• Submit a real test comment.
• Test required-field validation.
• Test moderation.
• Test classic themes.
• Test block themes.
• Test custom post types.
• Test third-party comment plugins.
• Test WooCommerce reviews where relevant.
• Use a later hook priority only when required.
• Remember that historical URLs remain stored.
• Decide separately whether historical author URLs should remain visible.
• Do not delete historical URLs without a defined reason.
• Continue using appropriate anti-spam controls.
• Remember that URLs can still be submitted inside comment text.
• Disable comments entirely only when discussion itself is unnecessary.
• Re-test after theme or comment-plugin changes.

Related guides

• Why Comment Spam Targets the Website Field
• How to Completely Disable Comments in WordPress
• WordPress Comments in Classic vs. Block Themes
• WordPress Per-Post vs. Site-Wide Comment Settings
• What Happens to Old Comments When You Disable Them
• WordPress Staging Site Best Practices

Final recommendation

If your site uses WordPress comments but has no meaningful reason to collect commenter websites, remove the Website field through WordPress’s native comment-form API.

The standard implementation is intentionally small:

add_filter(
    'comment_form_default_fields',
    function ( $fields ) {
        unset( $fields['url'] );

        return $fields;
    }
);

This approach is supported directly by the official WordPress comment_form_default_fields documentation and is preferable to editing Core, rebuilding the entire comment template or simply hiding the field with CSS.

Keep the different layers separate:

comment_form_default_fields
→ future native form fields

comment_author_url
→ stored commenter URL

get_comment_author_url
→ URL returned for display

comment_status
→ whether comments are allowed

Removing the Website field does not delete existing comments, does not erase historical author URLs and does not completely prevent comment spam.

It removes one unnecessary input and one common incentive for link-oriented submissions.

For sites that still value discussion, that is a focused and low-complexity improvement.

For sites that do not need discussion at all, removing one field is not enough. Disable the comment system instead and remove the unused workflow entirely.