1) Sin embargo, algunos de los artículos tenían RewriteCond %{HTTP_REFERER} !^$ pero otros no. ¿Podría explicar qué hace exactamente esta línea y es mejor tenerla o no?

Si ya investigaste esto un poco, entonces probablemente ya te hayas encontrado con la información, que la referencia es bastante poco confiable.

Podría ser "falso" o completamente bloqueado; algunas extensiones de privacidad del navegador o firewalls personales hacen esto, por ejemplo.

La condición !^$ coincide si la referencia no está vacía. Entonces, en combinación con el resto, se seguirá permitiendo el acceso, si el cliente envía un referente vacío, resp. ese encabezado de solicitud no está configurado en absoluto. Si envía una referencia desde un dominio diferente a los que usted permite explícitamente, o si la referencia contiene algo como Blocked by Extension XYZ for Privacy Reasons , el acceso seguirá bloqueado.

2) Además, con respecto a la última línea de código, noto dos enfoques diferentes, uno

 RewriteRule \.(jpg|jpeg|png|gif)$ http://example.com/nohotlinking.jpg [NC,R,L]

y el otro

 RewriteRule .*\.(jpg|jpeg|png|gif)$ http://example.com/nohotlinking.jpg [NC,R,L]

cuál sería la diferencia si incluyo el ".*" y una vez más cuál recomendaría usar.

Dado que ambos patrones solo están anclados al final, permiten cualquier carácter arbitrario delante de ellos.

El primer patrón dice, haga coincidir cualquier solicitud que termine con .jpg (y todas las demás extensiones enumeradas, por supuesto), mientras que el segundo coincide con cualquier solicitud que termine con *.jpg . ( * se usa en una sintaxis glob que significa aquí, no en el significado de una expresión regular).

Entonces, la diferencia aquí es más bien de naturaleza "filosófica", el efecto final es más o menos el mismo.

3) En tercer lugar, me preguntaba si hay alguna manera de agregar automáticamente todas las extensiones de archivo a esta regla y ¿sería una buena idea?

Puede obtener lo genérico con su patrón de expresiones regulares allí, como desee. RewriteRule .* https://… para hacer coincidir absolutamente cualquier cosa, por ejemplo.

Pero eso no es una buena idea. Es probable que sus propios documentos HTML también se vinculen desde otros sitios, como la página de resultados de un motor de búsqueda. En ese caso, la referencia generalmente sería ese otro sitio, pero no desea bloquear el acceso a sus páginas HTML en esta situación ahora, ¿verdad?

4) Por último, ¿este método crearía algún problema al compartir un artículo en plataformas de redes sociales o para el rendimiento general de SEO del sitio web?

Puede crear problemas, por ejemplo, cuando la plataforma intenta solicitar una imagen para usarla como miniatura de un enlace que comparte. Los raspadores que usan estas redes sociales, por lo general, no envían su dominio como referencia, pero tampoco creo que tengan muchas razones para enviar uno diferente , por lo que es probable que la referencia esté vacía, y luego la condición discutida en 1) tendría esto cubierto.

Sin embargo, estos raspadores generalmente envían un encabezado User-Agent específico, de modo que se pueden agregar más excepciones, en función de eso, si es necesario.