diff --git a/content/docs/faq-structure.md b/content/docs/faq-structure.md
index b54a8fef8..2228c69ae 100644
--- a/content/docs/faq-structure.md
+++ b/content/docs/faq-structure.md
@@ -6,13 +6,13 @@ layout: docs
 category: FAQ
 ---
 
-### Is there a recommended way to structure React projects? {#is-there-a-recommended-way-to-structure-react-projects}
+### C'è un modo consigliato per strutturare progetti React? {#is-there-a-recommended-way-to-structure-react-projects}
 
-React doesn't have opinions on how you put files into folders. That said there are a few common approaches popular in the ecosystem you may want to consider.
+React non ha opinioni su come organizzi i file nelle cartelle. Detto questo, ci sono alcuni approcci popolari nell'ecosistema che potresti prendere in considerazione.
 
-#### Grouping by features or routes {#grouping-by-features-or-routes}
+#### Raggruppamento per funzionalità o percorso {#grouping-by-features-or-routes}
 
-One common way to structure projects is to locate CSS, JS, and tests together inside folders grouped by feature or route.
+Una modalità comune per strutturare i progetti è posizionare file CSS, JS e i test in cartelle raggruppate per funzionalità o percorso.
 
 ```
 common/
@@ -35,11 +35,11 @@ profile/
   ProfileAPI.js
 ```
 
-The definition of a "feature" is not universal, and it is up to you to choose the granularity. If you can't come up with a list of top-level folders, you can ask the users of your product what major parts it consists of, and use their mental model as a blueprint.
+La definizione di "funzionalità" non è universale e sta a te decidere la granularità. Se non riesci ad ottenere una lista di cartelle principali, puoi chiedere agli utenti del tuo prodotto di quali parti è composto principalmente e usare il loro modello mentale come schema.
 
-#### Grouping by file type {#grouping-by-file-type}
+#### Raggruppamento per tipo di file {#grouping-by-file-type}
 
-Another popular way to structure projects is to group similar files together, for example:
+Un altro modo popolare per strutturare i progetti è raggruppare file simili, ad esempio:
 
 ```
 api/
@@ -59,16 +59,16 @@ components/
   ProfileHeader.css
 ```
 
-Some people also prefer to go further, and separate components into different folders depending on their role in the application. For example, [Atomic Design](http://bradfrost.com/blog/post/atomic-web-design/) is a design methodology built on this principle. Remember that it's often more productive to treat such methodologies as helpful examples rather than strict rules to follow.
+Alcune persone preferiscono andare ancora oltre e separare i componenti in cartelle diverse a seconda del loro ruolo nell'applicazione. Ad esempio, [Atomic Design](http://bradfrost.com/blog/post/atomic-web-design/) è una metodologia di progettazione costruita su questo principio. Ricorda che spesso è più produttivo trattare queste metodologie come esempi utili piuttosto che come rigide regole da seguire.
 
-#### Avoid too much nesting {#avoid-too-much-nesting}
+#### Evita troppo annidamento {#avoid-too-much-nesting}
 
-There are many pain points associated with deep directory nesting in JavaScript projects. It becomes harder to write relative imports between them, or to update those imports when the files are moved. Unless you have a very compelling reason to use a deep folder structure, consider limiting yourself to a maximum of three or four nested folders within a single project. Of course, this is only a recommendation, and it may not be relevant to your project.
+Ci sono molti punti deboli associati all'annidamento profondo delle cartelle nei progetti JavaScript. Diventa più difficile scrivere importazioni relative tra di loro, oppure aggiornare queste importazioni quando i file vengono spostati. A meno che tu non abbia una ragione convincente per usare una struttura di cartelle profonda, considera di limitarti a un massimo di tre o quattro cartelle annidate in un singolo progetto. Naturalmente, questa è solo una raccomandazione e potrebbe non essere rilevante per il tuo progetto.
 
-#### Don't overthink it {#dont-overthink-it}
+#### Non pensarci troppo {#dont-overthink-it}
 
-If you're just starting a project, [don't spend more than five minutes](https://en.wikipedia.org/wiki/Analysis_paralysis) on choosing a file structure. Pick any of the above approaches (or come up with your own) and start writing code! You'll likely want to rethink it anyway after you've written some real code.
+Se stai avviando un progetto, [non spendere più di cinque minuti](https://en.wikipedia.org/wiki/Analysis_paralysis) per scegliere una struttura di file. Scegli uno degli approcci qui sopra (o creane uno tuo) e inizia a scrivere codice! Probabilmente vorrai ripensarci comunque dopo aver scritto del codice reale.
 
-If you feel completely stuck, start by keeping all files in a single folder. Eventually it will grow large enough that you will want to separate some files from the rest. By that time you'll have enough knowledge to tell which files you edit together most often. In general, it is a good idea to keep files that often change together close to each other. This principle is called "colocation".
+Se ti senti completamente bloccato, inizia mantenendo tutti i files in un'unica cartella. Col tempo diventerà abbastanza grande che vorrai separare alcuni file dagli altri. A quel punto avrai abbastanza conoscenze per indicare quali file modifichi insieme più frequentemente. In generale, è una buona idea tenere i file che cambiano spesso insieme uno vicino all'altro. Questo principio è chiamato "colocation".
 
-As projects grow larger, they often use a mix of both of the above approaches in practice. So choosing the "right" one in the beginning isn't very important.
+Man mano che i progetti crescono, nella pratica spesso adottano una combinazione dei due approcci precedenti. Quindi scegliere quello "giusto" all'inizio non è molto importante.