I have several legacy URLs that has /yyyy/mm in the URL, especially some hardcoded URLs in old posts.
e.g. https://www.example.com/2011/04/test-1234
I would like to forward all such URLs to delete the /yyyy/mm, and also need to keep the post ID at the end (the 1234 in example above)
i.e. https://www.example.com/test-1234
I added code below to the top of my htaccess file
RedirectMatch 301 ^\/([0-9]{4})\/([0-9]{2})\/([^\/]+) /$3
I just want to double check this won't break my site?
RedirectMatch 301 ^\/([0-9]{4})\/([0-9]{2})\/([^\/]+) /$3
This looks "OK", however, since you are missing the end-of-string anchor ($) at the end of the regex, it will also match URLs of the form /2011/04/test-1234/<anything> and discard the /<anything> part. It will also preserve any query string that might be present on the original request (if that is a concern).
Since you are using WordPress that already uses mod_rewrite (RewriteRule) directives as part of the WP code block (front-controller pattern) then you should avoid using mod_alias (Redirect and RedirectMatch) directives here in order to prevent accidental conflicts. mod_rewrite always executes before mod_alias despite the apparent order of directives in the .htaccess file. So, placing this rule at the top or bottom of the file actually makes no difference (unless you have other mod_alias directives).
There is no need to backslash-escape literal slashes in the regex since spaces are regex delimiters in Apache config files. (The only reason to escape slashes in the regex is when slashes are being used as regex delimiters. Otherwise, slashes carry no special meaning in the regex.)
There is also no need for the capturing groups for the first two path segments (year and month) since these are being discarded. ie. Don't use parenthesised subpatterns for the first two path-segments and then just use $1 in the target URL, not $3.
You should also test this first with a 302 (temporary) redirect to avoid potential caching issues. Only change to a 301 (permanent) redirect when you are sure it's working as intended. 301s are cached persistently by the browser so can make testing problematic.
Use the following mod_rewrite directive instead at the top of the .htaccess file, before the existing WordPress code block.
RewriteRule ^\d{4}/\d\d/([^\/]+)$ /$1 [QSD,R=301,L]
Note that the mod_rewrite RewriteRule directive matches against a URL-path that does not start with a slash (unlike RedirectMatch).
\d (digits) is simply a shorthand character class that is the same as [0-9].
This now only matches a URL of the form /1234/12/<slug> as per your example (and not /1234/12/<slug>/<anything>).
The QSD flag discards any query string that might be present on the initial request. eg. /1234/12/<slug>?<something> - the ?<something> query string is not passed through to the target URL.